When family data lives on a home server, backup stops being optional and becomes part of the service itself. Among the available tools, restic is one of the most popular with people who run small servers: it is a single program, encrypts everything by default, removes duplicates and saves to many different destinations. Let us see how to use it in an orderly way for services hosted at home.
How restic thinks
Restic stores data in a repository, which can live on an external disk, on another computer over SFTP, on S3-compatible storage or on a dedicated server (rest-server). Each run creates a snapshot, a picture of the files at that moment.
Three features make it well suited to home use:
- Encryption: data is encrypted before it leaves the server. Anyone accessing the destination sees only unreadable blocks.
- Deduplication: files are split into chunks and each chunk is stored only once. A hundred snapshots of a folder that changes little take up barely more than one.
- Independent snapshots: each snapshot can be restored on its own, with no chain of incremental backups to rebuild.
The important consequence of encryption is that losing the repository password means losing the backup. Keep it in a password manager and, ideally, also on paper in a safe place.
Preparing the repository
The first step is to create the repository. With an external disk mounted at /mnt/backup:
export RESTIC_REPOSITORY=/mnt/backup/restic
export RESTIC_PASSWORD_FILE=/root/.restic-pass
restic init
Using a password file readable only by root avoids writing the password into scripts or seeing it in the command history.
What to back up and how
If services are organised in a consistent folder layout, the backup comes down to a few paths. The delicate point is databases: copying their files while the service is writing can produce an inconsistent backup. There are two ways round this:
- Stop the services for the duration of the backup, then restart them. Simple and safe, well suited to night-time hours.
- Export a dump before the backup, for example with
pg_dumpfor PostgreSQL, and save the exported file along with the rest of the data.
An example nightly script:
docker compose -f /srv/services/immich/compose.yaml stop
restic backup /srv/services --exclude-caches --tag nightly
docker compose -f /srv/services/immich/compose.yaml start
The --exclude-caches option skips folders marked as caches, while tags help distinguish automatic backups from those made by hand before an update.
Retention policies
Without a clean-up rule, the repository grows forever. Restic lets you decide how many snapshots to keep for each period:
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 12 --prune
This policy keeps the last seven days, four weeks and twelve months. The forget command decides what to drop, while --prune actually frees space by removing chunks that are no longer used. Pruning is a heavier operation: at home, once a week is enough.
A copy outside the house
An external disk attached to the server protects against failure of the main disk, but not against theft, fire or water damage. You need at least one copy in another place. With restic there are several options:
| Destination | Advantages | Things to watch |
|---|---|---|
| Disk at a relative's home | No recurring cost | Needs a connection or a periodic swap |
| Remote server over SFTP | Full control | That server needs maintaining too |
| S3-compatible storage | No maintenance | Traffic and storage costs |
You can initialise a second repository and run the backup twice, or copy snapshots from one repository to the other with restic copy.
Checking that the backup works
A backup that has never been verified is only a hope. Restic offers two levels of checking:
restic checkverifies the structure of the repository.restic check --read-data-subset=10%actually reads a portion of the data, in rotation, to find damaged chunks.
Besides the automatic checks, it is worth occasionally performing a real restore of a service to a test folder with restic restore latest --target /tmp/test, or exploring a snapshot by mounting it with restic mount. It is the only way to be sure that, on the day you need it, the data really comes back.
In short
- Restic encrypts, deduplicates and stores independent snapshots on many destinations.
- The repository password is irreplaceable: guard it carefully.
- Databases should be stopped or exported before the backup.
- The
forgetandprunepolicies keep space under control. - An offsite copy and test restores complete the system.
