Backup, recovery, and durability

Lesson 4 of 4 in Lifecycle and Tiering.

Backup belongs in a store-design module rather than an operations appendix, because two numbers decide the store and the storage class before any product is chosen.

RPO — recovery point objective — is how much recent data you can afford to lose. An RPO of zero rules out every scheduled backup and demands synchronous replication or a replayable source. An RPO of 24 hours makes a nightly snapshot sufficient. RTO — recovery time objective — is how long you can afford to be unavailable. And here is the connection people miss: retrieval time is part of recovery time. An RTO of two hours is incompatible with a backup in Glacier Deep Archive, whose standard restore alone is about twelve hours. The cheapest gigabyte is the slowest to come back, and that is not a detail to discover during an incident.

It is also worth separating three ideas that get used interchangeably.

Durability is whether the bytes still exist. S3 Standard, Standard-IA and all the Glacier classes are designed for the same 99.999999999% durability, because they all replicate across at least three Availability Zones. Availability is whether you can reach them right now, and it is what the storage classes actually trade. Protection from your own actions is a third thing entirely — no durability figure stops an authorised DeleteObject, a DROP TABLE, or a pipeline bug that overwrites a year of partitions with empty files.

One Zone-IA is the exception that proves the rule: it is the only class that lowers the durability expectation, because a single Availability Zone's loss takes the data with it. Everything else on the list is trading availability and access cost, not durability.

What each control actually protects against — the rows are not substitutes for each other
Control	Overwrite or accidental delete	Deliberate destruction	Region loss	Typical recovery time
S3 Versioning	yes — the previous bytes are kept	no — versions are deletable	no	minutes, with Batch Operations
S3 Object Lock (compliance)	yes	yes — undeletable until retention expires	no	minutes
Cross-Region replication	only if the destination is versioned	partly — a separate account helps	yes	minutes to hours
AWS Backup + vault lock	yes	yes — recovery points are immutable	yes, with cross-Region copies	minutes to hours by store
Glacier Deep Archive copy	yes	partly — with Object Lock on it	no, unless replicated	about 12 hours, or 48 bulk
DynamoDB point-in-time recovery	yes — any second in 35 days	no — it can be switched off	no	minutes to hours, into a new table

Three mechanisms are worth knowing by their exact behaviour, because that is what a question tests.

AWS Backup turns backup from a per-service habit into a policy. A backup plan carries a schedule, a retention period, optional transition to cold storage, and cross-Region or cross-account copy rules, and it applies to DynamoDB, Aurora and RDS, Amazon Redshift, EBS, EFS, Amazon S3 and more through resource tags. The governance value is the point: one place that can answer "is this table backed up, to what retention, and who can delete the backups". Vault Lock then makes the recovery points themselves immutable, which is what stops a compromised administrator from deleting the backups before the data.

S3 Replication needs versioning on both sides and a role. It copies new objects; existing ones need batch replication explicitly. Three variants answer three different stems: cross-Region replication for a disaster-recovery copy or to put data near a consumer, same-Region replication for aggregating logs into one account or changing object ownership, and Replication Time Control when a replication window has to be measured — it replicates most objects in seconds and 99.99% within 15 minutes, backed by a service-level agreement, and emits metrics and events so a breach is visible. Note also that replication copies deletes only if you ask, and never replicates the deletion of a specific version.

S3 Object Lock writes a retain-until date or a legal hold onto an object version. In governance mode a privileged principal can shorten or remove it; in compliance mode nobody can, including the account root, until the date passes. It requires versioning, and it is the control that makes an S3 copy genuinely write-once — which is both the strength and the thing to think about twice, because a compliance-mode retention of seven years written by mistake is seven years of storage you cannot cancel.

Which protection does this requirement actually need?

Interactive decision tree — outcomes:

Versioning, plus Batch Operations to roll back
The previous bytes are already in the bucket, milliseconds away, and a Batch Operations job driven by an inventory report can copy the last good version back over thousands of keys in minutes. Pair it with a noncurrent-version expiration rule so the history does not become the bill, and remember it does not protect against a deliberate delete of the versions themselves.
AWS Backup with a plan and a retention period
A schedule, a retention, and one place to prove both. Recovery takes as long as the service’s restore takes, which is minutes to hours depending on the store — so check that figure against the objective rather than assuming it.
A Deep Archive copy — and a warm one as well
Deep Archive is the right home for years of retention nobody expects to read, and on its own it cannot serve a short recovery objective: a standard restore is about twelve hours. Keep the cheap cold copy for the compliance requirement and a warm copy for the recovery one; they are different requirements and deserve different copies.
Object Lock, or a locked backup vault
Compliance-mode Object Lock makes a version undeletable until its retain-until date by anyone, including the account root; Vault Lock does the same for recovery points. This is the only row in the matrix that survives a credential that intends the loss — and it is irreversible by design, so set the retention period deliberately.
Replication to another Region, ideally another account
Versioning on both sides, a replication role, and batch replication for the objects that already exist. A separate account also puts the copy outside the blast radius of the credentials that could destroy the original, which is the part a Region-only answer misses. Add Replication Time Control if the window has to be measurable.
A manual snapshot, or a table-format snapshot you do not expire
Automated snapshots cap at 35 days, so “reproduce the quarter-end state in five years” is a manual snapshot retained indefinitely, an AWS Backup plan with a long retention, or an Iceberg snapshot deliberately kept. Note that keeping a table-format snapshot also keeps every data file it references, so the storage is real.

Eleven nines does not mean what people use it to mean

The 99.999999999% figure is a durability design target for the bytes against hardware and facility failure. It says nothing about any of the following, each of which has destroyed data in a real lake:

An authorised delete. A DeleteObject from a role that was granted it is not a durability event. Nor is a DROP TABLE, a TRUNCATE, or a pipeline writing empty partitions over good ones.

A lifecycle rule you wrote. An expiration action is a deliberate instruction, carried out exactly as durably as everything else.

A Region or Availability Zone you chose. One Zone-IA is designed to lose the data with the zone, and that is the documented behaviour rather than a failure of it.

Your own code. The commonest cause of data loss in a lake is a job that ran successfully and did the wrong thing.

So the useful question in a design review is never "how durable is this class" — they are all the same except one — but "what is the second copy, where is it, who can delete it, and how long does it take to come back".

Key terms: RPO and RTO, Durability vs availability, S3 Replication, AWS Backup, S3 Object Lock

Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.