Home backup
Overview
This is the backup tooling for everything else on my home server. I wrote it with one idea in mind: a backup you have not restored is a rumour.
It has two parts. A small Node.js library checks the database dump, exports the Paperless data, makes the snapshots and sends me a short message at the end. A set of scripts on the host starts all of it from Windows Task Scheduler.
I kept the scripts out of containers. They need to reach into the running containers and use the tools on the host, and a container would only mean more credentials to look after.
Two details matter most to me. A dump is checked before it is copied, so a bad one cannot replace a good one. And no password or host name lives in the code.
Problem
My home server holds my documents, my finances and my recipes. I wanted backups that run on their own and that I can trust. A backup I have never restored is only a guess, so I built the tooling around that idea.
Approach
- I split the repository in two. A small Node.js library runs the steps, and a folder of shell and batch scripts is started by Windows Task Scheduler.
- The library checks the database dump, runs the Paperless export, makes the restic snapshots and writes a log.
- I kept the scripts outside of containers on purpose. They call docker exec on the running Paperless and PostgreSQL containers and use the restic, rclone and 7z that are installed on the host.
- I read every password and host name from the environment and never wrote them into the code.
- I added a short Telegram message at the end of each run. It is optional and skipped when no token is set.
Architecture and design decisions
- The backup covers the PostgreSQL dump, the Paperless export, a copy to a second machine and the sync of phone scans.
- The data ends up in four places: a local folder, a second machine reached over ssh and scp, an off site restic repository with its own encrypted password, and Google Drive for the phone scans through rclone.
- Putting the scripts in a container would only add a second set of credentials and mounts, so they run on the host.
- The batch scripts have sensible defaults and read values such as the backup location, the backup host and the database password from the environment when they are set.
Reliability and performance
- A database dump is checked before it is copied away, so a broken dump cannot overwrite a good backup.
- Backups run on their own from Windows Task Scheduler and write a log.
- The off site copy is encrypted with its own password.
- The rclone config, the SSH private key and the Google service account file are git ignored.
- Data lives in four places, so losing one does not lose everything.
Outcomes
- Backups run without me starting them.
- Every backup run ends with a log and a short Telegram message.
- My data sits in four places, including one encrypted off site copy.
- A broken dump never replaces a good backup.
- No credential or host name is stored in the repository.
Known gaps
- I have not described a tested restore. The idea is that a backup you have not restored is a rumour, but this page does not show a restore run.
- I have no numbers for backup size, run time or how long I keep old snapshots.
- I do not say how often the backups run.
- It is built for one household on a Windows host. I have not tested it on other setups.
- I do not say which licence the repository uses.