I run homelabs and I keep my backups as if my time and sleep depend on them. After the Anna’s Archive takedown, the lesson is simple: a backup system that is private, lawful and testable keeps you in control.
For single files and config, rsync over SSH or Syncthing works well. For versioned, encrypted backups, use restic or Borg. Restic is easy to start with: initialise a repo, add a passphrase, schedule the job, then run restic check to verify integrity. Borg is a better fit for large deduplicated stores. For cloud targets, use an S3-compatible provider or Backblaze B2 and turn on client-side encryption. If you keep disks offsite, use full-disk encryption with LUKS and a unique key.
On the hardware side, a small NAS or mini-server with ECC RAM is worth having if you care about corruption. Keep a separate USB disk or hot-swap bay for cold copies. A cheap router that supports VLANs is enough to keep backup storage away from the rest of the home network. Run backup jobs under a dedicated non-root user. Use SSH keys with a passphrase and restrict allowed commands in authorized_keys for any key that has backup access. Put the backup storage on its own VLAN or subnet and block access from the rest of the home network.
Privacy settings matter. Lock web panels behind 2FA and VPN-only access. If you expose a web interface, put it behind Cloudflare Access or an SSH tunnel, and switch directory listings off. For cloud repos, make sure server-side logs do not contain plaintext passphrases. Use separate credentials per target and rotate them on a schedule, for example every six months. If you use third-party backup services, read their terms and check you are not storing copyrighted material without explicit permission. Domain-level action can also remove access to material if it is linked to copyrighted content. Treat metadata the same as content; sensitive metadata can cause problems if it is shared by mistake.
Schedule backups and schedule restores. Run daily incremental backups and a weekly full snapshot, with a simple retention policy such as daily for 7 days, weekly for 8 weeks, and monthly for 12 months. Use cron or systemd timers for predictable runs. Add a verification job: a weekly script that mounts a random backup snapshot and checks checksums or runs restic check or borg check. I test restores by booting a VM from a recent snapshot at least once a quarter and by restoring a few random user files every month.
Logging matters too. Send backup logs to a separate log host or a cloud log sink. Alert on failed backups via email or a Matrix or Telegram hook. Make the alert useful: include the repo name, volume size, and error output so you can sort it out quickly.
Keep the system maintained like any other security asset. Keep backup software up to date and subscribe to security bulletins for the tools you use. Monitor for unauthorised access with fail2ban and auditd, and review SSH logs weekly. If a breach happens, isolate the backup host, revoke keys immediately, and preserve logs for forensic review. Keep copies of licences and ownership proof for media you store, and avoid keeping mass collections of third-party copyrighted material. Apply least privilege to any process that can read or modify backups. Document the recovery runbook with exact commands and passwords stored in a secure vault.
Choose an encrypted, versioned backup system like restic or Borg; isolate backup hosts on a separate VLAN and use SSH keys plus 2FA; schedule backups, restores and verification; and keep documentation and rotated credentials. That gives you a backup system that survives hardware failure, accidental deletion and the usual legal mess without drama.
