Recovering data with Time Travel, Fail-safe, and cross-region replication

Snowflake's data recovery features center on Time Travel and Fail-safe, which let you query, clone, or restore historical data after it has changed or been deleted, and on the UNDROP command for instantly recovering dropped objects. Data Engineers must know the retention windows, edition-based limits, and cost implications tied to each mechanism to design proper recovery and compliance strategies.

1 · Learn the must-know

Time Travel default retention is 1 day for all editions/objects (0 days possible for transient/temporary tables), and up to 90 days only for permanent tables on Enterprise Edition and above, configured via DATA_RETENTION_TIME_IN_DAYS at account, database, schema, or table level.
Time Travel enables SELECT ... AT/BEFORE queries using TIMESTAMP, OFFSET, or STATEMENT to view historical data, plus UNDROP TABLE/SCHEMA/DATABASE and cloning objects as they existed at a past point in time.
Fail-safe provides a non-configurable 7-day recovery period after Time Travel expires, but data recovery during Fail-safe requires contacting Snowflake Support—it is not self-service and is intended only for disaster recovery, not routine restores.
Transient and temporary tables have no Fail-safe period (0 days), which reduces storage costs but also removes the extra recovery safety net beyond their Time Travel window.
Dropped objects remain recoverable via UNDROP only while still within the Time Travel retention period; once that window passes (or storage is purged), the object moves into Fail-safe and self-service undrop is no longer possible.
Increasing DATA_RETENTION_TIME_IN_DAYS raises storage costs because Snowflake must retain historical micro-partitions for both Time Travel and the subsequent Fail-safe period, so retention settings should balance recovery needs against storage expense.

3 · Keep going

Ready for more? Take a weighted mock or try free practice questions.