Data lake: backup e disaster recovery

Un data lake può contenere anni di eventi, tabelle curate e dataset critici per il reporting regolatorio. Sapere che S3 è durevole non basta: se una policy errata cancella oggetti o una regione diventa indisponibile, il team deve sapere quali dati ripristinare, in quale ordine e a quale costo. Questa lezione va letta con gli occhi di chi deve decidere, non solo configurare, e ti porta dal versioning al restore di prova.

Prima di tutto: di cosa stiamo parlando

Il backup e il disaster recovery di un data lake sono il piano verificato che riporta i dati giusti disponibili nei tempi promessi dopo cancellazioni, corruzioni o perdita di una regione. Non sono due tecnologie da acquistare, ma due discipline da provare: senza prove periodiche restano carta che nessuno legge.

Il piano si costruisce in sei passi

1. Classifica bucket, prefissi e tabelle per criticità e obblighi di retention.
2. Attiva il versioning sui bucket con dati curated e critici.
3. Abilita la replica cross-region verso una seconda regione per i dati che devono restare leggibili.
4. Fissa RPO e RTO con il business e scrivili nella procedura di restore.
5. Esegui un restore di prova su una partizione reale e documenta tempi ed esito.
6. Applica object lock e MFA Delete dove cancellazioni o manomissioni sono inaccettabili.

Versioning, replica e le altre protezioni

Il versioning di S3 crea una nuova versione a ogni modifica, quindi una cancellazione accidentale si recupera ripristinando la versione precedente. Il costo è lo storage extra delle versioni multiple, ma resta la base di quasi tutte le altre protezioni. Si attiva in un attimo, e da quel momento nessun DELETE è più definitivo:

aws s3api put-bucket-versioning --bucket my-lake --versioning-configuration Status=Enabled

La cross-region replication copia automaticamente gli oggetti in una seconda regione e richiede il versioning attivo. Se una regione diventa indisponibile, i dati restano leggibili nell’altra.

S3 eu-west-1 → S3 us-east-1 (async replication)

L’object lock blocca cancellazioni e modifiche per un periodo fisso, per esempio sette anni per la compliance fiscale. In modalità Governance l’override resta possibile con permessi speciali, mentre in modalità Compliance non è possibile per nessuno. Infine MFA Delete richiede un’autenticazione multifattore per eliminare versioni di oggetti, così credenziali API compromesse da sole non bastano a distruggere i dati.

Se vuoi il riassunto in una riga: versioning sempre sui dati critici, replica cross-region per la continuità tra regioni, object lock e MFA Delete solo dove la cancellazione è inaccettabile.

RPO e RTO: i due numeri che governano tutto

Due numeri tengono insieme tutto il resto, e conviene padroneggiarli prima dell’incidente. L’RPO indica quanti dati puoi permetterti di perdere: con la replica cross-region scende intorno ai quindici minuti. L’RTO indica quanto tempo serve per tornare operativi: se Athena punta alla replica, l’RTO si misura in minuti perché basta cambiare la location della query. Concorda questi due valori con il business prima dell’incidente, non durante.

Gli errori che tornano puntuali

Il primo errore è trattare il backup come un’etichetta tecnica invece che come un criterio di scelta: si abilita il versioning, si mette una spunta e non si prova mai un restore reale. Il secondo è confondere la replica con il disaster recovery: avere i dati in due regioni non serve se nessuno sa quale procedura seguire quando una regione cade. Il terzo è ignorare il costo, perché versioni multiple e classi sbagliate possono far esplodere la spesa di storage senza alcun beneficio in termini di rischio.

Dalla teoria a un incidente vero: GitLab, 2017

Il 31 gennaio 2017 un manutentore di GitLab cancella per errore circa 300 GB di dati di produzione e il team scopre che i backup disponibili non sono ripristinabili. Il servizio viene ricostruito in meno di un giorno e l’azienda pubblica il post-mortem completo, trasmettendo parte del ripristino in diretta. Da allora il caso viene citato in ogni discussione seria di disaster recovery. La lezione è una sola: un backup mai ripristinato in prova non è un backup e il tempo di ripristino si misura con le esercitazioni, non con le slide.

Verdetto: versioning sempre sui dati critici, replica cross-region per la continuità tra regioni, object lock e MFA Delete solo dove la cancellazione è inaccettabile: fissa RPO e RTO con il business prima dell’incidente e prova un restore reale, perché un backup mai ripristinato non è un backup.

Domande per chiudere la lezione

1. Quale dato ripristini per primo dopo la cancellazione di una partizione curated usata dal reporting finance?
2. Quando la replica cross-region riduce davvero il tempo di ripartenza rispetto al solo versioning?
3. Quale combinazione di object lock e MFA Delete applichi ai dati con obblighi di retention pluriennali?
4. Quale prova periodica dimostra che RPO e RTO concordati sono rispettati?