Bird
Raised Fist0
Snowflakecloud~5 mins

Why Time Travel enables data recovery in Snowflake - Quick Recap

Choose your learning style10 modes available
Recall & Review
beginner
What is Time Travel in Snowflake?
Time Travel is a feature in Snowflake that lets you access historical data at any point within a defined retention period. It helps you recover data that was changed or deleted.
Click to reveal answer
beginner
How does Time Travel help recover deleted data?
Time Travel keeps snapshots of data before changes. If data is deleted, you can query the snapshot from before deletion and restore it.
Click to reveal answer
intermediate
What is the default retention period for Time Travel in Snowflake?
The default retention period is 1 day (24 hours), but it can be extended up to 90 days depending on your Snowflake edition and settings.
Click to reveal answer
intermediate
Why is Time Travel considered safer than manual backups?
Time Travel automatically keeps data history without extra work. It allows quick recovery without restoring from external backups, reducing downtime and errors.
Click to reveal answer
beginner
Can Time Travel recover data after a long period?
Only if the data change is within the retention period. After that, data history is removed and cannot be recovered using Time Travel.
Click to reveal answer
What does Snowflake's Time Travel feature allow you to do?
AEncrypt data at rest
BAutomatically delete old data
CAccess past versions of data within a retention period
DCreate new databases
What is the default Time Travel retention period in Snowflake?
A1 day
B90 days
C30 days
D7 days
If data was deleted 2 days ago, can Time Travel recover it with default settings?
ANo, Time Travel does not recover deleted data
BYes, always
CYes, but only if manually backed up
DNo, because default retention is 1 day
Why is Time Travel useful compared to manual backups?
AIt requires no extra backup steps and allows quick recovery
BIt deletes data faster
CIt encrypts data automatically
DIt creates more storage space
What happens to data history after the Time Travel retention period ends?
AIt is archived indefinitely
BIt is permanently removed and cannot be recovered
CIt is moved to a backup server
DIt is encrypted for security
Explain how Snowflake's Time Travel feature enables data recovery.
Think about how you can 'go back in time' to see old data versions.
You got /4 concepts.
    Describe the limitations of Time Travel for data recovery in Snowflake.
    Consider what happens when the 'time window' closes.
    You got /4 concepts.

      Practice

      (1/5)
      1. What is the main benefit of Snowflake's Time Travel feature?
      easy
      A. It automatically backs up data to an external system.
      B. It speeds up query performance by caching results.
      C. It encrypts data to enhance security.
      D. It allows you to recover data from a previous point in time.

      Solution

      1. Step 1: Understand Time Travel purpose

        Time Travel lets you access data as it was at a past time, enabling recovery.
      2. Step 2: Compare options

        Only recovering past data matches Time Travel's main benefit; others describe different features.
      3. Final Answer:

        It allows you to recover data from a previous point in time. -> Option D
      4. Quick Check:

        Time Travel = Data recovery [OK]
      Hint: Time Travel means going back to old data states [OK]
      Common Mistakes:
      • Confusing Time Travel with backup or encryption
      • Thinking it improves query speed
      • Assuming it stores data outside Snowflake
      2. Which SQL syntax correctly queries data from 2 hours ago using Time Travel?
      easy
      A. SELECT * FROM table BEFORE (TIMESTAMP => CURRENT_TIMESTAMP - INTERVAL '2' HOUR);
      B. SELECT * FROM table AT (TIMESTAMP => DATEADD(hour, -2, CURRENT_TIMESTAMP));
      C. SELECT * FROM table AT (OFFSET => -7200);
      D. SELECT * FROM table FOR TIME TRAVEL 2 HOURS AGO;

      Solution

      1. Step 1: Recall correct Time Travel syntax

        Snowflake uses AT (TIMESTAMP => ...) to query past data.
      2. Step 2: Analyze options

        SELECT * FROM table AT (TIMESTAMP => DATEADD(hour, -2, CURRENT_TIMESTAMP)); uses DATEADD to subtract 2 hours from current time correctly; others use invalid or unsupported syntax.
      3. Final Answer:

        SELECT * FROM table AT (TIMESTAMP => DATEADD(hour, -2, CURRENT_TIMESTAMP)); -> Option B
      4. Quick Check:

        Use AT (TIMESTAMP => ...) with DATEADD for past data [OK]
      Hint: Use AT (TIMESTAMP => DATEADD(...)) to query past data [OK]
      Common Mistakes:
      • Using unsupported keywords like BEFORE or FOR TIME TRAVEL
      • Incorrect interval syntax
      • Using OFFSET with negative seconds (not valid)
      3. Given the table users had a row deleted 1 hour ago, what will this query return?
      SELECT * FROM users AT (TIMESTAMP => DATEADD(hour, -1, CURRENT_TIMESTAMP));
      medium
      A. The table data including the deleted row as it was 1 hour ago.
      B. An error because Time Travel cannot query deleted rows.
      C. Only the deleted row from 1 hour ago.
      D. The table data as it is now, without the deleted row.

      Solution

      1. Step 1: Understand Time Travel query effect

        Querying with AT (TIMESTAMP => ...) shows data as it was at that time, including deleted rows.
      2. Step 2: Interpret the query

        The query asks for data 1 hour ago, so it returns all rows including the deleted one.
      3. Final Answer:

        The table data including the deleted row as it was 1 hour ago. -> Option A
      4. Quick Check:

        Time Travel shows past data including deleted rows [OK]
      Hint: Time Travel shows full past data, not just current state [OK]
      Common Mistakes:
      • Assuming deleted rows are inaccessible
      • Expecting only deleted rows returned
      • Thinking it causes query errors
      4. You tried to restore a dropped table using Time Travel but got an error. What is a likely cause?
      medium
      A. The Time Travel retention period has expired for that table.
      B. You used the wrong SQL syntax for Time Travel.
      C. The table was never created in the first place.
      D. Time Travel does not support restoring dropped tables.

      Solution

      1. Step 1: Recall Time Travel retention limits

        Time Travel keeps data only for a set retention period (default 1 day).
      2. Step 2: Analyze error cause

        If retention expired, data cannot be recovered, causing errors when restoring dropped tables.
      3. Final Answer:

        The Time Travel retention period has expired for that table. -> Option A
      4. Quick Check:

        Expired retention blocks recovery [OK]
      Hint: Check retention period before restoring dropped tables [OK]
      Common Mistakes:
      • Assuming Time Travel keeps data forever
      • Blaming syntax errors without checking retention
      • Thinking dropped tables can't be restored at all
      5. You accidentally updated many rows in a table 3 hours ago and want to recover the original data. Your Time Travel retention is 24 hours. Which approach correctly recovers the data?
      hard
      A. Run INSERT INTO table SELECT * FROM table AT (TIMESTAMP => DATEADD(hour, -3, CURRENT_TIMESTAMP)); to overwrite current data.
      B. Run DELETE FROM table WHERE update_time < DATEADD(hour, -3, CURRENT_TIMESTAMP); to undo changes.
      C. Use CREATE TABLE new_table AS SELECT * FROM table AT (TIMESTAMP => DATEADD(hour, -3, CURRENT_TIMESTAMP)); and replace the original table after verification.
      D. Restore the entire database to the state 3 hours ago using Time Travel.

      Solution

      1. Step 1: Understand safe recovery method

        Directly overwriting current data risks data loss; safer to create a new table snapshot first.
      2. Step 2: Verify and replace

        Creating a new table from past data lets you verify before replacing the original table.
      3. Step 3: Analyze other options

        Run INSERT INTO table SELECT * FROM table AT (TIMESTAMP => DATEADD(hour, -3, CURRENT_TIMESTAMP)); to overwrite current data risks duplicate data; C does not revert updates; D is not supported at database level.
      4. Final Answer:

        Use CREATE TABLE new_table AS SELECT * FROM table AT (TIMESTAMP => DATEADD(hour, -3, CURRENT_TIMESTAMP)); and replace the original table after verification. -> Option C
      5. Quick Check:

        Recover by snapshot then replace [OK]
      Hint: Recover past data into new table before replacing [OK]
      Common Mistakes:
      • Overwriting current data without backup
      • Trying unsupported database-wide restore
      • Using DELETE to undo updates
      Recommended

      Ready to prove it?

      Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

      10 questions~5 mineasy hard