The 3-2-1 Backup Rule and Cloud Backups

Every business backs up its data, or believes it does. The trouble usually appears only when something goes wrong: the backup was on the same server that failed, the ransomware encrypted the backup drive too, or nobody had ever tried a restore. The 3-2-1 backup rule is a simple, long-standing guideline that protects against exactly these failures, and cloud storage makes it easier and cheaper to follow than ever.

What the 3-2-1 backup rule says

The rule fits in one sentence: keep three copies of your data, on two different types of storage, with one copy offsite.

• 3 copies: the live data plus two backups. If one backup is corrupt, you still have another.
• 2 different media: for example a local disk or NAS and cloud object storage. A single type of storage can share a single weakness, such as a firmware bug or a faulty batch of drives.
• 1 offsite: at least one copy in a different physical location, so fire, flood or theft at your office or data centre does not take everything.

The idea is not about any particular product. It is about removing single points of failure from your recovery plan.

Why the rule needed an update: ransomware

When 3-2-1 became popular, the main threats were hardware failure and physical disasters. Today, ransomware attackers deliberately look for backups and delete or encrypt them before launching their attack. A backup that is permanently connected and writable from your network is not safe from them.

That led to the extended 3-2-1-1-0 version promoted by several backup vendors:

• 1 offline or immutable copy: one copy that cannot be changed or deleted for a set period, even by an administrator account.
• 0 errors: backups are verified and restores are tested, so you know they work.

How cloud storage fits the 3-2-1 backup rule

Cloud object storage (Amazon S3, Azure Blob Storage, Google Cloud Storage, Backblaze B2, Wasabi and others) is a natural home for the offsite copy. It is in a different location by definition, it scales without buying hardware, and most providers support features that help with the newer requirements:

• Object lock / immutability: S3 Object Lock, Azure immutable blob storage and Google Cloud Storage bucket retention policies can prevent objects from being deleted or overwritten until a retention date.
• Versioning: keeps previous versions of overwritten files, so an encrypted file does not replace the clean one.
• Lifecycle rules: move older backups to cheaper archive tiers automatically.
• Separate accounts: storing backups in a different cloud account, with different credentials, limits the damage if your main account is compromised.

Example 3-2-1 layouts

The last row surprises many people. SaaS providers keep your service running, but their retention features are not a full backup in the 3-2-1 sense. Accidental deletions beyond the retention period, or a compromised admin account, can still lose data.

A practical server example

On a Linux server, an open-source tool such as restic can send encrypted, deduplicated backups straight to S3-compatible storage. A minimal setup looks like this:

export AWS_ACCESS_KEY_ID=backup-only-key
export AWS_SECRET_ACCESS_KEY=...
export RESTIC_REPOSITORY=s3:s3.amazonaws.com/example-backups/web01
export RESTIC_PASSWORD_FILE=/root/.restic-pass

restic init                                  # once
restic backup /var/www /etc /root/db-dumps   # nightly via cron
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 12 --prune
restic check                                 # verify repository integrity

Use credentials that can write backups but not delete them where your storage allows it, and combine with object lock for real protection. Dump databases to files first (for example with mysqldump --single-transaction or pg_dump) rather than copying live database files.

Testing restores: the step most people skip

A backup you have never restored is a hope, not a plan. Schedule restore tests, at least quarterly and after major changes:

1. Pick a random file, folder or database from a recent backup.
2. Restore it to a separate location, never over live data.
3. Open it and confirm it is complete and readable.
4. Record how long the restore took. That number tells you whether you can meet your recovery time objective.

Once a year, try a full restore of a critical system onto a fresh server. This is where missing configuration files, forgotten cron jobs and undocumented dependencies come to light.

Common mistakes

• Sync is not backup. Tools like Dropbox or OneDrive sync deletions and encryption too. Use versioning and a separate backup.
• Snapshots on the same platform only. A snapshot in the same account is convenient but shares that account's risks.
• Unencrypted offsite copies. Encrypt backups before they leave your control, and store the key somewhere other than the server being backed up.
• No monitoring. Backups fail silently. Alert on failed or missing jobs.

If you would rather have backups set up and monitored for you, this is part of our server management and database management work.

Key takeaways

• The 3-2-1 backup rule: three copies, two media, one offsite.
• Add an immutable or offline copy and verified restores (3-2-1-1-0) to resist ransomware.
• Cloud object storage with versioning and object lock is an ideal offsite copy.
• SaaS data needs its own backup, and every backup needs a tested restore.