Datenschutz und Business Continuity

Snowflake-Management, Governance & Zusammenarbeit

Emily Melhuish

Technical Curriculum Developer, Snowflake

Das Business-Continuity-Problem

Diagramm mit drei Risikoszenarien: versehentliches Löschen, Regionsausfall und regionsübergreifende Datenresidenz, jeweils mit entsprechender Snowflake-Lösung

Analyst löscht Datensätze versehentlich – Time Travel behebt das
Cloud-Regionsausfall macht Claros Konto unzugänglich – Failover-Gruppen lösen das
EU-User brauchen Daten, die nur im US-Konto liegen – Replikation löst das
Unterschiedliche Risiken brauchen unterschiedliche Tools

Time Travel und Fail-Safe

Zeitachsen-Diagramm

Time Travel stellt Daten auf einen früheren Stand wieder her
Fensterlänge hängt von der Edition ab
- Standard: bis 1 Tag
- Enterprise: bis 90 Tage
Fail-Safe: 7 Tage Wiederherstellungspuffer nach dem Time-Travel-Fenster; erfordert Snowflake Support

Zero-Copy Cloning: Betriebsweisen

Klone eine Tabelle vor jeder riskanten Massenoperation
Sofortkopie – kein Speicher-Overhead bei Erstellung
Schlägt die Migration fehl, aus dem Klon wiederherstellen
Writes in den Klon berühren die Quelle nie

Zero Copy Cloning.png

¹ Snowflake Lernmaterial

Was ist Replikation?

Kopiert Daten über Konto-Grenzen hinweg
Asynchron — Ziel ist Near-Real-Time, kein Live-Spiegel

Use Cases

Screenshot 2026-05-17 at 7.33.30 pm.png

Replication example.png

Replikationsgruppen

Diagramm einer Replikationsgruppe mit zwei Datenbanken im Primärkonto US-East und Pfeilen zu schreibgeschützten Replikas im Sekundärkonto EU-West

Eine Replikationsgruppe erstellen

-- 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-Gruppen: Das kommt dazu

Baut auf Replikationsgruppen auf, mit einem wichtigen Zusatz
Sekundär kann bei Ausfall zum Primär hochgestuft werden
Sekundär ist immer read-only
Hochgestuftes Sekundär wird schreibbar — neue Source of Truth
Repliziert auch Kontoobjekte: Users, Roles, Warehouses, Resource Monitors

Failover example.png

Geplantes Failover und Mechanik

Geplantes Failover – geplant: Primär demotet, Sekundär promoted; kein Datenverlust
Failover – ungeplant: Primär nicht verfügbar, Sekundär promoted sofort
Replikation ist asynchron – Änderungen nach dem letzten Refresh fehlen im Sekundär
Refresh-Frequenz ist eine zentrale RPO-Entscheidung

Failover example.png

Lass uns üben!

Snowflake-Management, Governance & Zusammenarbeit