Dataskydd och affärskontinuitet

Snowflake-hantering, styrning och samarbete

Emily Melhuish

Technical Curriculum Developer, Snowflake

Problemet med affärskontinuitet

Diagram med tre riskscenarier: oavsiktlig radering, regionavbrott och datahemvist i olika regioner, var och en med sin Snowflake-lösning

En analytiker raderar poster av misstag – Time Travel hanterar det
Avbrott i molnregion gör Claros konto otillgängligt – failover-grupper hanterar det
EU-användare behöver data som bara finns i ett US-konto – replikering hanterar det
Olika risker kräver olika verktyg

Time Travel och Fail-Safe

Tidslinjediagram

Time Travel gör det möjligt att återställa data till ett tidigare tillstånd
Fönsterdjupet beror på din utgåva
- Standard: Upp till 1 dag
- Enterprise: Upp till 90 dagar
Fail-Safe: en 7-dagars återställningsbuffert utöver Time Travel-fönstret – kräver kontakt med Snowflake Support

Zero-copy-kloning: Driftsmönster

Klona en tabell innan riskfyllda massoperationer
Omedelbar kopia – inget lagringsutrymme åtgår vid skapandet
Om migrering misslyckas, återställ från klonen
Skrivningar till klonen påverkar aldrig källan

Zero Copy Cloning.png

¹ Snowflake Learning Material

Vad är replikering?

Kopierar data över kontogränser
Asynkron — målet är nära realtid, inte en direktkopia

Användningsfall

Screenshot 2026-05-17 at 7.33.30 pm.png

Exempel på replikering.png

Replikeringsgrupper

Diagram över en replikeringsgrupp med två databaser på det primära kontot US-East, med pilar till skrivskyddade repliker på det sekundära kontot EU-West

Skapa en replikeringsgrupp

-- On the primary account
CREATE REPLICATION GROUP claro_replication_group
  OBJECT_TYPES = DATABASES
  ALLOWED_DATABASES = claro_db, claro_users_db
  ALLOWED_ACCOUNTS = claro.eu_west;

-- On the secondary account
CREATE REPLICATION GROUP claro_replication_group
  AS REPLICA OF claro.us_east.claro_replication_group;

-- Trigger a refresh
ALTER REPLICATION GROUP claro_replication_group REFRESH;

Failover-grupper: Vad de tillför

Bygger på replikeringsgrupper med ett viktigt tillägg
Sekundärt konto kan befordras till primärt om det primära går ner
Sekundärt konto är alltid skrivskyddat
Befordrat sekundärt konto blir skrivbart — tar över som källan till sanning
Replikerar även kontoobjekt: användare, roller, lager, resursmonitorer

Exempel på failover.png

Planerad failover och failover-mekanik

Planerad failover - planerad: primärt degraderas, sekundärt befordras; ingen dataförlust
Failover - oplanerad: primärt otillgängligt, sekundärt befordras omedelbart
Replikering är asynkron – ändringar efter senaste uppdatering saknas i sekundäret
Uppdateringsfrekvens är ett viktigt RPO-designbeslut

Exempel på failover.png

Låt oss öva!

Snowflake-hantering, styrning och samarbete