The 3-2-1 backup strategy, explained for Linux servers
What the 3-2-1 backup rule means, why it still matters, and how to implement it for Linux servers with restic, off-site object storage, and tested restores.
What 3-2-1 means
The 3-2-1 rule has been standard backup guidance for decades, since well before cloud storage. The reasoning is about correlated failure: two copies on the same server are lost together if that server fails, and two copies in the same building are lost together in a fire. Spreading the copies across independent locations means a single event cannot take all of them.
- 3 copies of your data — the live copy plus at least two backups.
- 2 different media — do not keep both backups on the same disk or box.
- 1 off-site copy — at least one backup somewhere physically separate.
Why it still matters in the cloud era
Assuming a managed VPS provider handles backups is a common way to end up without any. Provider snapshots usually live in the same account as the server, so a billing lapse, a compromised API key, or an accidental deletion can remove the server and its snapshots together. Ransomware also looks for and deletes backups it can reach. An independent off-site copy is what removes that shared risk.
A concrete 3-2-1 setup for a Linux server
You do not need enterprise tooling. A single VPS can satisfy 3-2-1 cheaply. Because restic encrypts client-side, every off-site copy is ciphertext — you get geographic separation without trusting the storage provider with your data.
- Copy 1 (live): your application data on the server.
- Copy 2 (different medium): a nightly encrypted restic backup to an object-storage bucket on a different provider.
- Copy 3 (off-site): replicate that bucket to a second region or provider; object storage with versioning and an object-lock policy gives you an immutable copy.
The modern update: 3-2-1-1-0
A common extension adds 1 offline or immutable copy (air-gapped or write-once, so ransomware cannot alter it) and 0 errors — meaning you have actually verified a restore. Schedule a periodic restic restore into a scratch location and confirm the files are intact. A backup you have never restored is a guess.
restic restore latest --target /tmp/restore-check
How Rested implements 3-2-1
Rested runs the encrypted restic backups to storage you own, keeps bounded run history, and surfaces failures so a silent gap in your off-site copy does not go unnoticed for weeks. Your recovery key stays with you, so even the off-site copies are only decryptable by you.
Related from Rested
Common questions
Frequently asked questions
What does the 3-2-1 backup rule mean?
Keep 3 copies of your data on 2 different types of media, with 1 copy stored off-site. It ensures no single failure — a dead disk, a fire, or a compromised account — can destroy every copy at once.
Do provider snapshots satisfy 3-2-1?
Usually not on their own. Snapshots that live in the same provider account share a blast radius with the server. You still need an independent, off-site copy — ideally immutable — to meet the rule.
What is 3-2-1-1-0?
An extension that adds one offline or immutable copy and zero backup errors — meaning you have verified a restore actually works, not just that the backup job completed.