The 3-2-1 backup rule for servers: what it means for a VPS

Where the rule comes from

US-CERT, now part of CISA, recommended the rule in a 2012 paper, Data Backup Options, crediting it to photographer Peter Krogh's The DAM Book (2009). The paper puts it in three lines: keep 3 copies of any important file (1 primary and 2 backups), keep the files on 2 different media types "to protect against different types of hazards", and store 1 copy offsite.

That advice was written for desktops, external drives and tapes. A cloud server has no drives you can hold, so each number needs translating.

What 3, 2 and 1 mean on a VPS

Copies that update instantly do not count. A RAID mirror, a database replica or a synced folder copies a deleted table or an encrypted file within seconds. They protect against hardware failure, not against mistakes or attacks.

Why off-provider matters for cloud servers

Provider snapshots and automated backups are useful, but they live in the same account as the server. These problems reach every copy in that account at once:

• Account suspension. An abuse report, a fraud check or a terms dispute can lock the account. While it is locked you may not reach the dashboard, the API or your snapshots.
• Billing failure. An expired card or a missed invoice can lead to suspension and, after the provider's grace period, deletion of resources. Check your provider's terms for how long that period is.
• Compromise. Anyone holding an API token with write access can delete the server and every snapshot in the account in a few calls. That includes an attacker who reads the token from your server.
• Site incidents. In March 2021 a fire destroyed one of four data center buildings on a hosting provider's Strasbourg campus. Data Center Knowledge reported that many customers could not bring their applications back because they did not have backups. A copy kept in the same building would have burned with the server.
• Human error. Deleting the wrong project, or closing an account that still held the only snapshots.

A copy at another company, under a separate login with its own two-factor authentication, survives all five. Give the server credentials that can upload backups but not delete them, so a compromised server cannot erase its own history.

The 3-2-1-1-0 extension

A newer form of the rule adds two numbers. The extra 1 is one copy that is immutable or offline, so nothing can change or delete it during a set period. The 0 is zero errors when you restore it, which you only know by testing. CISA's #StopRansomware Guide covers both in one line: "Maintain offline, encrypted backups of critical data, and regularly test the availability and integrity of backups in a disaster recovery scenario."

For a server, the practical immutable copy is a bucket with S3 Object Lock, which stores object versions write-once-read-many (WORM). AWS defines two retention modes. In governance mode, users cannot overwrite or delete a locked version unless they hold the s3:BypassGovernanceRetention permission. In compliance mode, no user can, including the account's root user, and the retention period cannot be shortened. Object Lock requires versioning, and once it is on a bucket you cannot turn it off.

With the AWS CLI, turn on versioning, then set a default retention for every new object. These commands follow the AWS CLI reference; replace my-server-backups with your bucket name.

aws s3api put-bucket-versioning --bucket my-server-backups --versioning-configuration Status=Enabled

aws s3api put-object-lock-configuration --bucket my-server-backups --object-lock-configuration '{"ObjectLockEnabled":"Enabled","Rule":{"DefaultRetention":{"Mode":"GOVERNANCE","Days":30}}}'

aws s3api get-object-lock-configuration --bucket my-server-backups

Several S3-compatible storage providers implement the same Object Lock API. Check your provider's documentation before you rely on it.

Object Lock in compliance mode still has one exit: AWS notes that the only way to delete a locked object early is to delete the account. That is another reason the locked copy belongs in a different account from the server.

Worked examples: one VPS with a database, three budgets

Take one VPS running a web app with PostgreSQL: a 2 GB database, 5 GB of user uploads, and configuration in /etc. The live disk is copy 1 in every setup.

Minimal. You pay the provider's snapshot or backup fee and storage for a few GB at a second company. It meets 3-2-1: three copies, three storage systems, one off-provider. Its weak point is the upload credential on the server. If it can delete, an attacker on the server can erase the off-site copy too.

Standard. Turning on versioning and Object Lock closes that gap: the server can still write, but for 30 days a backup can only be deleted by a user holding the governance bypass permission, and the server's key does not have it. Six-hourly database dumps cut worst-case loss to a quarter of a day, and the weekly automated drill supplies the "0".

Thorough. WAL archiving lets you restore PostgreSQL to any moment the archive covers, not only to the last dump. The second bucket sits in an account that the server's credentials cannot touch, with a different administrator login. Rebuilding at the other provider proves you could run somewhere else if you had to, and tells you how long it takes.

3-2-1 checklist

Frequently asked questions

Does a provider snapshot count as the off-site copy?

Not for a cloud server. It is stored by the same company, in the same account, so it covers disk failure and many mistakes but not account suspension, billing problems or a stolen API token. Count it as copy 2 and keep copy 3 at a different provider.

Is RAID or a database replica a backup?

No. Both copy changes as they happen, including a dropped table or files encrypted by ransomware. They keep a server running through hardware failure; they do not let you go back in time.

Can a cloud drive be the off-site copy?

Yes, if it belongs to a different company from your server provider and sits behind its own login with two-factor authentication. Object storage is easier to make immutable, because versioning and Object Lock are built for it.

How long should the immutable lock be?

At least as long as it could take you to notice a problem. Damage from an attack or a bad deploy can go unnoticed for days, so 14 to 30 days is a reasonable start. Longer locks cost more, because every locked version is billed until it expires.

Is 3-2-1 overkill for a small project?

The minimal setup above costs the provider's snapshot fee plus storage for a few GB. If losing the server would cost you more than a day of rebuilding or any data you cannot recreate, it is worth it.