Backups & Recovery
Here's a question every app builder should be able to answer:
If your database was deleted right now, how much data would you lose? And how long would it take to recover?
If you can't answer this confidently, you don't have a backup strategy — you have a hope strategy.
Why Backups Matter
Data loss happens more often than you think:
| Cause | How It Happens |
|---|---|
| Human error | You or someone else accidentally deletes data or runs a destructive command |
| Software bugs | A bug in your app corrupts data or deletes records |
| Security breach | An attacker deletes or encrypts your data (ransomware) |
| Hardware failure | Your server's hard drive dies |
| Hosting provider issues | Your cloud provider has an outage or data loss incident |
| Natural disasters | Fire, flood, or power outage at a data center |
Without backups, any of these can mean permanent data loss.
The Backup Types You Need
1. Database Backups
Your database is the most critical thing to back up. It contains user accounts, orders, content, and everything that makes your app work.
How often: At least daily for production apps. Hourly for apps with frequent data changes.
What to back up: The entire database — all tables, all records.
2. File Backups
If your app stores uploaded files (images, documents, user avatars), these need to be backed up too.
How often: Depends on how frequently files change. Daily is usually sufficient.
What to back up: Upload directories, configuration files, and any other non-database data.
3. Configuration Backups
Your app's configuration — environment variables, server settings, deployment scripts — should be backed up separately.
How often: Whenever configuration changes.
What to back up: Environment files, server configuration, deployment scripts, SSL certificates.
The 3-2-1 Backup Rule
The industry standard for backups is called the 3-2-1 rule:
| Rule | What It Means |
|---|---|
| 3 copies of your data | 1 primary + 2 backups |
| 2 different storage types | e.g., cloud storage + external drive, or two different cloud providers |
| 1 copy off-site | Stored in a different physical location |
Example:
- Copy 1: Your production database (primary)
- Copy 2: Automated daily backup on the same cloud provider
- Copy 3: Weekly backup on a different cloud provider or physical drive
Common Backup Mistakes
Mistake 1: Never Testing Restores
"We have backups."
The most dangerous backup is one you've never tested. A backup that can't be restored is not a backup — it's a false sense of security.
Test your backups regularly. At least once a month, try restoring your backup to a test environment and verify the data is complete and usable.
Mistake 2: Backups on the Same Server
If your backup is stored on the same server as your database, it's not a backup. If the server fails, you lose both the data and the backup.
Store backups on a different server or cloud storage service.
Mistake 3: Infrequent Backups
A weekly backup means you could lose up to a week of data. For most apps, that's unacceptable.
Back up at least daily. For apps with user-generated content or transactions, consider hourly backups.
Mistake 4: No Off-Site Backup
If your backups are in the same data center as your app, a regional outage or disaster can wipe out everything.
Keep at least one backup in a different geographic region.
Mistake 5: Assuming Your Hosting Provider Handles It
Many cloud hosting providers offer backup services, but they're often optional and cost extra. Don't assume your data is being backed up. Check your hosting plan and configure backups explicitly.
How to Set Up Backups
For Non-Technical Founders
If you're not comfortable with command-line tools, use a hosting platform that includes automated backups:
| Platform | Backup Features |
|---|---|
| Vercel | Automatic backups with Postgres/Neon integration |
| Railway | Automated daily backups with point-in-time recovery |
| Supabase | Automated daily backups (paid plans) |
| PlanetScale | Automatic daily backups with branch-based restore |
| Render | Automated daily backups for Postgres |
| DigitalOcean | Automated daily backups ($1/month per database) |
What to check:
- Are backups automated?
- How often do they run?
- How long are backups retained?
- Can you restore to a specific point in time?
- Have you tested the restore process?
For AI-Assisted Developers
Ask your AI tool to set up backups with this prompt:
Set up automated daily backups for my [database type] database.
Requirements:
- Backups should be stored on [cloud storage service, e.g., AWS S3]
- Keep daily backups for 7 days, weekly backups for 4 weeks
- Test that backups are valid after creation
- Send a notification if a backup fails
- Document the restore process
Recovery: The Part Everyone Forgets
A backup is useless if you can't restore from it. You need a documented recovery plan.
Recovery Plan Template
💡 New to Markdown? This template uses Markdown — a simple way to format text with symbols like
#for headings and-for bullet lists. If any of this looks unfamiliar, check out our Markdown Crash Course — it covers everything you need in 2 minutes.
# Recovery Plan
## If the database is corrupted or deleted:
1. Stop the application to prevent further data changes
2. Download the most recent backup from [location]
3. Restore the backup to the database:
[specific commands or steps]
4. Verify the data is complete:
[how to check]
5. Restart the application
6. Notify users that service has been restored
## Estimated recovery time: [X] minutes/hours
## Who is responsible: [name or role]
## Last tested: [date]
Recovery Time Objectives
Two metrics matter for recovery:
| Metric | What It Means | Good Target |
|---|---|---|
| RPO (Recovery Point Objective) | How much data you can afford to lose | < 1 hour for critical apps |
| RTO (Recovery Time Objective) | How long you can afford to be down | < 4 hours for most apps |
If your RPO is 24 hours (daily backups), you accept losing up to a day of data. If your RTO is 4 hours, you accept being down for up to 4 hours.
The Backup Checklist
- Database backups are automated
- File backups are automated
- Backups are stored on a different server/location
- At least one backup is off-site
- Backups are tested at least monthly
- Recovery plan is documented
- Recovery plan has been tested
- Someone is responsible for monitoring backup status
- Backup failure notifications are configured
- Retention policy is defined (how long to keep backups)
The Bottom Line
A backup you've never tested is a wish, not a plan.
Data loss is not a matter of "if" — it's a matter of "when." Every app that stores user data will eventually face a situation where backups are needed. The difference between a crisis and a minor inconvenience is whether you prepared in advance.
Set up automated backups today. Test the restore process this week. Document the recovery plan. Future you will be grateful.