Protezione dei dati e continuità operativa

Gestione, governance e collaborazione in Snowflake

Emily Melhuish

Technical Curriculum Developer, Snowflake

Il problema della continuità operativa

Schema con tre scenari di rischio: eliminazione accidentale, outage di regione e residenza dati cross-region, ognuno con la soluzione Snowflake corrispondente

Un analista elimina record per errore: Time Travel lo risolve
Outage della regione cloud rende indisponibile l’account di Claro: lo gestiscono i failover group
Gli utenti UE necessitano dati che esistono solo in un account US: lo gestisce la replica
Rischi diversi richiedono strumenti diversi

Time Travel e Fail-Safe

Diagramma temporale

Time Travel permette di ripristinare i dati a uno stato precedente
La profondità della finestra dipende dall’edizione
- Standard: fino a 1 giorno
- Enterprise: fino a 90 giorni
Fail-Safe: buffer di recupero di 7 giorni oltre la finestra di Time Travel; serve contattare Snowflake Support

Zero-copy cloning: pattern operativi

Clona una tabella prima di qualsiasi operazione rischiosa in bulk
Copia istantanea: nessun costo storage alla creazione
Se la migrazione fallisce, ripristina dal clone
Le scritture sul clone non toccano mai la sorgente

Zero Copy Cloning.png

¹ Snowflake Learning Material

Cos’è la replica?

Copia i dati tra account
Asincrona — il target è near real-time, non uno specchio live

Casi d’uso

Screenshot 2026-05-17 at 7.33.30 pm.png

Esempio di replica.png

Gruppi di replica

Schema di un gruppo di replica con due database sull’account primario US-East, con frecce verso repliche di sola lettura sull’account secondario EU-West

Creare un gruppo di replica

-- 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 group: cosa aggiungono

Si basa sui gruppi di replica con un’aggiunta chiave
Il secondario può diventare primario se il primario cade
Il secondario è sempre in sola lettura
Il secondario promosso diventa scrivibile — diventa la fonte di verità
Replica anche oggetti account: utenti, ruoli, warehouse, resource monitor

Esempio di failover.png

Failover pianificato e meccanica del failover

Failover pianificato: il primario si demota, il secondario si promuove; nessuna perdita dati
Failover non pianificato: primario indisponibile, il secondario si promuove subito
Replica asincrona: le modifiche dopo l’ultimo refresh non sono nel secondario
La frequenza di refresh determina l’RPO

Esempio di failover.png

Passons à la pratique !

Gestione, governance e collaborazione in Snowflake