- Disaster recovery is how you bring the whole app back after a serious failure, within time and data-loss limits you agreed in advance.
- Plan for the likely disasters first: a deleted or corrupted database, a compromised cloud account and a bad deployment, not only a regional outage.
- Set two targets with the business: how long the app can be down (RTO) and how much recent data you can lose (RPO).
- For most small apps, backup and restore done well meets those targets; a standby copy in another region is for stricter ones.
- A written runbook and a timed drill turn backups into recovery; untested plans fail on the day.
What does disaster recovery mean for a small web app?
Disaster recovery is how you bring the whole app back after a serious failure, such as a deleted database, a compromised cloud account or a broken deployment, within limits on downtime and data loss that the business agreed in advance. For a small app it comes down to five things: recovery targets, a strategy that meets them, backups an attacker cannot delete, a written runbook, and drills that prove the plan works.
Having backups is only the starting point. What decides how a bad day goes is whether anyone knows which backup to use, how long a restore takes and who is allowed to start it. This is the planning our cloud and DevOps team does with clients before something goes wrong.
Which disasters should you plan for?
| What happens | What it breaks | What gets you back |
|---|---|---|
| A mistaken delete or a bad migration | Some or all data, instantly | Point-in-time restore of the database |
| A bug that corrupts data slowly | Data over days before anyone notices | Older backups kept long enough to go back |
| Ransomware or a stolen admin account | The servers and any backups the attacker can reach | Locked copies in a separate account |
| A server or data centre failure | The running app | Rebuilding from infrastructure code, or a database with automatic failover |
| A whole cloud region going down | Everything hosted in that region | Copies and, if needed, standby resources in another region |
Small businesses tend to plan for the last row and get hit by the first three.
What are RTO and RPO, and who should set them?
AWS defines the recovery time objective (RTO) as the maximum acceptable delay between an interruption and restoring service, and the recovery point objective (RPO) as the maximum acceptable time since the last data recovery point. In plain terms: how long can you be down, and how much recent work can you afford to lose?
These are business decisions. A booking app that loses a morning of reservations has a different answer from an internal reporting tool. AWS lists arbitrary or unrealistic targets, such as zero time to recover, among the common mistakes. Write the two targets down for each app, then pick the setup that meets them.
Which recovery strategy fits a small app?
| Strategy | What runs in the second location | Fits when |
|---|---|---|
| Backup and restore | Nothing; you rebuild from backups | Some hours of downtime are acceptable |
| Pilot light | Data is copied; core infrastructure is ready but mostly off | You need faster recovery from a regional outage |
| Warm standby | A scaled-down but working copy of the app | Downtime is expensive and must be short |
| Multi-site | The full app, serving traffic in several regions | Downtime is close to unacceptable |
AWS's disaster recovery whitepaper notes that for a well-architected, highly available workload, protecting against the loss of a single data centre may only require a backup and restore approach; the other three are for regional disasters or regulatory needs. That matches what we see for most small business apps.
What do managed databases give you for recovery?
Point-in-time recovery is the feature that saves most bad days. On Amazon RDS, automated backups can be kept for between 0 and 35 days, and setting 0 turns them off; the default is seven days when the database is created in the console but one day through the API, so check yours. RDS uploads transaction logs to S3 every five minutes, which is what lets you restore to a moment just before the mistake.
On your own server you choose the method. PostgreSQL's documentation describes three approaches: SQL dumps, file system level backups and continuous archiving, and only the last gives you point-in-time recovery. For uploaded files on Amazon S3, versioning turns a delete into a delete marker so you can restore the previous version.
How do you keep backups out of an attacker's reach?
CISA's ransomware guide recommends offline, encrypted backups, because many ransomware variants look for accessible backups and delete or encrypt them. In the cloud, the equivalent is a copy that the production account cannot delete.
- Locked backup vaults. AWS Backup Vault Lock gives a write-once, read-many configuration that stops early deletion, even by privileged users, once the lock is in compliance mode.
- A separate account or region. AWS Backup can copy backups to other regions as part of a scheduled plan.
- Few people with delete rights, all using multi-factor sign-in, and an alert whenever a backup is removed.
What should the recovery runbook contain?
- Who decides: the person who declares a disaster, their deputy and how to reach both.
- Access that still works: emergency admin accounts stored safely outside the systems that might be down.
- The order of work: stop deployments, restore the database, then files, then the app, then switch DNS.
- How to rebuild servers: CISA advises keeping infrastructure code under version control and golden images of critical systems so they can be redeployed quickly.
- Where the secrets are, and which ones must be rotated if an account was compromised.
- What to tell customers, with a short status message ready to send.
What does a recovery drill look like?
AWS's reliability guidance lists the habits that fail on the day: restoring a backup without querying any data, assuming that a backup exists, and assuming the restore fits within your RTO. A useful drill follows the runbook into a separate environment, checks real records such as recent orders and logins, times the whole process against the RTO, and notes the age of the newest data against the RPO. AWS Backup can also run restore testing on a schedule and report restore job duration times.
Pair the drills with alerts for missing or unusually small backups, as covered in our guide to monitoring a production web app. If you have just inherited an app, our checklist for taking over a codebase puts this near the top, and regular drills are part of our maintenance and security service.
Frequently asked questions
Is a database replica the same as a backup?
No. A replica copies every change almost instantly, including a mistaken delete or data scrambled by a bug or ransomware. It helps you recover from a failed server, but only a backup taken before the problem lets you go back in time. Most production apps need both.
Who should be allowed to declare a disaster?
Name one person and a deputy in the runbook, usually the product owner or technical lead, and give them the authority to stop deployments, put the app into maintenance mode and start a restore. Recovery goes wrong when several people act at once or wait for permission that nobody is sure how to give.
How often should we run a recovery drill?
On a fixed schedule, such as every quarter, and after any major change to the database, hosting or storage. Rotate who leads it, so the plan does not depend on one engineer. Each drill should end with a short note on timings, problems and the changes made to the runbook.
What does disaster recovery cost for a small app?
For backup and restore, mostly storage and a few hours of engineering for setup and drills. Costs rise with the strategy: a standby copy of the app in another region means paying for servers that sit idle most of the time. Choose the strategy from your recovery targets, not the other way round.
Does the plan need to cover services like payments and email?
Yes, even though you cannot restore their systems. Record which accounts you use, who owns them, the webhook and DNS settings that point to your app, and how to export your data. When you rebuild in a new place, those settings are what reconnect payments, email and sign-in.
Last updated