Backup e Point-in-Time Recovery in DynamoDB
DynamoDB protegge i tuoi dati in due modi. I backup on-demand sono snapshot completi che crei e conservi a tempo indeterminato. Il point-in-time recovery (PITR) è un backup continuo e automatico che ti permette di ripristinare la tabella a qualsiasi secondo dentro una finestra scorrevole. Entrambi ripristinano verso una nuova tabella — sono strumenti di recovery, non un pulsante di undo.
Per l'audit log questo è imprescindibile. È un record di compliance immutabile; una migrazione sbagliata che riscrive gli eventi, o una cancellazione di massa accidentale, deve essere recuperabile fino al momento prima dell'errore.
Come funzionano backup e point-in-time recovery in DynamoDB?
DynamoDB offre due tipi di backup. Il point-in-time recovery (PITR) esegue backup automatici continui, permettendoti di ripristinare a qualsiasi secondo all'interno di una finestra configurabile da 1 a 35 giorni. I backup on-demand sono snapshot completi manuali conservati a tempo indeterminato. Entrambi ripristinano verso una nuova tabella, mai sopra quella originale, quindi sono strumenti di recovery più che un undo sul posto.
- PITR = backup continuo, ripristino a qualsiasi secondo dentro una finestra configurabile da 1 a 35 giorni (un tempo era fissa a 35).
- Backup on-demand = snapshot completi manuali conservati quanto vuoi, indipendenti dalla finestra del PITR.
- I ripristini creano una nuova tabella. Ripristini su un nuovo nome, poi fai il cut over — l'originale resta intatto.
- Il PITR è tariffato sulla dimensione della tabella, non sul numero di punti di ripristino — stimalo con il Calcolatore di prezzi DynamoDB.
Il problema: un errore che non puoi annullare sul posto
DynamoDB non ha un transaction log su cui fare rollback né un "undo" su una
scrittura. Se uno script di migrazione riscrive il campo action di ogni evento, o
qualcuno esegue una delete più ampia del previsto, la tabella è semplicemente nello
stato sbagliato. Senza backup, i dati sono persi.
Per un audit log — il cui intero valore è essere un record affidabile — "non possiamo recuperare gli eventi di martedì scorso" è un fallimento di compliance, non un semplice inconveniente.
Come funzionano backup e PITR
Il point-in-time recovery, una volta abilitato, esegue backup automatici
continui. Secondo la
documentazione AWS,
il PITR "fornisce backup continui automatici e completamente gestiti dei dati della
tabella con fino a 35 giorni di punti di ripristino con granularità al secondo". La
finestra è configurabile da 1 a 35 giorni tramite RecoveryPeriodInDays, e puoi
ripristinare a qualsiasi secondo al suo interno — anche su una region diversa.
Un caso limite importante: ridurre il periodo di ripristino riduce immediatamente il punto di ripristino più antico, e disabilitare e poi riabilitare il PITR azzera il momento di inizio recuperabile — perdi la storia continua precedente.
I backup on-demand sono separati: snapshot manuali dell'intera tabella che crei esplicitamente e conservi a tempo indeterminato, utili per un checkpoint pre-migrazione o un archivio di compliance a lungo termine oltre la finestra di 35 giorni del PITR.
Entrambi ripristinano verso una nuova tabella, non sopra quella esistente:
Un esempio pratico: recuperare da una migrazione sbagliata
Una migrazione pensata per aggiungere un attributo expiresAt ha invece sovrascritto
action su ogni evento con una stringa vuota. Il PITR è attivo con una finestra di
35 giorni, quindi ripristini al secondo prima che la migrazione girasse:
| step | result |
|---|---|
| restore PITR to 09:59:00 | new table audit-log-restored with correct actions |
| diff against live | confirm only the migration's rows differ |
| cut app over to restored | original left intact for forensics |
La tabella corrotta resta intatta mentre verifichi il ripristino — confronti gli
eventi ripristinati con quelli live, confermi che i valori di action sono tornati,
poi ripunti l'app. Nulla viene distrutto nel recovery stesso.
Se la perdita fosse una manciata di Item invece di una corruzione dell'intera tabella, potresti invece ispezionare i dati live e la copia ripristinata e copiare solo le righe interessate — vedi copiare una tabella DynamoDB.
Fallo in DynoTable
Un ripristino vale solo quanto la verifica che ne fai. Dopo aver ripristinato su
audit-log-restored, devi davvero guardare gli eventi recuperati e confermare che
corrispondano a com'erano prima dell'errore.
DynoTable si connette alla tabella ripristinata come a qualsiasi altra, così puoi
fare la Query degli eventi del tenant interessato, confermare che i valori di
action siano corretti, e confrontare con la tabella live prima del cut over —
trasformando un ripristino da atto di fede in un recovery verificato.
Puoi anche esportare gli eventi recuperati per un record di compliance offline — vedi esportare DynamoDB in CSV.
Trappole e prossimi passi
- Abilita il PITR prima di averne bisogno. Protegge solo dal momento in cui è attivo — non c'è recovery retroattivo. Attivalo per qualsiasi tabella i cui dati non puoi permetterti di perdere.
- Disabilitare il PITR azzera la finestra. Disattivarlo e riattivarlo cancella la storia continua; il momento di inizio recuperabile riparte dalla riabilitazione.
- I ripristini non sono istantanei né gratuiti. Un ripristino provisiona un'intera nuova tabella e richiede un tempo proporzionale alla dimensione; metti a budget la durata e la tabella extra.
- 35 giorni non sono un archivio. Per la retention oltre la finestra del PITR, esegui backup on-demand o esporta su S3 — il PITR è una finestra di recovery, non storage a lungo termine.
Questo chiude il ciclo delle operazioni sull'audit log: transazioni per la consistenza, Streams per la reazione, TTL per la scadenza, la giusta modalità di capacità per il costo, le global tables per la resilienza tra region, e il PITR per il recovery dei dati. Rileggi la panoramica Operations & Cost per vedere come si incastrano insieme.
Scarica DynoTable per connetterti a una tabella ripristinata e verificare il tuo recovery prima di fidartene.