Backup and Disaster Recovery in 2026: RPO vs RTO, 3-2-1-1-0, Real Costs

Every backup system I have ever inherited was described to me as "fine". Fine usually meant a cron job that had succeeded, at some point, and a bucket that contained files. Nobody had restored from it. This post is the version of the conversation I wish I had earlier in my career: what RPO and RTO actually mean, how the four standard disaster recovery strategies trade money for minutes, why the 3-2-1 backup rule grew two extra digits, what immutable backups protect against (and what they don't), and what changes when the thing you are recovering is a Kubernetes cluster rather than a database server.

RPO vs RTO: what is the difference?

Two numbers, two different questions.

RPO (recovery point objective) is how much data you can afford to lose, measured backwards in time from the failure. NIST's glossary, quoting SP 800-34 Rev. 1, defines it as "the point in time to which data must be recovered after an outage." Back up nightly at 02:00, lose the database at 23:00, and your real RPO that day was 21 hours.

RTO (recovery time objective) is how long you can be down. NIST defines it as the overall length of time a system's components can be in the recovery phase before the outage starts to hurt the organisation's mission. It is measured forwards from the failure until the service works again, which includes noticing, deciding, provisioning, restoring and checking.

The practical difference: RPO is mostly decided by how often you copy data and where to. RTO is mostly decided by how much of the recovery is automated and how much already exists before the disaster. You can have a one-minute RPO and a two-day RTO (continuous replication into a region where nothing else is deployed), or the reverse (a fully scripted rebuild from a nightly snapshot). Both numbers should be written per workload, signed off by whoever owns the business risk, and kept in the same repository as the runbook. AWS's Well-Architected guidance warns against implementing a strategy more stringent than you need, because each step down in RTO and RPO costs real money.

The four disaster recovery strategies and what they cost

AWS's reliability pillar lists four strategies "in increasing order of cost and complexity, and decreasing order of RTO and RPO". The ranges below are AWS's published targets for a multi-region setup, not guarantees, and they generalise reasonably well to other clouds.

Strategy	Typical RPO	Typical RTO	What runs in the recovery site	Ongoing cost
Backup and restore	Hours (PITR can reach about 5 minutes)	24 hours or less	Nothing but backup copies	Lowest: storage and copy traffic
Pilot light	Minutes	Tens of minutes	Replicated data stores; compute not deployed	Low: databases and storage always on
Warm standby	Seconds	Minutes	Scaled-down full stack serving nothing	Medium: a small copy of everything
Multi-site active/active	Near zero	Potentially zero	Full stack serving live traffic	Highest: two production estates plus conflict handling

Sources: AWS Well-Architected REL13-BP02 for the RPO and RTO ranges; the AWS DR whitepaper for what runs where. Cost column is the ordering AWS gives, not a price.

Two things stand out. First, the difference between pilot light and warm standby is not size, it is whether the recovery site can serve a request without anyone deploying anything. Second, AWS recommends failing over with data plane operations only, because control planes (launching instances, editing DNS weights, Auto Scaling) have lower availability goals and are exactly what is under stress during a regional event. If your failover runbook starts with "create the EKS cluster", you have a backup and restore strategy with a pilot light label on it. I wrote up the DNS side of this in how to build multi-region failover with Route 53 and Cloud DNS, and the official postmortems from the 2025 and 2026 cloud outages are a good reality check on how often the control plane is the thing that broke.

The most common mistake I see is treating replication as backup. AWS says it plainly: continuous replication "will not protect you against data corruption or destruction" unless you also keep point-in-time copies. A dropped table replicates in milliseconds.

What is the 3-2-1-1-0 backup rule?

The classic 3-2-1 rule is three copies of your data, on two different media, with one copy off-site. Veeam's best practice guide extends it to 3-2-1-1-0: the extra 1 is a copy that is offline, air-gapped or immutable, and the 0 is zero errors when you verify that backups actually restore.

In cloud terms I translate it like this:

• 3 copies: production, a primary backup, and a backup copy.
• 2 media: in a cloud world "media" means failure domains with different blast radii: block snapshots plus object storage, or two storage services that do not share credentials.
• 1 off-site: a different region, and ideally a different account or provider.
• 1 immutable: a copy nobody can delete before its retention expires, including you, including root.
• 0 errors: an automated restore that runs on a schedule and fails loudly.

The second 1 exists because attackers learned to go for the backups first. Veeam's 2024 trends report put attempts on backup repositories at 96 percent of attacks. The good news in 2026 is that backups are working more often when they survive. Sophos's State of Ransomware 2026, a survey of 2,158 leaders at organisations hit in the previous year, found 66 percent recovered encrypted data from backups, up 12 points on 2025, while 48 percent still paid a ransom (median payment $769,000) and the average recovery cost rose 11 percent to $1.7 million.

Do immutable backups stop ransomware?

They stop one specific thing: someone with your credentials deleting or overwriting the backup before you need it. That is the attack that turns an incident into a catastrophe, so it is worth doing properly.

On AWS the building block is S3 Object Lock. It requires versioning and has two modes. In governance mode, users with s3:BypassGovernanceRetention can still delete. In compliance mode, no user can delete or shorten retention, "including the root user", and AWS notes the only way to remove a compliance-locked object early is to close the account. AWS suggests testing in governance mode first; a typo in a compliance retention period is an expensive typo.

# aws-cli v2. Create a bucket with Object Lock, then a 30-day compliance default.
# Test with "GOVERNANCE" first; COMPLIANCE cannot be shortened or removed, even by root.
BUCKET=acme-backups-immutable
REGION=eu-west-1

aws s3api create-bucket \
  --bucket "$BUCKET" \
  --region "$REGION" \
  --create-bucket-configuration LocationConstraint="$REGION" \
  --object-lock-enabled-for-bucket          # also turns on versioning

aws s3api put-object-lock-configuration \
  --bucket "$BUCKET" \
  --object-lock-configuration '{
    "ObjectLockEnabled": "Enabled",
    "Rule": { "DefaultRetention": { "Mode": "COMPLIANCE", "Days": 30 } }
  }'

# Check what you actually configured before writing anything to it
aws s3api get-object-lock-configuration --bucket "$BUCKET"

A simple DELETE against a locked bucket still returns 200 and adds a delete marker; the locked version underneath survives. That matters for backup tools that expire old backups: the tool thinks it deleted something, you keep paying for it until the lock lapses. Set the lock a little longer than the tool's retention and budget for the overlap.

Managed equivalents exist. AWS Backup added EKS support in November 2025 (cluster state and persistent volumes, with restores of a whole cluster, a namespace or a single volume) and, in March 2026, logically air-gapped vaults for those EKS backups, which are locked by default and can live in a separate account.

What immutability does not do: it does not stop data theft and extortion, it does not make a backup restorable, and it does not help if the attacker was in your environment for a month and your retention is two weeks. The figure that worries me most from this year's surveys is Veeam's. Its Data Trust and Resilience Report 2026, based on more than 900 senior IT, security and risk leaders, found 90 percent confident in their ability to recover, while among organisations hit by ransomware only 28 percent fully recovered all affected data, and the average recovered was 72 percent. Vendor survey, but the gap between confidence and outcome is the whole story of backups.

How often should you test backup restores?

More often than you do now, and automatically. The 0 in 3-2-1-1-0 is the digit everyone skips.

GitLab's January 2017 postmortem is still the best teaching document on this. They lost roughly six hours of production data, at least 5,000 projects, 5,000 comments and roughly 700 users, because every layer had failed quietly: pg_dump 9.2 was running against a 9.6 database and producing nothing, failure emails were rejected because DMARC was not set up, disk snapshots were not enabled on the database servers, and in their words nobody was responsible for testing the procedure. Every one of those would have been caught by a weekly restore into a scratch environment.

The counterexample is UniSuper in May 2024. A parameter left blank in an internal Google tool gave the customer's VMware Engine private cloud a one-year term, and it was deleted when the year ended. Google's incident report credits backups held in Cloud Storage, "along with third party backup software", for the recovery, which still took several days of round-the-clock work. Backups saved them; rebuilding everything around the data is what took days.

What a restore test should prove, in order of how often it gets skipped:

1. The backup exists and is the size you expect.
2. It restores into a clean environment without manual fixes.
3. The application starts against the restored data and passes a smoke test.
4. The elapsed time fits inside your RTO, measured from "we declare a disaster", not from "the restore command started".
5. Someone other than the author can run it from the runbook.

AWS's whitepaper suggests a scheduled restore job triggered after each backup, which doubles as a warm copy if the control plane is unavailable later. I'd add a quarterly game day where the runbook's author is not allowed to type; I covered the tooling in chaos engineering in 2026.

What does a Kubernetes backup need to include?

A Kubernetes cluster has three kinds of state, and most teams back up one of them.

• Desired state (manifests). If you run GitOps, Git already holds most of this, which is a good start and not a backup. Git does not hold Secrets you created by hand, objects that controllers generate, or CRD instances some operator wrote at runtime.
• Cluster state (etcd). On self-managed clusters, take etcd snapshots and restore them with etcdutl, which the Kubernetes docs describe as the tool for restoring snapshots. On EKS, GKE or AKS you do not have etcd access, so you back up through the API instead.
• Persistent data (volumes). PersistentVolumes, plus anything outside the cluster the apps depend on: managed databases, object storage, DNS, IAM, certificates.

Velero is the usual open-source answer for the API objects and the volumes. The current release is v1.18.4 (September 2026). Two recent changes matter for planning. Velero 1.17 removed the Restic path for new file system backups (you can still restore old Restic backups until 1.19) and moved fs-backup onto Kopia data mover pods. Velero 1.18 added concurrent backups, glob patterns for namespace filters, and cache volumes for data movers. The piece that changes your DR posture is CSI snapshot data movement: a cloud disk snapshot lives in the same region and account as the disk, so Velero's data mover copies the snapshot contents into object storage, where Object Lock and cross-region replication can protect it. The Velero migration docs say the AWS and Azure plugins cannot migrate snapshot data between regions; data in object storage can. I walk through the full setup in the companion guide, how to back up and restore Kubernetes with Velero.

The restore order is where Kubernetes DR plans usually fall apart. You need a cluster, its add-ons, CRDs, storage classes with the same names, the secrets backend, and DNS before the app restore means anything. That is infrastructure as code, not backup, and it is why the Terraform state bucket deserves the same immutable treatment as the data. An AI agent with kubectl delete namespace rights is one more reason to keep a copy it cannot touch.

FAQ

What is a good RPO and RTO?

There is no universal good value; it is whatever the business will pay for. As a starting point, many teams set hours of RPO and a day of RTO for internal tools (backup and restore), minutes for customer-facing systems (pilot light or warm standby), and reserve near-zero targets for the few services where downtime directly stops revenue.

Is replication the same as backup?

No. Replication copies every change, including deletions, corruption and encrypted files, to the replica within seconds. A backup is a point-in-time copy you can go back to. You need both if your RPO is short, because replication covers infrastructure loss and backups cover data loss.

What is the difference between pilot light and warm standby?

Pilot light keeps data replicated in the recovery site but does not run application servers, so it cannot serve traffic until you deploy them. Warm standby runs a smaller but complete copy of the stack, so it can serve traffic immediately and only needs to scale up. Warm standby costs more and recovers faster.

Are immutable backups enough to recover from ransomware?

They make sure a copy survives, which is necessary but not sufficient. You also need retention longer than the likely time an attacker was inside, credentials for the backup account that are separate from production, and restore tests that prove the copy works. Immutability does nothing about stolen data.

This quarter I would do three things, in this order: write down RPO and RTO for the five services that matter most and get someone with budget to sign them; move one backup copy into a separate account with Object Lock in governance mode, then compliance once the retention is right; and schedule an automated restore that fails a pipeline when it breaks. The fourth thing, a game day with a stopwatch, tends to produce the most uncomfortable and most useful number of the year.

Related: Cloud Outages 2025-2026: What 7 Official Postmortems Actually Teach, How to Build Multi-Region Failover with Route 53 and Cloud DNS (2026) and How to Write a Blameless Postmortem: Template and Examples (2026).