The 3-2-1 backup rule
and how to actually implement it

3-2-1 has been the gold standard for data protection for decades. Most people have the first two copies. The third - offsite - is the one that saves you when the building burns down. This page explains the rule and shows you how to implement it with restic.

What is the 3-2-1 rule?

  • 3 copies:Your primary data plus two backups. If you only have one backup and it is corrupt, you have nothing.
  • 2 media types:Your primary on one type of storage, backup on another. If both are hard drives in the same machine, a firmware bug or power surge can take both out.
  • 1 offsite copy:Physically separate from your primary location. This is the copy that survives fire, flooding, theft, and ransomware that spreads through the local network.

Why most setups fail the third rule

RAID is not backup. A second disk in the same machine is not offsite. A NAS in the same building is not offsite. Cloud sync (Dropbox, Google Drive) is not quite the same as backup - sync propagates deletions and ransomware encryption to the remote copy.

Real offsite backup means: immutable snapshots, physically separate location, encrypted with a key you control.

A practical 3-2-1 setup for homelabs and Linux servers

  • Copy 1 (primary):Your running data on your main machine or NAS.
  • Copy 2 (local backup):Restic backup to an external drive, a second NAS, or a Proxmox Backup Server on the same LAN.
  • Copy 3 (offsite):Restic over SFTP to a private encrypted vault on ServerCrate. Physically in Los Angeles, encrypted with your key, accessible from anywhere.

Setting up the offsite copy with restic

# Set up credentials
sudo tee /etc/restic/env <<EOF
RESTIC_REPOSITORY=sftp:vaultuser@vault.servercrate.net:22150:/data
RESTIC_PASSWORD=your-strong-password
EOF
sudo chmod 600 /etc/restic/env

source /etc/restic/env
restic init

# First offsite backup
restic backup /home /etc /var/www \
  --tag offsite \
  --exclude="*/cache" \
  --exclude="*/tmp"

# Verify it worked
restic snapshots

Testing your backup - the step everyone skips

A backup you have never tested is not a backup, it is a hope. Schedule a restore drill every 90 days. Restore a random file and verify it opens correctly. Restore a full directory to a temp location and check it. This takes 15 minutes and is worth more than any monitoring dashboard.

# Test restore of a specific file
restic restore latest \
  --target /tmp/restore-test \
  --include /etc/nginx/nginx.conf

cat /tmp/restore-test/etc/nginx/nginx.conf

Modern extensions to 3-2-1

Some people recommend 3-2-1-1-0: an additional immutable copy (1) with zero errors verified (0). Restic's restic check command handles the zero-errors verification. An append-only remote repository handles immutability - once written, old snapshots cannot be deleted even if an attacker gains access to your backup credentials.

3-2-1 for different environments

  • Homelab (Proxmox):Copy 1 = running VMs. Copy 2 = Proxmox Backup Server on local NAS. Copy 3 = Restic to ServerCrate for configs, app data, and critical files. See the Proxmox offsite backup guide.
  • Linux VPS:Copy 1 = live server. Copy 2 = provider snapshot (if available). Copy 3 = Restic to ServerCrate. Provider snapshots don't count as offsite - they are still in the same provider infrastructure. See the VPS backup service page.
  • NAS (TrueNAS/Synology):Copy 1 = NAS primary pool. Copy 2 = NAS parity / ZFS mirror. Copy 3 = Restic to ServerCrate over SFTP. See the NAS offsite backup guide.
  • Docker setup:Copy 1 = running containers with bind mounts. Copy 2 = daily database dumps on local disk. Copy 3 = Restic to ServerCrate including dumps and compose configs. See the Docker backup guide.

Modern extensions to 3-2-1

The original 3-2-1 rule predates ransomware as a mainstream threat. Modern variants add a fourth requirement: at least one copy must be immutable or append-only, so ransomware that encrypts your primary data and local backup cannot also destroy the offsite copy.

Restic with ServerCrate provides strong isolation for the offsite copy - the vault is only writable via SFTP with your credentials, not mounted as a network drive or accessible via SMB. An attacker who compromises your primary machine cannot reach the vault without your SFTP credentials. This makes it a practical ransomware-resilient offsite component for most homelab and small business setups.

The step everyone skips: testing restores

Having three copies means nothing if none of them are actually restorable. Schedule a restore test monthly: pick a random file from your most recent snapshot and restore it. Quarterly, do a full directory restore to a temporary location. The restic restore guide has copy-paste commands for every scenario. ServerCrate has no egress fees so testing costs you nothing beyond a few minutes of time.

FAQ

Common questions.

No. RAID protects against drive failure but not accidental deletion, ransomware, fire, or flood. It is a reliability feature, not a backup. Count RAID as one copy, not two.
Partially. Sync propagates deletions and corruption to the remote copy. For true backup, you need versioned snapshots that cannot be overwritten. Restic to a dedicated vault is more reliable than sync alone.
Run restic snapshots to confirm the offsite copy exists, restic check to verify data integrity, and a restore drill to confirm you can actually get your data back. Do this quarterly.
Get started today

Complete your 3-2-1 setup today.

The offsite piece. Free tier, no card required.

No egress fees, cancel anytime, 7-day money-back guarantee