Backup e Point-in-Time Recovery in DynamoDB: la guida completa

DynamoDB protegge i tuoi dati in due modi. I backup on-demand sono snapshot completi che crei e conservi indefinitamente. Il point-in-time recovery (PITR) è un backup continuo e automatico che ti permette di ripristinare la tabella a un qualsiasi secondo entro una finestra scorrevole. Entrambi ripristinano su una tabella nuova — sono strumenti di ripristino, non un pulsante di annullamento.

Per il log di audit questo non è negoziabile. È un record di conformità immutabile; una migrazione sbagliata che riscrive gli eventi, o una cancellazione di massa accidentale, deve essere recuperabile al momento precedente all'errore.

Come funzionano il backup e il point-in-time recovery di DynamoDB?

DynamoDB offre due tipi di backup. Il point-in-time recovery (PITR) esegue backup continui e automatici, permettendoti di ripristinare a un qualsiasi secondo entro una finestra configurabile da 1 a 35 giorni. I backup on-demand sono snapshot completi manuali conservati indefinitamente. Entrambi ripristinano su una nuova tabella, mai sopra l'originale, quindi sono strumenti di ripristino più che un annullamento sul posto.

• PITR = backup continuo, ripristino a un qualsiasi secondo entro una finestra configurabile di 1-35 giorni (un tempo era un valore fisso di 35).
• Backup on-demand = snapshot completi manuali conservati per tutto il tempo che vuoi, indipendenti dalla finestra del PITR.
• I ripristini creano una nuova tabella. Ripristini su un nuovo nome, poi tagli sopra — l'originale resta intatto.
• Il PITR ha un prezzo basato sulla dimensione della tabella, non sul numero di punti di ripristino — stimalo con il calcolatore dei prezzi di DynamoDB.

Il problema: un errore che non puoi annullare sul posto

DynamoDB non ha un log delle transazioni da riavvolgere né un "annulla" su una scrittura. Se uno script di migrazione riscrive il campo action di ogni evento, o qualcuno esegue una cancellazione più ampia del previsto, la tabella è semplicemente nello stato sbagliato. Senza backup, i dati sono persi.

Per un log di audit — il cui intero valore è essere un record affidabile — "non possiamo recuperare gli eventi di martedì scorso" è un fallimento di conformità, non solo un fastidio.

Come funzionano backup e PITR

Il point-in-time recovery, una volta abilitato, esegue backup continui e automatici. Secondo la documentazione AWS, il PITR ti dà backup continui completamente gestiti dei dati della tabella con granularità di ripristino al secondo. La finestra è configurabile da 1 a 35 giorni tramite RecoveryPeriodInDays, e puoi ripristinare a un qualsiasi secondo al suo interno — fino a circa cinque minuti dietro al tempo reale (LatestRestorableDateTime) — inclusa una regione diversa.

Un punto importante: ridurre il periodo di recupero riduce immediatamente il punto di ripristino più antico, e disabilitare e poi riabilitare il PITR azzera il tempo di inizio recuperabile — perdi la precedente storia continua.

Il PITR condiziona anche l'export gestito verso S3: l'export legge dagli stessi backup continui, quindi con il PITR disattivato ExportTableToPointInTime fallisce con PointInTimeRecoveryUnavailableException.

I backup on-demand sono separati: snapshot completi manuali della tabella che crei esplicitamente e conservi indefinitamente, utili per un checkpoint pre-migrazione o un archivio di conformità a lungo termine oltre la finestra PITR di 35 giorni. La richiesta viene elaborata istantaneamente e il backup diventa ripristinabile nel giro di pochi minuti, non consuma nulla del throughput della tabella e non c'è un limite a quanti ne conservi. Un'avvertenza onesta dalla documentazione: i backup on-demand non garantiscono la coerenza causale tra gli item — lo scarto tra gli aggiornamenti è "usually much less than a second", ma un backup preso nel mezzo di una raffica di scritture non è un unico istante congelato.

Che cosa un ripristino non riporta indietro

Un ripristino ricrea i dati della tabella e i suoi indici — non il suo cablaggio operativo. Secondo la documentazione AWS, sulla tabella ripristinata devi riconfigurare a mano: le policy di auto scaling, le policy IAM, le metriche e gli allarmi CloudWatch, i tag, le impostazioni degli stream, il TTL, la protezione dalla cancellazione e il PITR stesso. Ripristinare da backup e dimenticare di riabilitare il PITR è il modo in cui il prossimo incidente diventa irrecuperabile.

Al momento del ripristino puoi cambiare deliberatamente alcune impostazioni — modalità di fatturazione, capacità con provisioning, chiavi di crittografia — e puoi escludere alcuni o tutti gli indici secondari, il che rende il ripristino più rapido ed economico se puoi ricostruirli dopo. I ripristini possono anche puntare a una regione diversa, e un ripristino non sovrascrive mai una tabella esistente.

Backup pianificati con AWS Backup

I backup on-demand nativi di DynamoDB non hanno uno scheduler. Per backup ricorrenti con conservazione, DynamoDB si integra nativamente con AWS Backup (documentazione AWS): i backup plan ti danno backup pianificati con regole di ciclo di vita (inclusa la migrazione a cold storage), copie cross-account e cross-region automatiche per il disaster recovery, una chiave KMS indipendente tramite il backup vault e Vault Lock per una postura di conformità WORM che nessuno può cancellare in silenzio. Due insidie operative: AWS Backup richiede un opt-in esplicito per account e per regione, e i backup che crea (di tipo AWS_BACKUP) non si possono eliminare dalla console DynamoDB — vanno gestiti in AWS Backup.

Entrambi ripristinano su una nuova tabella, non sopra quella esistente:

Un esempio svolto: recupero 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 precedente all'esecuzione della migrazione:

La tabella corrotta resta intatta mentre verifichi il ripristino — confronti gli eventi ripristinati con quelli live, confermi che i valori di action siano tornati, poi ripunti l'app. Nulla viene distrutto nel recupero 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 tua verifica di esso. Dopo aver ripristinato su audit-log-restored, devi effettivamente guardare gli eventi recuperati e confermare che corrispondano a ciò che avrebbero dovuto essere prima dell'errore.

DynoTable si connette alla tabella ripristinata come a qualsiasi altra, così puoi interrogare gli eventi del tenant interessato, confermare che i valori di action siano corretti e confrontare con la tabella live prima di tagliare sopra — trasformando un ripristino da un atto di fede a un recupero verificato.

Puoi anche esportare gli eventi recuperati per un record di conformità offline — vedi esportare DynamoDB in CSV.

Insidie e passaggi successivi

• Abilita il PITR prima che ti serva. Protegge solo dal momento in cui è attivo — non c'è recupero 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 tempo di inizio recuperabile ricomincia dalla riabilitazione.
• I ripristini non sono istantanei né gratuiti. Un ripristino crea un'intera nuova tabella e richiede un tempo proporzionale alla dimensione; metti in conto la durata e la tabella extra.
• 35 giorni non sono un archivio. Per una conservazione oltre la finestra PITR, esegui backup on-demand o esporta su S3 — il PITR è una finestra di recupero, non uno storage a lungo termine.

Questo chiude il ciclo di operazioni del log di audit: transazioni per la coerenza, Streams per la reazione, TTL per la scadenza, la modalità di capacità giusta per il costo, global tables per la resilienza regionale e PITR per il recupero dei dati. Rivedi la panoramica Operations & Cost per vedere come si incastrano.

Scarica DynoTable per connetterti a una tabella ripristinata e verificare il tuo recupero prima di fidartene.