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, I don’t have an ops team on standby 24/7. So backup and disaster recovery isn’t a “nice to have” — it’s the only safety net I’ve got. Here’s what I actually run.

1. Automated backups, not manual ones. If backing up means “remember to do it every week,” it will eventually get missed. I schedule a cron job that runs on its own, so I’m not relying on my own memory.

2. Store backups off the source server. A backup that only lives on the same VPS is useless if that VPS dies completely or the disk corrupts. I push backups to separate object storage so they’re genuinely independent from the source server.

3. Test the restore, not just the backup. A backup that’s never been restore-tested is a backup that only looks safe. I set aside time periodically to actually restore into a fresh environment, to make sure the process really works when it’s needed.

4. Document the recovery process. The moment you’re panicking because a server is down is not the best time to think clearly. I keep the recovery steps written down, so I can follow a checklist instead of improvising under pressure.

5. Separate database backups from file/config backups. They have different frequency and retention needs — a database usually needs backing up more often than static files or server config.

No setup is completely failure-proof, but with the five things above, my worst case went from “project gone entirely” to “a few hours of downtime to restore” — and that difference matters a lot.