Architecting for Data Recovery and Business Continuity in Snowflake
Instruction: Describe your approach to designing data recovery and business continuity strategies within the Snowflake ecosystem.
Updated
Official answer
Start with a business impact assessment: which decisions and operations depend on each data product, how much data loss is acceptable, and how long the service can be unavailable. Record recovery-point and recovery-time objectives with owners and dependencies.
Separate three needs: resilience to infrastructure disruption, recovery from logical errors, and recovery from a regional/account-level incident. Platform-managed infrastructure redundancy helps availability, but it does not restore a mistaken update or automatically prepare every application dependency in another region.
Use appropriate Time Travel retention for eligible logical recovery and a protected recovery/backup strategy for the required threat model. Fail-safe is a distinct Snowflake-managed recovery mechanism, not arbitrary self-service point-in-time access or a guaranteed rapid restore. Confirm object-type restrictions and costs.
Configure supported replication/failover groups where a secondary region is justified. Monitor the last successful recovery point and errors, and prepare external storage, identities, networks and ingestion dependencies. An hourly schedule does not prove that the most recent successful replica is less than an hour old.
Document declaration authority, credential access, writer fencing, promotion, client redirection, data validation, replay and failback. Replication can copy bad data, so select a known-good recovery point for corruption incidents rather than blindly promoting the newest state.
Run exercises with realistic volumes and unavailable dependencies. Measure actual loss and time to useful service, record gaps, and update the runbook after architecture changes. Communicate degraded freshness and service expectations to consumers throughout recovery.