Self-Hosted Backups: What to Back Up and How Often

Most self-hosters discover they have a backup strategy the hard way: the day the disk dies, or the day they run a bad command against the wrong volume. The uncomfortable truth is that not everything needs the same attention, and trying to back everything up with equal zeal usually means you back everything up poorly. A good strategy sorts your data by how painful it is to lose and how often it changes, then applies a schedule to match. The three buckets are configuration, application data, and state machines — databases and queues — and each deserves different frequency and ceremony.

Back Up Configuration Like Code

Configuration is cheap to back up and hard to justify losing. Your compose files, .env values, and certificates tell every other backup how to come back. Because it changes rarely, a nightly job pulling these small files to an off-box location is more than enough. Treat config as its own artifact, kept even longer than app data, because it is your bootstrapping path into a fresh host.

Frequency Decides the Rest

Ask a simple question about each service: how much data can I afford to lose? Losing three hours of a notes app is annoying; losing a day of an accounting ledger is a problem. Match the cadence to the answer. A reasonable default is nightly backups everywhere plus a more frequent mechanism for anything with continuously changing state.

# nightly app-data pull with restic to a remote repo
restic backup /srv/notes-data -r b2:netbay-notes
restic forget -r b2:netbay-notes --keep-daily 14 --keep-weekly 8
restic prune -r b2:netbay-notes

Backup tools like restic handle deduplication and retention so daily runs stay small even as history accumulates — the forget and prune steps keep only what you asked for.

Get Databases Consistent, Not Just Copied

Copying a live database file while it is being written produces a corrupt backup. The correct approach is a tool-native dump or snapshot that guarantees a consistent point in time. For Postgres that means pg_dump or pg_basebackup; for MySQL it is mysqldump. A cron or systemd timer runs it, compresses the output, and ships it off-box.

# consistent Postgres dump, piped gzip, then restic
PGPASSWORD=secret pg_dump -h 127.0.0.1 -U app -d mydb |
  gzip > /backups/mydb.$(date +%F).sql.gz
restic backup /backups/mydb.$(date +%F).sql.gz   -r b2:netbay-db --tag nightly

The pipe makes the to-disk artifact a clean dump rather than an inconsistent file copy, which is the difference between a backup that restores and one that is theater. Databases are the one place a naive file copy will bite you, so always use the tool's own export.

Practice the Restore

A backup you never restore is a guess. Once a month, restore one service into a scratch directory or throwaway container and confirm the application boots against it. The minutes this costs are the cheapest insurance in self-hosting — it turns an unverified hunch into a known-good procedure you can run under stress. Keep the restore commands written down in the same file as your backup script, because your future self will not remember the exact incantation at 2 a.m. during the incident the restore is meant to solve.

Encrypt and Keep It Off-Box

A backup stored on the same disk as the data it protects is not a backup — a disk failure, an accidental rm, or ransomware takes both at once. Push snapshots off the box, and encrypt them on the way out. Restic handles both with a repository password and encrypted storage, so even a backup endpoint you do not fully trust cannot read your data. The password is your one, unforgivable secret for this stack; store it somewhere independent of the host, or every snapshot becomes ciphertext with no key.

# restic forget: keep a rolling window plus a long-term monthly
# off-site policy so history grows bounded
restic forget -r sftp:backup@offsite/restic   --keep-daily 7 --keep-weekly 4 --keep-monthly 12

The principle is the 3-2-1 rule in miniature: at least two copies, on two different media, one of them remote. For a homelab, "remote" can be as modest as a second VPS or a download-only encrypted drive at a trusted friend's place. The size of the endpoint matters less than the fact that it is not the same machine.

Takeaway

Sort your data into config, app data, and databases; give each a cadence that matches how fast it changes; and verify restores on a schedule. The exact tool matters less than the discipline of consistent, off-box, testable snapshots. A Netbay VPS in Lucknow is a solid single-homed base for a homelab, and netbayhosts.in can be your off-site destination for those nightly restic runs.