Your time travel expires in 7 days, not 30

Two retention clocks control one rewind

Your rewind is 7 days, not 30. Delta Lake time travel and RESTORE reach back only as far as BOTH the transaction log and the deleted data files survive. delta.logRetentionDuration (default interval 30 days) controls how long table history is kept; delta.deletedFileRetentionDuration (default interval 7 days) controls the threshold VACUUM uses to physically delete data files no longer referenced by the current version. To query a previous table version, you must retain both the log and the data files for that version (official docs).

On Databricks Runtime 18.0 and above, time travel queries are blocked if they request a version older than the deletedFileRetentionDuration table property; for Unity Catalog managed tables this applies from Databricks Runtime 12.2. VACUUM never touches the log — log files are deleted automatically and asynchronously after checkpoint operations and are not governed by VACUUM — but once VACUUM removes a version's data files, the log entry for that version points at files that no longer exist.

OSS Delta Lake has the same defaults and machinery (interval 30 days log, interval 1 week deleted-file) — this is not Databricks-only behavior.

Illustrative walkthrough

Reproducible, idempotent setup:

CREATE OR REPLACE TABLE demo.orders_rewind (order_id BIGINT, amount DOUBLE, dt DATE);
INSERT INTO demo.orders_rewind VALUES (1, 99.50, DATE '2026-09-01'), (2, 149.00, DATE '2026-09-02');  -- version 0
UPDATE demo.orders_rewind SET amount = 109.50 WHERE order_id = 1;  -- version 1
DELETE FROM demo.orders_rewind WHERE order_id = 2;  -- version 2
SELECT version, operation FROM (DESCRIBE HISTORY demo.orders_rewind) ORDER BY version;  -- expected output: 0/WRITE, 1/UPDATE, 2/DELETE
SELECT * FROM demo.orders_rewind VERSION AS OF 0 ORDER BY order_id;  -- expected output: 2 rows: (1, 99.50), (2, 149.00)

Then the trap

VACUUM demo.orders_rewind RETAIN 24 HOURS;

After this, version 0's data files are physically gone while the log still lists version 0. The query fails on missing files; on DBR 18+ it is blocked outright.

What is guaranteed by the docs is the loss of reachability (“If you run a VACUUM on a Delta table, you lose the ability to time travel back to a version older than the specified data retention period.” / “The ability to query table versions older than the retention period is lost after running VACUUM.”) — not any specific error message.

The policy fix: set BOTH windows before you need them

ALTER TABLE demo.orders_rewind SET TBLPROPERTIES ('delta.deletedFileRetentionDuration' = 'interval 30 days', 'delta.logRetentionDuration' = 'interval 30 days');
-- defaults for NEW tables in this session:
SET spark.databricks.delta.properties.defaults.deletedFileRetentionDuration = 'interval 30 days';
SET spark.databricks.delta.properties.defaults.logRetentionDuration = 'interval 30 days';

Note: on Databricks Runtime 18.0+, logRetentionDuration must be greater than or equal to deletedFileRetentionDuration.

Saveable diagnostic query

SHOW TBLPROPERTIES demo.orders_rewind ('delta.deletedFileRetentionDuration', 'delta.logRetentionDuration');
DESCRIBE HISTORY demo.orders_rewind LIMIT 3;

These tell you both retention windows and the oldest version still listed. If the rewind you need exceeds either property, the rewind is already impossible: fix the properties first.

Use this when

1. You run GDPR/right-to-erasure workflows: the 7-day default is your friend — deleted data becomes physically unqueryable fast, and the docs pair deletion with VACUUM.
2. Your rollback/audit SLA needs a 30-day rewind: set BOTH delta.deletedFileRetentionDuration and delta.logRetentionDuration to interval 30 days (they must match; on DBR 18+ the log window must be >= the deleted-file window).

Avoid this when

1. Raising deletedFileRetentionDuration on high-churn tables “just in case”: you pay storage for every deleted file retained, and VACUUM automation respects your configured window, so the bill compounds.
2. Running VACUUM ... RETAIN 24 HOURS (or any retention below your rewind SLA) on a table anyone might time-travel: the rewind dies the moment the files are gone, permanently.