5 things every developer gets wrong about backups
You probably think you have backups. You set up a cron job six months ago, pointed it at your database, and forgot about it. But here is the uncomfortable question: have you ever tested restoring one? If not, you do not have backups — you have hopes.
1. You are not testing your restores
A backup that you have never restored is a backup that might not work. Corrupted files, missing permissions, schema mismatches — these are all common reasons why a restore fails. The only way to know your backups work is to restore them regularly. Set a monthly calendar reminder: download a backup, spin up a test database, restore it, verify the data. If you cannot do this in under 30 minutes, your disaster recovery plan has a problem.
2. You are only backing up the database
Your database is not the only thing that matters. What about your environment variables? Your nginx config? Your SSL certificates? Your uploaded files? A full recovery means restoring everything — not just the PostgreSQL dump. If your server died right now, how long would it take you to rebuild everything from scratch? If the answer is more than an hour, you need to back up more than just data.
3. Your backups are on the same server
This is the classic mistake. You diligently back up your database every night... to the same disk. When the disk fails — and disks do fail — you lose both your data and your backups. Always store backups off-site. A different server, a different data center, an object storage service. The whole point is that your backup survives the disaster that kills your primary.
4. You do not have point-in-time recovery
Daily backups mean you can lose up to 24 hours of data. For a side project, that might be fine. For a production app handling transactions? That is catastrophic. Point-in-time recovery lets you restore to any specific moment — not just the last backup. PostgreSQL supports this with WAL archiving. If you are running a production database and you are not archiving WAL files, start today.
5. You have no retention policy
Keeping every backup forever sounds safe until you run out of disk space and your backup script silently fails. Have a clear retention policy: keep daily backups for 7 days, weekly backups for 4 weeks, monthly backups for 12 months. Automate the cleanup so old backups do not pile up.
How DigitalAura handles backups for you
If all of this sounds like a lot of work, that is because it is. DigitalAura automates the hard parts:
- Automated weekly snapshots for all running VMs (via BullMQ cron)
- Daily backups for managed databases with point-in-time recovery
- Off-site storage on separate infrastructure
- One-click restore from any snapshot
- Retention policies managed automatically
- Manual snapshots available anytime
You should not need to be a backup expert to keep your data safe. Set up your app on DigitalAura, and we handle the rest. Your future self (the one who accidentally ran DROP TABLE in production) will thank you.
# Take a manual snapshot anytime
nolbase servers snapshot my-app --name "before-migration"
# List available snapshots
nolbase servers snapshots my-app
# Restore from a snapshot
nolbase servers restore my-app --snapshot snap_abc123