Backup and Disaster Recovery for a Solo Developer: What I Actually Run

As a solo developer managing a few VPS instances for my own projects and client work, I don’t have an ops team on standby 24/7. If a server goes down at 2am, the only thing waking up is a monitoring alert, and the only one fixing it is me. So backup and disaster recovery isn’t a “nice to have” — it’s the only safety net I’ve got.

Backups have to be automated, period

If backing up means “remember to do it every week,” it eventually gets missed — usually right when a client deadline is at its busiest, which is exactly the worst time to lose progress. I schedule a cron job that runs every night for every VPS, so I’m not relying on my own memory for something this important.

Store it off the source server

A backup that only lives on the same VPS is useless if that VPS dies completely or the disk corrupts — you lose the data and the backup together. I push backups to separate object storage, so they’re genuinely independent from the source server. This also came in handy once when I switched VPS providers — just restore from object storage onto the new server, without having to figure out how to move data off the old one I was about to shut down.

Test the restore, don’t just trust that the backup runs

This is the part most people skip, myself included early on. A backup that’s never been restore-tested is a backup that only looks safe — you don’t actually know the file’s intact or the process works until you need it and it fails. I set aside time every few months to actually restore into a fresh environment (a cheap throwaway VPS, not production), to make sure the process really works when needed, not just under ideal conditions.

Document the recovery process

The moment you’re panicking because a server is down is not the best time to think clearly or remember the right command sequence. I keep the recovery steps written down — not just “restore from backup,” but the concrete sequence: which command, where the credentials live, what to check once the restore finishes. So I can follow a checklist instead of improvising under pressure with my heart racing.

Separate database backups from file/config backups

They have different frequency and retention needs. A database usually changes by the minute if there’s traffic, so it needs backing up more often — several times a day for an active project. Static files or server config rarely change, so daily or even weekly is enough. Lumping both into one strategy either wastes storage on the part that barely changes, or doesn’t back up often enough the part that changes constantly.

No setup is completely failure-proof — I can still get hit by something I didn’t plan for. But with the five things above, my worst case went from “project gone entirely, starting from zero” to “a few hours of downtime to restore.” That’s a massive difference when you’re the only person who can fix it.