Identify the three data categories

Application data includes databases, user uploads, media libraries, and any content created by services or visitors. On a typical home server this might be the contents of PostgreSQL or SQLite databases plus directories holding photos or documents. These items exist nowhere else and require the highest frequency and longest retention.

Configuration covers files that make the server function as this specific machine rather than a generic install. Examples are /etc directories, Docker Compose files, reverse-proxy settings, TLS certificates, systemd units, and environment files. Reconstructing these from memory during an outage is error-prone, so they belong in the backup even when version control already stores copies.

Replaceable software comprises the operating system, binaries in /usr, and packages that a package manager or Ansible role can recreate deterministically. Backing up these files adds little value for most servers because reinstall time is acceptable; exceptions arise only when recovery time objectives are extremely tight.

Choose and configure a backup tool

Restic provides a single static binary that encrypts data before it leaves the server and supports local paths, SFTP, and S3-compatible storage. Create one repository for each category or combine them with tags so retention policies can differ. Run backups under a dedicated user with read-only access to the source paths to limit blast radius if credentials are exposed.

Borg offers similar deduplication and encryption with slightly different compression options. Both tools separate the forget operation, which applies retention rules, from prune, which reclaims space. Schedule them together so old snapshots are removed before disk usage grows unchecked.

  • Initialize the repository once with a strong passphrase stored offline and outside the server.
  • Tag snapshots with the category name so policies can keep daily application data for 30 days while keeping configuration for 90 days.
  • Enable append-only mode or object-lock on the remote repository to protect against ransomware deletion.

Set retention and verification schedules

A 3-2-1-1-0 approach keeps three copies on two media types with one copy offline or immutable and zero errors on verification. For a home server this often means a local NAS copy plus an off-site object-storage copy. Run a fast structural check daily and a sampled data read weekly to catch bit-rot or upload truncation.

Database dumps should be taken consistently with tools such as pg_dump rather than copying live files. Include WAL archiving when point-in-time recovery is required. Application data snapshots can run every six hours during low-activity periods while configuration is captured on change plus once daily.

Perform regular restore testing

Integrity checks confirm stored chunks are readable; they do not prove the restored files will start services correctly. Schedule restore drills to a throwaway directory or spare virtual machine at least monthly. After each restore, verify file counts, import database dumps into a test instance, and confirm services start without errors.

Document the exact commands used so any administrator can repeat the drill. Never restore production data in place during testing; always target an isolated location first.

  • List recent snapshots and confirm timestamps match expectations.
  • Restore the latest snapshot to /tmp/restore-test and compare checksums of critical files.
  • Run a full repository check with data sampling on a quarterly schedule.

Automate and monitor the entire workflow

Wrap the backup, forget, prune, and check steps in systemd timers or cron jobs. Send success and failure notifications to a channel that is checked daily. A silent backup failure is the most common cause of data loss during incidents. Keep the repository password in a separate location from the server itself so an attacker who compromises the machine cannot also delete the backups.