What happens to your business if the laptop holding your only copy of the customer database slides off a table tomorrow morning? That single question separates teams that recover in an afternoon from teams that lose a quarter. Cloud backup is the usual answer, but it is also one of the most misunderstood services in IT, sold as a checkbox and often deployed in ways that fail at the worst possible moment. This guide covers what cloud backup really is, how it differs from sync tools, how to design it so it survives ransomware, and the practical mistakes that show up again and again when real restores happen.
What cloud backup actually means
Cloud backup is the practice of copying data over a network to storage run by a third party, so that a usable copy survives a local failure: a dead disk, a flooded office, a deleted table, a malicious encryption event. The copy lives somewhere else, on hardware someone else maintains.
That definition matters because it maps directly onto how cloud services are classified. The standard reference is the National Institute of Standards and Technology’s definition of cloud computing and its service models, which describes five essential characteristics, including on-demand self-service and measured service, and three delivery models: SaaS, PaaS and IaaS. Backup products are usually sold as SaaS (a managed backup service) or built on IaaS (object storage plus your own tooling). Knowing which model you bought tells you who is responsible when a restore fails at 2 a.m.
The critical distinction is between backup and sync. File-sharing drives mirror your working files. Delete a file locally and it vanishes from the cloud too. Overwrite a spreadsheet with garbage and the garbage syncs. A genuine backup keeps versions and retains deleted data for a defined window, so you can go back to a point before the mistake. Many small teams believe they have backup because their documents live in a shared drive. They have availability, not recoverability. (Backup)
The 3-2-1 rule still earns its place
The oldest guideline in the field remains the most useful starting frame: keep at least three copies of your data, on two different media types, with one copy off-site. Cloud backup is the natural way to satisfy the off-site leg, and often the second medium as well.
The rule’s origin is often attributed to photographer Peter Krogh around 2005, though the exact provenance is genuinely disputed, so treat it as folk wisdom that happens to be correct rather than a formal standard. What makes it durable is that it forces you to think about failure domains. Three copies on the same server rack is one copy. Two copies in the same building is one copy during a fire.
In practice, most organizations end up with something like this:
| Copy | Location | Typical medium | Protects against |
|---|---|---|---|
| Primary | Production systems | Local SSD or SAN | Nothing on its own |
| Secondary | Local appliance or NAS | Disk | Accidental deletion, fast restores |
| Tertiary | Cloud provider | Object storage | Site loss, ransomware, hardware failure |
The table is a starting point, not a law. Regulated industries often add a fourth copy in a second cloud region or a separate provider. If you are weighing whether workloads belong in one account or several, there is a useful discussion of when to split workloads across cloud accounts that applies directly to isolating backup infrastructure from production.
Ransomware changed the design requirements
Before roughly 2020, backup design was mostly about hardware failure and human error. Ransomware rewrote the threat model, because modern strains deliberately hunt for connected backups and encrypt or delete them before touching production data.
Government guidance now treats this as a core requirement rather than a nice-to-have. The Cybersecurity and Infrastructure Security Agency’s ransomware guide recommends maintaining offline, encrypted backups and, just as importantly, testing restoration. The word “offline” is doing heavy lifting there. A backup repository with credentials sitting on a domain-joined server is not offline, however remote it is. (NIST Cybersecurity Framework overview)
What actually works in practice comes down to a few controls:
- Immutability. Configure object lock or write-once retention so that no credential, including an administrator’s, can delete or alter backup data before the retention period expires. This is the single highest-value setting in most cloud backup deployments.
- Separate credentials and separate accounts. Backup infrastructure should not share an identity plane with production. If an attacker owns your directory, they should not automatically own your backups.
- Network isolation. Backups should be push-only from production where possible, with no inbound path from the production network into the backup store.
- Retention long enough to matter. If dwell time before detection is three weeks, a fourteen-day retention window is a false comfort.
The most common mistake is treating immutability as a feature to enable later. It is usually a bucket or repository setting that must be chosen at creation time, and retrofitting it means rebuilding the repository and reseeding the data.
Encryption, keys and the question nobody asks
Almost every cloud backup product advertises encryption. The useful question is not whether encryption exists but where the keys live and who can reach them.
Client-side encryption means data is encrypted before it leaves your systems, so the provider stores ciphertext it cannot read. The standard behind most implementations is the Advanced Encryption Standard, specified in NIST’s FIPS 197 publication, typically in its 256-bit form, with TLS protecting data in transit. Provider-side encryption, by contrast, protects data at rest on the vendor’s disks but leaves the vendor able to decrypt.
Both models are legitimate. Client-side is stronger against a subpoena, a rogue insider or a provider breach, and weaker on convenience: lose the key and the data is gone, permanently, with no support ticket that can fix it. That trade-off needs an explicit decision and a documented key escrow process, not an accident of default settings.
A related practical point: encryption keys deserve the same 3-2-1 treatment as the data. Teams that carefully back up 40 terabytes and store the only copy of the encryption key on the same server have built a very expensive random number generator.
Cost: the restore is where budgets break
Cloud backup pricing looks simple and usually is not. Charges typically combine stored volume, request operations, and egress, the fee for pulling data back out. Egress is the line item that surprises people, because a routine monthly backup costs little to store and a full disaster recovery can mean retrieving tens of terabytes in a week.
The pattern to watch is asymmetric: steady-state costs are predictable and small, while the one event you are actually paying for is the expensive one. A clearer way to think about this is covered in this breakdown of how to track cloud data transfer costs, which is worth reading before you commit to a retention policy measured in years.
Three habits keep restore costs sane:
- Model a full restore, not a monthly bill. Price out retrieving your entire dataset once and add it to the business case.
- Tier the retention. Keep recent backups in fast, expensive storage and older ones in archive tiers with slower retrieval, accepting that an ancient restore will take hours.
- Test the cost figures alongside the technology. A restore drill that ignores the bill teaches you only half the lesson.
Cost reviews also fail for a human reason: the people who can change architecture rarely see the invoice. There is a good argument in this piece on making cloud cost reviews useful to engineers that applies neatly to backup spend, which is easy to ignore until it is not.
Compliance is part of the design, not a review step
Where personal data is involved, backup location and provider choice are legal questions. In the European Union, the General Data Protection Regulation governs processing of personal data, and its full text on EUR-Lex sets out the obligations that matter most here: Article 28 requires a written contract with each processor, and Article 32 requires appropriate technical and organizational security measures. A backup provider is a processor. The contract, the storage region and the retention period all need to reflect that.
In the United States, health data brings its own rules. The Department of Health and Human Services publishes guidance on the HIPAA Security Rule, which requires covered entities to back up data and maintain a contingency plan. Cloud backup can satisfy that requirement, but only under a signed business associate agreement, and only if the plan is documented and exercised.
The practical takeaway for both regimes: decide the data residency and processor terms before the first byte moves. Migrating a backup repository to a different region later is slow, costly and, in some contracts, a billable event. A structured approach to what to inventory before a cloud migration helps here, because data classification is the input to every residency decision.
Testing: the only proof that counts
An untested backup is a hypothesis. Every serious guidance document says the same thing, and every post-incident review of a failed recovery says the same thing too: nobody tried.
What works in practice is unglamorous. Schedule restores on a calendar, not on intent. Restore a random sample monthly, a full application quarterly, and a complete site-loss scenario annually. Record how long each took, because recovery time is a number leadership will ask for during an incident, and a guess will not survive contact with a real outage.
Common failure modes surface quickly once testing starts: backup jobs that silently stopped weeks ago because a credential expired, agents excluded from policy by an old group membership rule, databases backed up in a crash-consistent state that will not start, and retention policies that deleted the very version needed. None of these are exotic. All of them are invisible without a restore.
If you want a broader map of how backup fits into the rest of your estate, the material on cloud infrastructure and architecture and on enterprise AI and cloud security covers the surrounding layers, from network design to identity. For teams building out a wider program, the overview at 9481.org is a reasonable starting point.
Conclusion
Cloud backup is not a product you buy and forget; it is a promise you have to keep proving. The teams that recover well tend to share a handful of habits: they separate backup from sync, they keep an immutable and isolated copy, they know where their encryption keys live, they have priced a full restore, and they actually run restores on a schedule. None of that is expensive or exotic. It is just deliberate.
Start with one question: if production vanished right now, what would you do first? If the honest answer involves hoping, the backup design needs work before anything else on the roadmap does.
Frequently asked questions
Is cloud backup the same as cloud storage?
No. Cloud storage and file-sync services keep your working files available across devices, and deletions or overwrites propagate. Cloud backup keeps separate, versioned copies you can restore to an earlier point in time. The test is simple: delete a file in the tool and see whether a recoverable copy survives. If it does not, you have storage, not backup.
How many copies of data do I really need?
The long-standing guideline is three copies, on two media types, with one off-site. In practice that usually means production data, a local copy for fast restores, and a cloud copy for site loss and ransomware. Regulated environments often add a fourth copy in a separate region or with a second provider.
Can ransomware delete my cloud backups?
It can if your backups are reachable with the credentials an attacker has stolen, which is exactly why modern guidance stresses offline or immutable copies. Enable object lock or write-once retention, keep backup credentials out of the production identity system, and make the backup path push-only. Without those controls, a remote backup is only remote, not safe.
How often should I test a restore?
More often than feels necessary. A workable rhythm is a small sample restore monthly, a full application restore quarterly, and a complete disaster scenario once a year. Record the time each takes, because recovery time is the number that matters during an actual incident.
What drives the cost of cloud backup?
Three things: how much you store, how long you keep it, and how much data you pull back out. Storage is usually the predictable part. Retrieval charges, often called egress, can dominate the cost of a large recovery, so price a full restore before you commit to a multi-year retention policy.
Is client-side encryption worth the extra hassle?
It depends on your threat model. Client-side encryption means the provider stores data it cannot read, which helps with breach exposure, insider risk and legal requests. The cost is that lost keys mean lost data, with no recovery path. If you choose it, treat key escrow as seriously as the backup itself.
