Backup rule (3-2-1)

What each number protects against

Three copies mean a single failed backup is not a disaster. Two kinds of storage mean one fault, such as a bad disk model or a provider bug, cannot take both. One off-site copy survives the loss of the whole site or provider account.

What the rule does not cover

The rule does not say whether an attacker can reach your backups, or whether they restore. Add a copy that cannot be deleted from the production server and test restores on a schedule. The full plan, with tools and commands, is in our VPS backup strategy guide.

Counting copies honestly

The numbers in 3-2-1 only help if each copy can survive the loss of the others. A quick audit of your own setup is more useful than reciting the rule. For every copy, write down three facts: where it physically lives, which account or key can change it, and which account or key can delete it. Then apply a few tests:

• The live data counts as copy one. A second directory on the same disk is not a second copy of the storage.
• A mirror or sync that replicates deletions immediately is replication, not a backup, because a mistaken delete or a malicious encryption arrives on the other side within moments.
• "Two kinds of storage" means failure domains that differ: for example the server's disk and object storage, or a separate backup host, not two volumes from the same provider account.
• "Off-site" is best read as a different provider or account, so one billing lock or compromised login cannot reach both the server and the copy.

If one set of credentials can modify every copy, you have one copy with extra steps. This is why the backup strategy guide adds a copy the production server cannot delete, and why CISA's #StopRansomware Guide pairs offline backups with regular testing. Repeat the audit after each infrastructure change.

Verifying the chain with restic and Borg

A listed snapshot is not proof that the data inside can be read. Both common tools include verification, and the restic documentation explains the cost. The default restic check verifies the structure of snapshots, trees and pack files but does not confirm that the pack files on disk are unmodified. --read-data downloads and verifies every pack file, which is thorough but slow, and --read-data-subset spreads that work over time:

restic check
restic check --read-data-subset=1/5
restic restore latest --target /tmp/restore --include /etc/hostname

Using subsets 1/5 through 5/5 on five separate runs covers the whole repository. The restore line, in the form shown in the restic restore docs, proves one real file comes back. For Borg, borg check runs a repository check and an archive check, and --verify-data adds a full cryptographic check that reads, decrypts and decompresses everything, which the docs call very slow. Leave --repair alone until the repository itself is backed up, since the docs label it potentially dangerous.

Schedule the cheap checks, rotate the deep ones, and alert on any failure, as the monitoring guide explains.

Related terms: Ransomware, Incident response, VPS, RPO and RTO, Object Lock.