
Cheapest disaster recovery for startups: what each strategy costs
March 26, 2026
Aron Wagner
CEO & Co-Founder
The cheapest disaster recovery strategy that works for a startup is backup and restore: automated copies of your data somewhere production can't reach, servers you can rebuild from code, and a restore you've actually timed. For a small stack on our rate card, that's $26.56 a month. Keeping standby servers running costs three to four times as much, and most startups don't need that yet.
A backup you've never restored isn't a backup. It's a hope. Anything beyond that mostly buys you speed.
What's the cheapest disaster recovery strategy for a startup?
AWS's disaster recovery whitepaper describes four strategies, "ranging from the low cost and low complexity of making backups to more complex strategies using multiple active Regions." They apply on any cloud. In order of cost:
- Backup and restore. Copies of your data live somewhere else. When disaster hits, you build new servers and restore onto them.
- Pilot light. Your database keeps a live copy running in a second location. Everything else stays off until you need it. As AWS puts it, a pilot light "minimizes the ongoing cost of disaster recovery by minimizing the active resources."
- Warm standby. "A scaled down, but fully functional, copy of your production environment" runs all the time, so recovery means scaling it up and pointing traffic at it.
- Multi-site active/active. Two full copies serve traffic at once. AWS calls it "the most complex and costly approach to disaster recovery," and in return recovery time drops to near zero.
The whitepaper also says that if your risk is losing one data center, "you may only require a backup and restore approach."
How much downtime and data loss can you live with?
Two numbers decide which strategy you need. AWS defines them this way:
- Recovery time objective (RTO) is "the maximum acceptable delay between the interruption of service and restoration of service."
- Recovery point objective (RPO) is "the maximum acceptable amount of time since the last data recovery point."
In plain terms: how many hours can the product be down before customers leave, and how much recent data can you lose and re-enter by hand? If the honest answers are "a few hours" and "since last night," backup and restore covers you. If they're "minutes" and "nothing," you're paying for a standby.
What does each strategy cost for a small stack?
Here's one stack, priced on our public rate card on October 28, 2026, at monthly rates (hourly billing adds 2% to servers):
- Production: an app server (2 vCPU, 4 GB RAM, 50 GB disk) and a Postgres server of the same size with a 100 GB data volume.
- 500 GB of backups: a month of nightly database dumps plus a copy of your uploaded files.
Every strategy keeps the backups. A live replica copies your mistakes too: drop a table in production and it's gone from the replica moments later. So you still need yesterday's dump.
| Strategy | What runs in the second location | Per month |
|---|---|---|
| Backup and restore | 500 GB in object storage ($10) and a small backup server, 1 vCPU and 1 GB ($16.56) | $26.56 |
| Pilot light | The above, plus a database replica: 2 vCPU, 4 GB, 50 GB disk ($43.13) and a 100 GB volume ($10) | $79.69 |
| Warm standby | The above, plus a small app server, 1 vCPU and 2 GB ($21.56), and a public IP ($1) | $102.25 |
| Multi-site active/active | Backups, a full copy of production ($97.25) and a load balancer to split traffic ($12) | $135.81 |
The pilot light's replica is plain Postgres streaming replication you set up between your two servers.
When is a pilot light or warm standby worth paying for?
Price one bad day: what you'd lose in the hours a rebuild takes. Then compare that with a year of the standby's extra cost.
A pilot light adds $53.13 a month over backup and restore, or $637.50 a year. It skips the slowest part of a rebuild, restoring and checking the database. And if production dies, you lose only what the replica hadn't caught up on, not everything since last night. If a few hours down would cost you more than $637.50 in refunds, churn or missed sales, pay for it.
A warm standby adds $908.25 a year. It's worth it when even the time to start app servers is too long, usually once you have paying customers with an uptime promise in their contract.
Multi-site is for when any downtime at all costs more than running two of everything, plus the work of keeping data consistent in both places. Few startups are there.
How do you make backup and restore actually work?
Taking backups was never the hard part. Proving they restore is. Our backup guide treats it as three layers, and a real plan uses all three:
- Nightly copies off the server. Dump the database and push it, with your uploads, to object storage. Snapshots are for rolling back a disk before a risky deploy; nightly protection is a dump on a cron. If you run our managed databases, add a backup repository and set a schedule with retention. Backups are off until you do.
- One copy production can't delete. CISA's ransomware guide warns that "many ransomware variants attempt to find and subsequently delete or encrypt accessible backups." If your app server holds the keys to the backup bucket, so does anyone who breaks into it. Reverse it: the small backup server pulls dumps and files from production over SSH and holds the only bucket keys. Put that server and its bucket under a separate account. That's the $16.56 line in the table, and it's what makes the plan worth anything.
- A timed restore. Every quarter, build a fresh server, restore last night's dump onto it and check the data. Write down how long it took. That number is your real RTO, and it's usually longer than you'd guess.
Two habits make the restore fast. Keep your servers in code (our Terraform provider covers servers, networks and volumes), so rebuilding is a command and not an afternoon of clicking. And write the runbook while you're calm: which dump, which order, who does what. Nobody remembers it at 3 AM.
That's the US-CERT 3-2-1 rule in practice: three copies, two kinds of storage, one copy offsite.
What does it cost to get your data back?
The restore has a price too, and it depends on where your backups live. Storing 500 GB in Amazon S3 Standard costs $11.50 a month at $0.023 a GB in US East. Restoring it to anywhere outside AWS costs $36: the first 100 GB out each month is free, then it's $0.09 a GB. Replicating across AWS regions costs $0.01 to $0.02 a GB on top. Google Cloud Storage charges $0.12 a GiB to the internet.
$36 is one restore. Test a restore every quarter, as you should, and it's $144 a year, growing with every gigabyte you protect. Our egress fees explainer has the full math.
Where does American Cloud fit?
Our object storage is S3-compatible, so the AWS CLI, rclone and s3cmd work by changing the endpoint. It's $0.02 a GB a month with a $5 minimum, and we charge no egress fees: the restore, the quarterly test and the replication between servers add nothing to the bill. If production runs on another cloud, a bucket with us is an off-site copy outside the account and provider your servers run on.
Run your standby in a different region from production. We have three in the US: us-west-0, us-west-1 and us-central-0. And if a restore goes sideways, our support replies in under 2 minutes.
Start with the $26.56 plan, time your first restore, and let that number tell you whether you need more.