Why is a lakehouse table format's time travel not a substitute for backups?

## What time travel actually protects against One thing, very well: a **logical** error on an otherwise healthy table. Someone ran a merge with an inverted predicate; a backfill double-loaded a month; a schema-mangling job wrote garbage. The bad state is a commit, the good state is the commit before it, and rollback re-points the table at the good file set in seconds. No restore, no downtime, no data movement. That is a genuinely superior answer to the classic warehouse restore, and it is why teams reach for it first. ## The failures it does not survive Every one of these takes the history down with the table: - **Storage loss.** The bucket or container is deleted, corrupted, or lost with a region. Old snapshots hold references, not copies, so their files are gone too. - **Purging drops.** A `DROP TABLE` that also removes data, or a lifecycle rule that deletes objects under the table prefix, leaves nothing for any snapshot to reference. - **Credential compromise or a hostile actor.** Anything that can delete the current data can delete the historical data — same bucket, same permissions, same blast radius. Ransomware does not respect snapshots stored beside the data. - **Catalog loss.** If the pointer to current metadata lives in a catalog and the catalog entry is lost, the objects may survive while nothing knows what the table is. Backing up storage without backing up the catalog is a half backup. - **Expiry.** Maintenance ran; the versions you wanted are gone. Self-inflicted, common, and permanent. - **Late detection.** A corruption discovered two months later, on a table with a two-week retention, has no version to return to at all. ## Retention is an RPO, and a short one Stating it as a recovery objective clarifies the argument: retention is the maximum age of a state you can return to, and it is usually days. Backup policies for important data are usually measured in months, with tiers, and with copies that live somewhere a compromise of the primary account cannot reach. Those are different requirements, and one does not imply the other. ## Rollback semantics worth knowing Rolling back typically appends a **new** commit that re-points the table at an earlier file set, rather than erasing what happened. That is a feature — the incident stays auditable and the rollback itself is reversible — but it means rollback is not a way to make data disappear. If the requirement is "this data must not exist any more," you need the files rewritten and the referencing snapshots expired, not a rollback. ## What an actual protection design looks like Layer it, and be explicit about which layer covers which failure: 1. **Time travel and rollback** — bad writes, within retention, table intact. Fast, cheap, first line. 2. **Object versioning plus delete protection** on the storage — accidental and malicious object deletion. 3. **Cross-account or cross-region replication** of the table's storage — account compromise, region loss. A different account matters more than a different region for the compromise case. 4. **Catalog backup or a redeployable catalog** — so a restored bucket can be turned back into tables. 5. **Periodic independent copies of critical tables** — the answer to "we found it three months later." 6. **Rehearsed restores.** An untested restore path is a hypothesis. ## Answering the interview version The crisp framing is: time travel is *versioning*, not *backup*, because it protects the contents of the table from you, but does not protect the table from the platform. Say what it does cover, name two failure classes it cannot (loss of the storage, and detection after retention), and describe the second copy that does cover them. Candidates who claim rollback makes backups unnecessary are describing a platform with a single point of failure and have usually never restored anything.