Backup coverage
One rule: every dataset lives on at least two physical devices, and one of them is not in this house. The table below lists the volume, the cadence and where the second copy sits for each service — anything without a plan listed is not backed up yet.
| service | volume | plan | RAM |
|---|---|---|---|
| Gitea | /srv/homelab/gitea/data | gitea dump produces a single archive with the database, the repositories, the configuration and the attachments. It runs weekly and on demand before every upgrade, and the archive is copied to the NAS. Repositories also exist on the laptops that push to them, which is a real second copy for everything except the issues. | 320 MB |
| Grafana | /srv/homelab/grafana/data | the SQLite database in the data volume holds every dashboard, user and data source, and is dumped nightly. Dashboards themselves are also exported as JSON into git after any change, because a dashboard you cannot diff is a dashboard nobody reviews. | 260 MB |
| Immich | /srv/homelab/immich/library | the library is a plain directory of files with a readable structure, so it goes to the NAS with rsync nightly and the NAS handles off-site. The database is dumped separately with pg_dump — without it you lose albums, faces and the mapping between files and dates, and the library becomes an unsorted pile of correctly named files. | 1300 MB |
| WireGuard (wg-easy) | /srv/homelab/wg-easy/data | the data directory holds the server key pair and every client config, so it is copied after any change and kept in the password manager as an exported archive. Losing it means re-issuing every phone and laptop profile, which is twenty minutes of work you do not want while travelling. | 40 MB |
| Nextcloud | /srv/homelab/nextcloud/html | three parts, and all three are needed: the database dumped with mysqldump every night, the config directory with config.php and the apps, and the data directory. Restoring requires putting back the matching database and the matching config, because the instance id and secret live in config.php and a mismatched pair logs every client out with a server-side error. | 1100 MB |
| Uptime Kuma | /srv/homelab/uptime-kuma/data | the kuma.db SQLite file is dumped nightly with sqlite3 .backup while the container is running, then copied to the NAS. A raw file copy of a live SQLite database can be torn; the .backup command is the safe way and takes under a second at this size. | 180 MB |
| Jellyfin | /srv/homelab/jellyfin/config | config directory nightly to the NAS, and the media library itself lives on the NAS and is backed up there — the Pi holds no irreplaceable data. The one thing worth exporting by hand is the user list and watch state, because rebuilding 'continue watching' from scratch takes weeks of viewing. | 900 MB |
| Caddy | /srv/homelab/caddy/data | the Caddyfile lives in git, which is the real backup. /srv/homelab/caddy/data holds the ACME account key and the issued certificates and is copied weekly; losing it costs one re-issue per hostname, not an outage. | 45 MB |
| Pi-hole | /srv/homelab/pihole/etc-pihole | the whole /etc/pihole directory nightly at 03:10 to the SMB share on the NAS with rclone, 14 daily snapshots kept, plus a copy of gravity.db after every adlist rebuild. If the Pi dies, restoring the directory onto a fresh card brings back blocklists, local DNS records and client groups without re-running the installer. | 240 MB |
What we deliberately do not back up
- Container images: pulling them again is faster than storing them
- Log volumes: docker logs keeps a week, and older lines have no value
- Thumbnails and transcode cache: Immich and Jellyfin rebuild them, it just costs time
- Raw Prometheus samples: only the alert rules and Grafana dashboard JSON are kept