Stratégie de sauvegarde serveur domestique qui fonctionne

A hard truth: RAID is not a backup

RAID and ZFS protect against drive failure. They do nothing against the things that actually destroy data most often: accidental deletion, a bad update, ransomware, a corrupted app database, theft, or fire. Backups protect against all of those. If you take one thing from this guide: build backups before you need them.

The 3-2-1 rule

The time-tested standard:

• 3 copies of your data,
• on 2 different types of media/devices,
• with 1 copy offsite.

For a homelab that typically means: the live data on your server, a backup on a NAS or separate disk, and an encrypted copy in the cloud or at another location.

Step 1: Decide what to back up

Not everything is equally precious. Sort your data into tiers:

• Irreplaceable — family photos, documents, personal projects. Back these up religiously, offsite.
• Hard to recreate — service configs, databases (Nextcloud, Immich, Home Assistant), Docker compose files. Back up regularly.
• Replaceable — media you can re-acquire, caches, downloadable ISOs. Back up lightly or not at all.

Also back up the things people forget: container volumes, databases, and your compose files (ideally in Git).

Step 2: Understand snapshots vs. backups

• Snapshots (ZFS/Btrfs/Proxmox) are instant, cheap rollback points — perfect for undoing a bad change. But they live on the same system, so a dead pool or stolen server takes them too.
• Backups are independent copies on other media/locations.

Use both: snapshots for quick "oops" recovery, backups for real disaster protection.

Step 3: Pick your tools

• Restic — fast, encrypted, deduplicated backups to local disks, SFTP, or cloud (S3, Backblaze B2). Excellent default, scriptable.
• Borg — similar strengths with great compression and deduplication; pairs with BorgBase for hosted repos.
• Duplicati — friendly web UI and scheduling for beginners.
• Proxmox Backup Server — for whole-VM backups with dedup and verification.
• Syncthing — continuous sync between devices (note: sync is not backup on its own, but pairs well).

Step 4: Automate it

A backup you have to remember to run won't happen. Schedule it with cron or a systemd timer. A typical Restic flow:

# Back up important folders to Backblaze B2, encrypted
export RESTIC_REPOSITORY="b2:my-bucket:server"
export RESTIC_PASSWORD_FILE="/root/.restic-pass"
 
restic backup /srv/config /srv/photos /srv/docker
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

For app databases, dump them first (e.g. pg_dump, mysqldump) so you back up a consistent copy, and put apps into maintenance mode where needed (as in the Nextcloud guide).

Step 5: Encrypt everything offsite

Any copy that leaves your home should be encrypted so a breach of the cloud provider doesn't expose your data. Restic and Borg encrypt by default — keep the passphrase somewhere safe and separate from the backups, or you'll be locked out of your own data.

Step 6: Test your restores

This is the step everyone skips. A backup is worthless until you've proven you can restore it. On a schedule (at least quarterly):

1. Restore a few files to a scratch location and diff them.
2. Restore a whole app/VM into an isolated environment and boot it.
3. Confirm databases come back consistent.

Fix any surprises now, not during a real emergency.

Step 7: Monitor for silent failures

The worst backup is one that quietly stopped working months ago. Have your backup script:

• Email or push a notification on failure.
• Ping an Uptime Kuma push monitor on success — so a missing success also alerts you.

A practical blueprint

• Snapshots hourly/daily on your ZFS or Proxmox host for quick rollback.
• Restic nightly of configs, databases and irreplaceable files to a NAS.
• Restic/Borg nightly (or weekly) of the same to encrypted cloud for offsite.
• Quarterly restore test and failure alerts wired up.

Next steps

Set up your first automated Restic job today, then layer in Proxmox Backup Server for whole-VM protection and snapshots via ZFS.