Homelab Backup Strategy

What to back up

Distinguishing irreplaceable from regenerable is the first design decision. Backing up everything is wasteful; backing up too little leaves gaps.

The 3-2-1 rule applied to homelab

• 3 copies: live data + local backup + off-site backup.
• 2 different media: NAS + external HDD, or NAS + cloud.
• 1 off-site: cloud, a friend's house, or a USB drive you take to work.

Snapshots don't count as one of the three because they live on the same storage as the original. See snapshots vs backups.

Backup tool choices

Most homelabs end up with: restic or borg for general file backups, ZFS send for VMs/containers on ZFS, and rsync for media libraries.

Where to put copies

• Local backup — a separate NAS, a USB-attached HDD, or a different ZFS pool on the same server.
• Off-site copy — cloud object storage (B2, S3, Wasabi, R2), or a remote NAS at a friend's house, or a rotating USB drive taken off premises.

For cloud off-site, encrypt before upload — the cloud provider stores ciphertext only. restic and borg do this natively.

Encryption

Off-site backups should be encrypted at rest. restic, borg, and Hyper Backup encrypt by default with a passphrase or key file. The key needs to be stored somewhere recoverable but not at the same location that's being backed up — a password manager, a safe-deposit box, etc.

The fastest way to lose a backup is to lose the key. Plan for key recovery as carefully as backup recovery.

The backup schedule

A reasonable starting schedule:

• Hourly — snapshots on critical filesystems. Free; lives on same storage.
• Daily — incremental backup to local backup target.
• Weekly — incremental backup to off-site (cloud or remote).
• Monthly — backup verification (restore test).
• Quarterly — full restore test of one service.

Database backup specifics

Databases need consistent backups. Three approaches:

• Stop the database, copy the files, start it again. Simple; brief downtime.
• Use the database's built-in backup command. mysqldump, pg_dump, sqlite3 .dump. Produces a consistent SQL file.
• Filesystem snapshot of running database. Works if the database supports it (Postgres with continuous archiving, MySQL with consistent snapshots). Otherwise produces inconsistent snapshots that may not restore.

For homelabs running Home Assistant, Nextcloud, Vaultwarden, etc., use the application's built-in backup feature if available.

Container backup strategy

The container image is recreatable; the volumes are not. So:

• Back up the docker-compose.yml or equivalent so containers can be redeployed identically.
• Back up the bind-mounts and named volumes for each container.
• Stop containers before backing up volumes if the data is database-like and may be in transit.
• Don't bother snapshotting running containers — restoring from those often fails.

Bandwidth considerations

The first off-site backup of a large dataset can take days. Strategies:

• Seed off-site initially via sneakernet. Carry a USB drive containing the initial backup to the off-site location; perform incremental updates over the network thereafter.
• Limit upload bandwidth so the backup doesn't saturate your internet during the day.
• Schedule large transfers overnight.
• Compress and dedupe before transferring — restic/borg do this automatically.

Testing restores

The discipline that separates backup-that-works from backup-that-might-work:

1. Monthly: restore one file from each backup; verify it opens correctly.
2. Quarterly: restore a database to a test environment; run a query.
3. Annually: assume primary storage is gone; rebuild a service entirely from backups. Time how long it took.

Discovering backups are corrupt during a real incident is much worse than during a drill.

Monitoring backup success

A backup that didn't run is the same as no backup. Monitor:

• Last successful backup timestamp per repository.
• Backup duration trend (sudden increases may indicate problems).
• Repository size trend.
• Restore-test success.

Healthchecks.io or similar service: your backup script pings a URL on success; the service alerts when the ping is missed.

Common mistakes

• Backup only on the same array as the data. Drive failure or fire takes both.
• No off-site copy. Local disaster (theft, fire, flood) wipes out everything.
• Off-site backup but no encryption. Cloud provider compromise exposes data.
• Backup runs but is never verified. Corrupt or missing data discovered too late.
• Key stored only in the backup itself. Lose access to the live system, lose access to the backup.
• Backing up everything indiscriminately. Wastes time, bandwidth, and storage; nothing prioritized.

Frequently Asked Questions

What should I back up in a homelab?

Three categories. Configuration: VM definitions, container configs, Ansible repos, /etc files — what you'd need to rebuild the homelab from bare metal. Application data: databases, photos, documents, anything the apps store and you care about. Media (optional): movies, music — easy to re-rip if you have the originals, expensive to back up. Skip what's easy to recreate (OS installs, downloadable apps).

What's the right backup tool for homelab?

For incremental dedupe-aware backups: restic or borg. Both handle encryption, dedupe, and remote repositories. For ZFS-based homelabs: ZFS send/receive between two pools (often paired with snapshots). For simple file copies: rsync to a NAS. Most homelabs end up using restic or borg for everything except large media libraries, which are often simpler to rsync.

Where should the off-site copy live?

Options in increasing complexity: a USB drive you take to work and rotate weekly; cloud object storage (Backblaze B2, AWS S3, Wasabi, Cloudflare R2) — restic and borg encrypt before upload; another homelab at a friend's or family's house (mutual off-site). The right choice depends on data volume, network capacity, and ongoing budget.

How often should I test restores?

At least quarterly, restore a representative file or two from the latest backup and verify it opens correctly. Annually, do a more complete restore — bring up a service from backup in a test environment. Untested backups are wishes. The first time you discover backups are broken should not be when you need them.

Should I back up Docker containers?

Back up the volumes (the data), not the containers themselves. Containers should be recreatable from their image and configuration; the docker-compose.yml or Ansible playbook plus the volume contents is what to back up. Backing up running containers (e.g., snapshotting them) often produces inconsistent results because in-flight transactions are mid-flight.