Snowflake Backup & Data Recovery – Key Concepts
Originally published on LinkedIn: https://www.linkedin.com/pulse/nowflake-backup-data-recovery-key-concepts-arabinda-mohapatra-yvwfc/
Migrated on: 2026-04-05
What is Time Travel?
Time Travel is like a time machine for your data. It allows you to go back to a specific point in the past and see or recover data as it was at that time. This is extremely useful when you need to undo accidental deletions or changes.
🔑 Key Insights:
- Retention Period: You can set how long Snowflake keeps past versions of your data. The default is 1 day, but in the Enterprise Edition or above, you can extend this up to 90 days.
- Easy Recovery: With Time Travel, you can query, restore, or clone data as it was at any point during the retention period.
- Rollback Mistakes: You can fix user errors by simply rolling back to a previous version of your table or database.
🚫 1. External Tables — Why They Are Not Cloned
External tables only store metadata inside Snowflake, while the actual data lives outside (S3 / ADLS / GCS). Time Travel works only on Snowflake-managed storage, because Snowflake keeps historical versions of its own micro‑partitions — not external files.
👉 So when you try to Time‑Travel clone, Snowflake cannot recreate past versions of external files, because it never stored them internally.
Think of it like this: Snowflake can rewind its own storage, but not someone else’s bucket.
🚫 2. Internal Stages — Why They Are Not Cloned
Internal stages store files, not tables. Snowflake does not version stage files, so there is no historical snapshot to reconstruct.
Example: If a stage had 5 CSV files yesterday and 2 today, Time Travel has no history to know what existed at the chosen timestamp.
👉 Since stage files don’t have history, Time Travel cannot clone them.
Simple analogy: Time Travel works on tables (with metadata + micro‑partitions), not on raw file folders.
⚠️ 3. Hybrid Tables — Only DB‑Level Clone Allowed
- Hybrid tables support transactional workloads but come with limited Time Travel capabilities. Snowflake does not store all historical states in granular detail (especially at schema level) for hybrid tables.
- 👉 So Snowflake allows cloning them only at the database level where full metadata context exists, not at schema level.
Easy mental model: Hybrid tables behave differently than normal tables. They need the full database structure around them, so Snowflake can’t “rewind” them inside just a schema.
🚫 4. Tasks — Why They Don’t Clone with AT(TIMESTAMP)
- Tasks are scheduling metadata, not data objects. Snowflake does not keep historical versions of tasks, unlike tables & views.
CREATE SCHEMA S2 CLONE S1 AT(TIMESTAMP => ...) Tasks are NOT cloned because Snowflake cannot reconstruct how those tasks looked in the past.
CREATE SCHEMA S3 CLONE S1; (regular clone) Tasks ARE cloned, because Snowflake simply copies the current version.
👉 Time Travel clone = requires history → tasks have none → cannot clone them.
Think of tasks like cron jobs: You can copy them as they are today, but you can’t restore them to an old version because no history exists.
What is Fail-safe?
Fail-safe gives you a final safety net after Time Travel has expired. It’s a built-in 7-day period where Snowflake can recover lost or corrupted data in emergencies. You won’t be able to access this data directly, but Snowflake Support can help.
🔑 Key Insights:
- Additional Protection: After Time Travel ends, Fail-safe provides another 7 days to recover data, but it’s designed for emergencies.
- Managed by Snowflake: Fail-safe recoveries must be requested through Snowflake’s support team.
- For Critical Situations: Use Fail-safe as a last resort when all other recovery options are no longer available.
👩💻 Real-World Example
Your company experiences a system failure after a software update, and several critical tables are lost. Since Time Travel has expired, Snowflake’s Fail-safe can help recover those tables and prevent major data loss.
What is Zero-Copy Cloning?
Zero-Copy Cloning allows you to make instant, exact copies of your data without actually duplicating storage. This feature is great for creating backups, testing environments, or running experiments without affecting your live data.
🔑 Key Insights:
- Instant Cloning: Cloning is fast and uses no additional storage at first, making it perfect for backups or testing environments.
- No Immediate Storage Costs: Since it references existing data, the clone doesn’t consume extra storage until you start making changes.
- Backup and Testing: Use it to create backups before big updates or test new features without touching your production data.
👩💻 Real-World Example:
Your development team needs to test a new feature that might affect your customer database. Instead of risking live data, you can create a zero-copy clone of the database to test the changes safely.
What is Database Replication?
Database Replication helps protect your data by copying databases across accounts. Typically these accounts would be located either on the same cloud provider in a different region or on different cloud providers. This way, if a system failure happens in one provider/region, your data is still available in another, ensuring business continuity.
🔑 Key Insights:
- Cross-Region Replication: You can replicate your data to different regions so that if one region is affected by an outage, your data is still accessible.
- Cross-Cloud Replication: You can replicate your data to different cloud providers so that if one provider is affected by an outage, your data is still accessible.
- Failover and Failback: If your primary database fails, you can switch to a secondary replica and keep operations running smoothly.
- Regular Syncing: Make sure your replicas are synchronized to avoid inconsistencies during failover.
👩💻 Real-World Example:
Your company’s main database is located in the US East region. A major outage occurs, but because you’ve replicated the database to the US West region, your business operations continue without disruption.
Comments
Post a Comment