Why Every Side Project Should Have a Backup Plan (And How to Build One)

Every side project starts the same way: a burst of enthusiasm, a database, and absolutely no backups. This is fine, right up until the moment it is catastrophically not fine — the disk fills, the migration goes sideways, you rm -rf the wrong directory at midnight, or the VPS provider has a bad week and your droplet evaporates with it.

I have lost data this way. Not recently, because losing data once is an education you only need to pay for the once. The lesson was not “back things up more” — everyone knows that. The lesson was that a vague intention to back things up is worth precisely nothing, and only an automated, tested, restorable backup counts. So let’s build one that actually works for a small project, without enterprise budgets or enterprise faff.

1 What you’re actually protecting

Before any tooling, decide what matters. Side projects usually have three categories, and conflating them is how people back up the wrong thing:

• State you cannot regenerate — the database, user uploads, anything a human typed. This is sacred.
• State you can rebuild but would rather not — generated thumbnails, caches, search indexes.
• Code and config — already in Git. If it isn’t, that’s your first job, not your backup strategy’s.

You back up the first category religiously, the second only if it’s cheap, and the third by pushing to a remote you don’t also host yourself.

2 The 3-2-1 rule, scaled down

The old advice is 3-2-1: three copies, on two types of media, with one off-site. For a side project you don’t need a tape robot, but the off-site part is non-negotiable. A backup sitting on the same machine as the original is not a backup; it’s a copy waiting to die in the same fire.

In practice, for a single VPS or homelab box, that means: the live data, a local snapshot for fast restores, and an encrypted copy pushed somewhere else entirely — another machine, a friend’s NAS, or cheap object storage.

3 Dump the database properly

The single most common mistake is copying a database’s files while it’s running and hoping for the best. Use the tool the database ships for exactly this. For Postgres:

#!/usr/bin/env bash
set -euo pipefail

STAMP=$(date +%Y-%m-%d_%H%M)
DEST=/var/backups/myapp
mkdir -p "$DEST"

# consistent dump, compressed, single file
pg_dump --format=custom myapp_prod \
  | gzip > "$DEST/db-$STAMP.sql.gz"

# keep 14 days locally, prune the rest
find "$DEST" -name 'db-*.sql.gz' -mtime +14 -delete

pg_dump gives you a consistent snapshot even while the app is live, which a file copy does not. Run something analogous for MySQL (mysqldump) or just copy the file for SQLite once the app is quiesced.

4 Automate it, then push it off-site

A backup you have to remember to run is a backup you will forget to run. Hang it off cron and send the result somewhere else. I lean on restic for the off-site leg because it’s encrypted, deduplicated and dead simple:

# /etc/cron.d/myapp-backup
15 3 * * *  root  /usr/local/bin/backup-db.sh && \
            restic -r s3:s3.example.com/myapp backup /var/backups/myapp

Encrypted at rest, deduplicated so fourteen daily dumps don’t cost fourteen times the space, and gone from the building.

5 The part everyone skips: restore

Here is the uncomfortable truth. A backup you have never restored is not a backup — it’s a hope. I have seen perfectly diligent nightly jobs that produced corrupt, empty, or unrestorable archives for months, discovered only on the day they were needed.

So once a quarter, do the drill. Spin up a throwaway container, pull the latest backup, restore it, and check the data is actually there:

gunzip -c db-2023-10-09_0315.sql.gz \
  | pg_restore --clean --dbname=restore_test

If it restores and the row counts look right, you have a backup. If it doesn’t, you found out today instead of on the worst day of the project’s life.

6 The honest verdict

Is all this overkill for a hobby app with four users? Slightly — and I’d still do it, because the cost is about an hour to set up and near-zero to run, while the cost of not having it is the project itself. You don’t need the full enterprise ceremony: skip the off-site leg only if you genuinely don’t mind starting over.

For anything with users, anything you’ve put real hours into, or anything you’d be gutted to lose, this is the cheapest insurance you’ll ever buy. Automate the dump, push it off the box, and actually test the restore. The version of you reading this calmly is doing a favour for the version of you who, one day, will be very, very glad it’s there.