Backups Are Not a Cloud Feature: The 3-2-1 Rule Every Business Needs
Ask a business owner whether they have backups and the answer is usually yes, everything is in the cloud. That answer confuses two different things, and the difference only becomes visible on the worst day.
Sync is not backup
Sync services keep copies identical. That is the entire point, and it is exactly the problem. Delete a file and the deletion propagates. Overwrite a spreadsheet with a broken version and every device gets the broken version. Ransomware encrypts a synced folder and your cloud copies are encrypted within seconds.
A backup is different in kind: a point-in-time copy you can go back to, held somewhere the live system cannot reach out and change.
Most sync services do keep version history and a recycle bin, and these will save you from an accidental deletion. But the retention window is often shorter than you assume, the restore is per-file rather than wholesale, and ransomware can exhaust version history by rewriting files repeatedly. It is a useful safety net. It is not a backup strategy.
The 3-2-1 rule
The industry shorthand, and it has aged well:
- 3 copies of your data — the live one plus two backups.
- 2 different media or systems — so a single failure or a single vendor problem cannot take out everything at once.
- 1 copy offsite — geographically separate from the original.
Many teams now add a 1 immutable or offline copy: one that cannot be modified or deleted for a fixed retention period, even by an administrator account. This is the specific defence against ransomware, because modern attacks deliberately hunt for and destroy backups before triggering encryption. Object storage providers offer this as object lock or immutable buckets, and it is usually a setting rather than a project.
What people forget to back up
The file server gets backed up. These often do not:
- Cloud applications. Your CRM, accounting system and email are somebody else’s servers, but your data. Most SaaS providers protect against their failure, not against you deleting a record. Check what your contract actually promises.
- The website. Including its database and its configuration, not just the files.
- Configuration itself — DNS records, firewall rules, user permissions. The documents survive and the environment they lived in does not.
- Encryption keys and credentials. A backup you cannot decrypt is not a backup.
Two numbers worth agreeing out loud
How much data can you afford to lose? That sets backup frequency. Nightly means up to a day’s work gone.
How long can you be down? That sets restore design. Restoring from a cheap archive tier can take many hours before you have even started.
Most businesses have never discussed either number, then discover both during an incident.
Untested backups fail
This is the part that gets skipped, and it is the part that matters. Backups fail silently in entirely mundane ways: a job that stopped running months ago and alerted nobody, a share that quietly filled up, a folder that was never in scope, an archive nobody can decrypt because the key was on the failed machine.
Schedule a restore test. Pick a real file, restore it somewhere safe, and confirm it opens. Do it twice a year, and once with the person who is not the usual administrator, because during a real incident that person may be unreachable.
An untested backup is a hypothesis, not a safeguard.
Where to put the copies
Object storage with lifecycle rules and object lock is the usual cost-effective answer for the offsite copy — see cloud storage for business for how the tiers and egress charges work, since retrieval cost is exactly the thing you do not want to discover mid-crisis.
Want someone to check whether your backups would actually restore? Get in touch — it is a short piece of work, and finding out now is considerably cheaper than finding out later.