Operate and recover
Back up home server data
Inventory configuration and state, copy them off the server, and restore into a disposable location.
10 minute lesson
The server is replaceable; its unique data, configuration, and secrets are not. The operating system reinstalls in twenty minutes, containers pull again from the registry — but the file sync data, the Compose files, and the keys exist nowhere else. Back up only what you can identify and restore.
Inventory before tooling
Create an inventory before selecting a tool:
printf '%s\n' \
/etc \
/srv/data \
/opt/services/compose.yaml \
'database dumps' \
'encryption keys stored separately'
Walk through it honestly. /etc covers host configuration (the Caddyfile, fstab, SSH config). /srv/data is the service state. The Compose files under /opt/services are the deployment itself. If a service runs a database, back up a dump — an export the database wrote while consistent — not the raw files underneath a running engine, which may be mid-write and restore as corruption.
The last line is the one people miss. If the backup is encrypted (it should be), the encryption keys stored separately rule is absolute: a key stored only on the server dies with the server, taking every backup with it. Print it, or keep it in your password manager.
Copy it off the machine, encrypted
Use the Backup and Restore course to create an encrypted offsite copy — it builds the full restic workflow. The shape of it:
restic -r sftp:backup@othermachine:/backups/homeserver backup /etc /srv/data /opt/services
“Off the server” is the requirement; a second directory on the same disk protects against nothing that matters.
Restore into a disposable location
A backup you haven’t restored is a hope, not a backup. Perform a file and service restore before trusting it:
restic -r sftp:backup@othermachine:/backups/homeserver restore latest \
--target /tmp/restore-drill --include /opt/services
diff -r /opt/services /tmp/restore-drill/opt/services
An empty diff means the round trip preserved the bytes. Then go one step further once: start the service from the restored copy on a scratch path and check it answers. That’s the drill the runbook lesson rehearses in full.
The false comfort to avoid
RAID, snapshots, and local copies do not protect against every deletion, compromise, theft, or site failure. RAID mirrors your mistakes in real time. Snapshots share the disk they protect. The test for a real backup: if the server were stolen tonight, could you restore tomorrow? Only a copy that lives somewhere else, with keys that live somewhere else again, answers yes.
Lesson completed