Cloud backup and disaster recovery, explained

One of the quiet wins of a cloud migration is that real disaster recovery, the kind that used to require a second data centre, becomes something a small business can actually afford. Provided you know which tier you are buying and why.

Backup and DR are different products

They get conflated because both involve copies of your data, but they answer different questions:

• Backup answers: can we get the data back? A point-in-time copy you can restore after deletion, corruption, ransomware, or a failed change.
• Disaster recovery answers: how fast is the business running again? Data plus the compute, networking, DNS, and runbook to serve customers when the primary environment is gone.

You can have excellent backups and terrible DR: every byte safe in another region, and a two-week outage because nobody can rebuild the environment that reads those bytes. Backup is a component of DR, never a substitute for it.

The two numbers that drive everything

Before comparing architectures, put numbers on two questions per system:

• RPO (recovery point objective): how much recent data can we afford to lose? Nightly backups give an RPO of up to 24 hours. Continuous replication gives seconds.
• RTO (recovery time objective): how long can we afford to be down? “Restore from backups” is often hours to a day. A hot standby is minutes.

Derive them from the cost of downtime, honestly. An internal reporting tool might tolerate RPO 24h / RTO 2 days. The order pipeline of an e-commerce business might justify RPO of minutes / RTO under an hour. Not everything deserves the same tier, and pretending it does is how DR budgets die: classify systems into two or three groups and buy each group the tier it earns.

The four tiers

Cloud DR strategies form a ladder. Each rung buys shorter recovery for more standing cost. (Same-region resilience across availability zones is table stakes and handles hardware failure; the tiers below are about losing a whole region or environment, which is where high availability ends and DR begins.)

Tier	How it works	Typical RTO	Typical RPO	Standing cost
Backup and restore	Backups in another region; rebuild everything when disaster hits	Hours to days	Since last backup (hours to 24h)	Storage only: tens of $/mo for most SMBs
Pilot light	Data replicates continuously; minimal core (database replica) runs; app servers exist as templates, turned off	Tens of minutes to a few hours	Minutes	Replica database + storage: small fraction of prod
Warm standby	A scaled-down but complete copy runs in the recovery region; scale it up and repoint DNS to fail over	Minutes to an hour	Seconds to minutes	Roughly 30 to 60% of prod added
Hot standby (multi-site active-active)	Full capacity in both regions, both serving traffic; failover is routing	Near zero	Near zero	Roughly 2x prod, plus real engineering complexity

Two honest observations from the field:

• Most SMBs belong on the first two rungs. Disciplined backup-and-restore with rehearsed runbooks, or a pilot light for the database-centric core, covers the realistic risk at a price the business will actually keep paying. The step up to warm standby should be justified by a downtime cost number, not by unease.
• Active-active is a lifestyle, not a checkbox. Serving from two regions raises hard questions about data consistency, session routing, and write conflicts. Teams that need it know they need it; everyone else is better served one rung down. The same discipline applies during migration cutovers, where the zero-downtime playbook uses the same replication ideas.

Getting the backup layer right

Whatever tier you choose sits on backups, and the details decide whether they hold up:

• Use the managed engine. AWS Backup, Azure Backup, and GCP’s Backup and DR service centralize scheduling, retention, and monitoring across VMs, disks, databases, and file systems. Snapshots land in cheap object storage.
• Follow 3-2-1, cloud edition: production data, backups in-region, and a copy in a second region and a separate account or subscription. The second account matters more than people expect: it means one compromised credential cannot encrypt production and delete the backups in the same afternoon.
• Make copies immutable. S3 Object Lock, Azure immutable blob storage, and GCS retention locks make backups undeletable for a set period, which is precisely what ransomware operators go after. This is a checkbox now; check it.
• Match frequency to RPO per system. Databases usually need point-in-time recovery (continuous WAL/log archiving), not just nightly snapshots. Managed databases include this; verify the retention window matches your number.
• Back up the environment, not just the data. If your network, servers, and configuration exist as infrastructure as code, the recovery region is a deploy plus a data restore, and your RTO drops by the days it would take to rebuild by memory.

Cost, worked roughly

For a typical small production estate (a few VMs, a 200 GB database, 2 TB of files), the ladder prices out roughly like this: cross-region immutable backups land in the tens of dollars per month. Pilot light adds a small replica database instance, often $100 to 300 per month. Warm standby adds scaled-down copies of the app tier on top. Hot standby doubles the infrastructure line. Set those against your downtime number and the right rung is usually obvious; if the numbers are murky, start with the cost estimation method and price two tiers side by side.

Watch two line items: cross-region replication traffic is billed as inter-region transfer (an egress-fee cousin, roughly $0.02 per GB), and long retention periods quietly accumulate; lifecycle rules that age old backups into archive tiers keep the storage line flat.

Testing: the part that makes it real

An untested DR plan is a document, not a capability. The failure modes are mundane: the restore that needs a KMS key nobody exported, the runbook referencing a person who left, the DNS change that needs an approval nobody can grant at 3 a.m.

• Restore tests, monthly or quarterly: restore the database backup to a temporary instance, run validation queries, tear it down. Automate it and alert on failure; this also continuously proves your backups are not silently broken.
• DR exercises, once or twice a year: actually stand up the recovery environment, fail over a test copy of traffic, and time it. The measured number is your real RTO; put it next to the objective and close the gap deliberately.
• After every major change: new database, new region, new critical service means the runbook is stale until re-tested.

FAQ

What is the difference between RPO and RTO?

RPO (recovery point objective) is the maximum data loss you accept, measured backwards from the incident: nightly backups mean an RPO of up to 24 hours. RTO (recovery time objective) is the maximum time until service is restored. They are independent: continuous database replication can give an RPO of seconds while your RTO is still hours because rebuilding the application environment takes that long.

Are cloud provider backups enough on their own?

Provider snapshot services (AWS Backup, Azure Backup, GCP Backup and DR) are a solid engine, but the defaults are not a strategy. You still need to decide scope and frequency against your RPO, keep copies in a second region and ideally a second account so one compromised credential cannot delete production and backups together, make copies immutable against ransomware, and run restore tests. The provider protects against its hardware failing; the riskier failure modes are deletion, ransomware, and account compromise.

What does a reasonable DR setup cost for a small business?

Versioned, cross-region, immutable backups for a modest estate typically run tens to a couple hundred dollars per month, mostly object storage. A pilot light (replicated data plus infrastructure templates, compute off) adds modestly on top. Warm standby roughly adds 30 to 60 percent of the production bill, and hot standby about doubles it. The right spend follows from your honest cost of downtime, not from what an enterprise reference architecture recommends.

How often should we test recovery?

Restore a database backup to a temporary instance and verify it monthly or quarterly, ideally automated. Run a full DR exercise (stand up the environment in the recovery region, fail over a test copy of traffic, measure the real RTO) once or twice a year, and after any major architecture change. An untested backup is a hope, and the test that finds the missing runbook step costs a few hours; the incident that finds it costs the business.

---

Not sure which tier your systems actually earn, or whether today’s backups would survive a bad week? Talk to a Webisoft cloud engineer. We’ll map your RPO and RTO per system, price the sensible tier, and help you run the first real restore test.