Home / Data Platform / Lakehouse

Data PlatformRunbookIntermediate

Delta Lake backup and recovery: time travel, RESTORE, deep clone and storage protection

Recover from bad writes, accidental deletes and storage loss in a Delta lakehouse. Covers time travel and RESTORE, what VACUUM does to your recovery window, deep clone backups, and storage soft delete and versioning.

Deepak Bhardwaj2 min read

Applies toDelta Lake on Databricks, Fabric, Synapse and open-source Spark; ADLS Gen2, S3, GCS

Recovery layers

Problem Tool Window
Bad UPDATE, MERGE or DELETE Time travel + RESTORE Limited by VACUUM retention (7 days by default)
Dropped managed table (Unity Catalog) UNDROP TABLE 7 days
Corrupted or deleted files, or a deleted container Storage soft delete or versioning Your storage setting
Region loss Deep clone or geo-replication to another region Your clone schedule

1. Time travel and RESTORE

DESCRIBE HISTORY prod.sales.orders;

SELECT count(*) FROM prod.sales.orders VERSION AS OF 412;
SELECT count(*) FROM prod.sales.orders TIMESTAMP AS OF '2026-10-21T22:00:00';

RESTORE TABLE prod.sales.orders TO VERSION AS OF 412;

RESTORE is itself a new commit, so you can undo it too.

2. Mind VACUUM and log retention

  • VACUUM deletes data files older than delta.deletedFileRetentionDuration (default 7 days). After that, older versions can't be read.
  • delta.logRetentionDuration (default 30 days) controls how long the history is kept.
  • For important tables, set a longer retention:
ALTER TABLE prod.sales.orders SET TBLPROPERTIES (
  'delta.deletedFileRetentionDuration' = 'interval 30 days',
  'delta.logRetentionDuration' = 'interval 60 days');

Longer retention means more storage. Do this per table, not across the whole lake.

3. Deep clone as a backup

CREATE OR REPLACE TABLE backup.sales.orders_daily
DEEP CLONE prod.sales.orders;
  • Independent copy of data and metadata. Later runs are incremental.
  • Put the backup catalog's storage in a different storage account or bucket (another region for DR) with tighter delete permissions.
  • A shallow clone references the source files, so it is not a backup.

4. Storage-level protection

  • ADLS Gen2: blob soft delete plus container soft delete. Point-in-time restore isn't supported with hierarchical namespace, so rely on soft delete and copies.
  • S3: versioning plus Object Lock for backup buckets, and lifecycle rules for old versions.
  • Deny Delete permissions to everything except the platform's managed identity.

5. Runbook: bad overnight load

  1. Pause the pipeline that writes the table.
  2. DESCRIBE HISTORY to find the last good version (check operationMetrics and the job ID).
  3. Check that version with sample queries and row counts.
  4. RESTORE TABLE ... TO VERSION AS OF n.
  5. Restore the matching downstream tables (silver and gold) or rerun them from the restored version.
  6. Fix the job, then resume.

Warning

Never run VACUUM ... RETAIN 0 HOURS (with the retention check disabled) on production tables. It deletes your recovery window immediately and can corrupt concurrent readers.

Related fixes