What is the 3-2-1 backup rule, and does it still work?

What does 3-2-1 mean?

Keep three copies of the data, on two different kinds of storage, with one copy offsite. The point of all three numbers is independence: each copy should fail for different reasons, so whatever takes out one leaves the others.

3 copies means the live data plus two backups. With a single backup, one bad night on the backup side leaves you with nothing if the server fails the next day.

2 kinds of storage means the two backups don't share hardware. Two folders on the same disk array die together. A NAS and cloud object storage don't.

1 offsite means one copy lives somewhere else. A fire, flood or break-in at the client's office takes everything in the building, including a NAS in the comms cupboard.

Why keep a local copy at all?

Because most restores are small and someone is waiting for them: a folder deleted this morning, a spreadsheet saved over. From a NAS at the client's site that restore runs at LAN speed. Pulling a whole file server back from the cloud over the client's internet connection can take much longer, and the business is down while it runs.

The offsite copy has a different job. It is the one you use when the local copy is gone: the building is damaged, or the NAS was encrypted along with the server. Plan for both jobs.

What counts as offsite?

A different physical location: cloud object storage, or a second site. Ask whether the event that destroys the client's office also reach this copy. If it would, the copy isn't offsite.

A USB disk taken home every night counts, as long as someone really takes it every night. That is the weak spot. It depends on a person remembering, and it quietly stops happening. Cloud storage written by the backup software every night doesn't depend on anyone's memory.

A second server in the same building doesn't count, however separate it looks on the network diagram.

What is 3-2-1-1-0?

A newer version of the rule with two more numbers.

The extra 1 is one copy that is offline, air-gapped or immutable, so nothing on the network can change or delete it. This is the ransomware answer. An attacker who has the domain admin password can reach every backup the network can reach, a NAS included. A copy held with S3 Object Lock, for example, can't be deleted or changed until its retention period ends.

The 0 is zero errors: every backup is checked, and restore tests pass. A backup job that reports success but can't be restored is only found out during a real restore.

What doesn't count as a backup copy?

• RAID. It keeps the server running when a disk dies. A deleted or encrypted file is deleted or encrypted on every disk in the array at once.
• Sync and replication, including OneDrive and copies to a second server. They keep both sides the same, so a deletion or ransomware encryption is copied across too.
• Snapshots on the same storage. Useful for quick rollbacks, but they live on the same device and the same administrator can delete them.
• A second folder on the same server. Same disk, same failure.

How do you apply 3-2-1 to a client's file server?

1. Copy 1 is the live data on the server.
2. Copy 2 goes to a NAS or disk at the client's site. Don't join the NAS to the domain and don't map the backup share as a drive letter on the server, so the server's own accounts can't reach it. This is the copy for fast restores.
3. Copy 3 goes to cloud object storage with immutability turned on. This is the offsite copy and the one ransomware can't change.

Then the parts that keep it honest: separate credentials for each backup copy, two-factor sign-in on the backup console, alerts when a backup fails or doesn't run, verification of every backup, and a restore test on a schedule. That gets you from 3-2-1 to 3-2-1-1-0.

How does MoorNest cover 3-2-1?

MoorNest covers the two backup copies with two plans on the same server: one writes a fast local copy to the client's NAS or disk, through a MoorNest gateway, and the other writes a second copy to MoorNest Cloud, away from the building. The server writes each copy itself, and each destination has its own keys and its own copy of every block, so damage at one doesn't reach the other. The cloud copy is held with S3 Object Lock, and every backup is encrypted on the server before it leaves.

That covers the 3, the 2, the offsite 1 and the immutable 1. For the 0, MoorNest verifies each backup; the restore test is still yours to schedule. The security page has the details.