A surprising number of teams believe their cloud data is backed up because the provider advertises high durability. Durability and recoverability are different things. Durability means the provider is very unlikely to lose the bytes you stored. It says nothing about what happens when your own pipeline overwrites a table with garbage, or an engineer runs a delete against the wrong prefix. The provider will faithfully and durably preserve your mistake.

Getting this right means understanding what each protection mechanism covers, then layering them to match how your data actually gets damaged.

Four Mechanisms, Four Different Failures

Versioning keeps prior versions of an object when it is overwritten or deleted. It is excellent for accidental overwrites and deletes. It does not help if the whole bucket or account is deleted, and it can quietly grow storage costs because old versions accumulate unless you set a lifecycle rule to expire them.

Replication copies data to another region or account. It protects against a regional outage and, if configured to a separate account, against account compromise. The catch: most replication copies deletions and overwrites too, so a bad change can propagate faithfully to the replica. Replication is availability, not undo.

Snapshots and point-in-time recovery for databases and warehouses let you restore a table or store to an earlier moment. Retention windows vary and are limited, so check what your service actually offers and for how long.

Backups to an independent location are copies that your normal credentials cannot easily alter, ideally in a separate account with restricted write access. This is the layer that saves you from ransomware-style or insider scenarios and from “we deleted the production account.”

Start From the Failures, Not the Features

List the ways data realistically gets damaged in your environment, then check each one against the mechanisms above:

• A job overwrites good data with bad data.
• Someone deletes a dataset by mistake.
• A schema migration corrupts a table.
• A region has an extended outage.
• Credentials are compromised and data is deleted deliberately.
• A downstream consumer needs last quarter’s version of a table to reproduce a report.

In practice most incidents are the first three, which is why versioning and short-term point-in-time recovery earn their cost quickly, while cross-account backups cover the rare but catastrophic cases.

Set Recovery Targets Before Choosing Tools

Two numbers drive everything. Recovery point objective is how much recent data you can afford to lose. Recovery time objective is how long you can be without the data. A reporting warehouse that is rebuilt nightly from source may tolerate a day of loss and several hours of downtime. An operational dataset feeding customer-facing features may not. Write down both for each major dataset, agree them with the people who depend on the data, and let them determine how much protection you pay for.

Matching Protection to Data Type

Data type	Main risk	Sensible layers
Raw landing data (re-creatable from source)	Accidental deletion	Versioning with short expiry
Curated warehouse tables	Bad transformation	Point-in-time recovery, plus code-driven rebuild
Data with no upstream source	Permanent loss	Versioning, cross-account backup, tested restores
Regulated or sensitive data	Compromise, retention rules	Independent backup, access logging, documented retention
Reference and config tables	Silent edits	Versioning, change history in source control

Notice that re-creatable data needs less protection than people assume. If you can rebuild a table from raw files and tested code, the code and the raw files are what you protect.

A Realistic Example

Imagine a team whose daily pipeline writes a curated table. A code change introduces a join bug and, over two days, overwrites the table with duplicated rows. Finance notices totals look wrong. The team has versioning on the raw landing bucket and point-in-time recovery on the warehouse with a window of several days, so they restore the table to the state before the bad deploy, fix the join, and rerun from raw. Recovery takes an afternoon. Without the window, they would have been rebuilding from months of raw files, which is still possible but slow. The lesson is that the cheap, short-window layers handle the common failure.

Test Restores on a Schedule

An untested backup is a hypothesis. Pick a quarterly date, choose one dataset at random, and restore it into a scratch location. Time how long it takes, check the contents against a known-good count or checksum, and note anything that surprised you, such as missing permissions or a key that nobody could find. Teams that do this once usually discover at least one gap, and it is much better to find it on a quiet Tuesday.

Also protect the recovery path itself: store encryption keys and restore runbooks somewhere that does not depend on the system you are recovering.

Control the Cost of Keeping Copies

Versions and backups are not free. Set lifecycle rules that expire noncurrent versions after a period that matches your realistic detection time for problems, and move older backups to cheaper tiers where your recovery time allows. Check your provider’s current retrieval rules for archive tiers before relying on them for fast recovery.

Frequently Asked Questions

Does replication replace backups? No. Replication mostly copies whatever happens to the source, including deletions and corruption. It protects availability. Backups protect against bad changes and need to be independent.

How long should we keep object versions? Long enough to cover the time it takes your team to notice a problem. For many teams that is days to a few weeks. Choose a window, then adjust based on how quickly issues have historically been found.

Do we need to back up data we can rebuild from source? Often the rebuild path is the backup, provided the source data and transformation code are protected and the rebuild time meets your recovery target. Test the rebuild to confirm.

Can a backup be deleted by the same people who can delete the data? It should not be. Use a separate account or immutability features, where your provider supports them, so one compromised credential cannot remove both.

What should a restore runbook contain? Where backups live, who can access them, the exact steps to restore, how to validate the result, and who to notify. Keep it short and keep a copy outside the affected system.

Next Step

Pick your single most important dataset and answer three questions in writing: what is the worst realistic way it gets damaged, which layer would let you recover, and when did you last actually restore it? If the last answer is “never,” schedule a restore test this month.