↓ Skip to main content
merox
Services

3-2-1 Backup Strategy for Your Homelab

·4 mins
Table of Contents
I’ve watched data loss happen, at home and at work, and every time it was the same shape: the backup existed, and nobody had ever restored from it. 3-2-1 is the smallest rule that covers most of the ways this goes wrong.

3

copies

the live data plus two backups

2

media

different disks or systems

1

offsite

survives the building

For a homelab that’s the live data, a local backup target, and one copy geographically separate. Three files on the same array is one copy.

Note

This is the general shape. What my own chain actually looks like today — which legs run when, and what deliberately isn’t backed up — is in the rack tour.

The stack
#

LayerExampleWhat it’s for
PrimaryProxmox + Longhorn / local disksWorking data
Local backupSynology NAS / Proxmox Backup ServerFast restore, same building
OffsiteCloud VPS, Hetzner StorageBox, S3-compatible storageSurvives the building

The tools matter far less than people think. What matters is that the three copies exist, that the offsite one is encrypted, and that you have restored from at least one of them.

The ways it fails anyway
#

  • Never testing restores. A backup you haven’t restored from is a hope.
  • Backups on the same system as the data. That’s a second copy of a single point of failure.
  • No encryption offsite. You’ve handed someone else your files.
  • No versioning. A live mirror replicates the encryption as fast as ransomware writes it.
  • No offsite copy. One fire, one flood, one theft.
Caution

Ransomware looks for backup files specifically, and a mounted backup share is the easiest target in the house. Without versioning or a copy that’s genuinely offline, there is nothing to recover from.

What actually helps: snapshots with a retention policy, at least one copy that’s offline or air-gapped, MFA on whatever manages the backups, and an alert when a job fails. That last one is cheap and catches the most common failure — backups that quietly stopped months ago.

Proxmox Backup Server, from any Linux host
#

Both halves, written now rather than during the outage. --keyfile is what makes the copy on the far end useless to anyone who takes the disk.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

#!/bin/bash
set -euo pipefail

export PBS_PASSWORD='token-secret-from-PBS'
export PBS_REPOSITORY='user@pbs!token@PBS_IP:DATASTORE'
export PBS_KEYFILE='/root/pbscloud_key.json'

echo "Running PBS backup for $(hostname -s) ..."

proxmox-backup-client backup \
  srv.pxar:/srv \
  volumes.pxar:/var/lib/docker/volumes \
  etc.pxar:/etc \
  scripts.pxar:/usr/local/bin \
  --keyfile "$PBS_KEYFILE" \
  --skip-lost-and-found

proxmox-backup-client snapshot list
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

#!/bin/bash
set -euo pipefail

export PBS_PASSWORD='token-secret-from-PBS'
export PBS_REPOSITORY='user@pbs!token@PBS_IP:DATASTORE'
export PBS_KEYFILE='/root/pbscloud_key.json'

if [[ $# -ne 3 ]]; then
  echo "Usage: $0 <snapshot> <archive> <destination>"
  echo "Example: $0 host/cloud/2025-01-22T15:19:17Z srv.pxar /root/restore-srv"
  exit 1
fi

mkdir -p "$3"

proxmox-backup-client restore "$1" "$2" "$3" --keyfile "$PBS_KEYFILE"

echo "Restored $2 from $1 into $3"

PBS_REPOSITORY takes the API token’s full ID, user@realm!tokenname, and proxmox-backup-client reads it and PBS_PASSWORD from the environment, so neither needs repeating on the command line. With set -e the restore script stops at the failing command, instead of printing a success line after it.

Note

Longhorn PVCs don’t go through PBS. Those are restored from the S3 backup target instead.

When one layer dies
#

What failedWhat you still haveWhat to do
Local NASBackup server + offsiteReplace hardware, rebuild the array, restore from whichever copy is closest, then confirm the next scheduled job succeeds
Offsite targetEverything localNew instance, redeploy the client, restore the encryption key from the password manager, run the backup once by hand, confirm the cron is back
Backup serverNAS + offsiteReinstall, restore the datastore config and mount point, check the datastore structure is intact (.chunks, namespaces), then pull from a surviving copy

Each row assumes the other two copies are healthy. The reason 3-2-1 works is that it never asks you to bet on one of them.

What lives in the password manager
#

Restoring is gated on things that are not themselves in the backup:

  • The encryption keyfile, e.g. pbscloud_key.json — without it the offsite copy is noise
  • Token credentials for the backup system
  • The backup paths for each layer
  • The cron definitions, so the automation can be rebuilt from nothing

Keeping it honest
#

Monthly, run an integrity check over a random subset and read the logs for jobs that failed quietly. Quarterly, do a real restore of at least one backup and write down how long it took — that number is your actual recovery time, and it’s usually longer than anyone’s estimate.

Alert on failed jobs and on capacity thresholds. Running out of space is the most common way a backup stops working without anyone noticing.