Ripristino point-in-time vs snapshot: cosa perdi

Qualcuno esegue un DELETE senza una clausola WHERE alle 16:15. Il backup più recente risale alle 03:00. Tutto ciò che è successo tra quei due momenti è perso e nessun ripristino potrà riportarlo indietro.

Quell'intervallo ha un nome: recovery point objective, o RPO. La scelta tra ripristino point-in-time e snapshot riguarda interamente quanto sei disposto a farlo diventare ampio.

I due modelli

Gli snapshot catturano lo stato dei dati in un determinato momento. Vengono eseguiti secondo una pianificazione, di solito ogni notte. Ripristinarne uno ti riporta esattamente alla situazione esistente al momento della sua esecuzione, mentre tutto ciò che è avvenuto dopo viene perso.

Il ripristino point-in-time combina un backup di base con un flusso continuo del write-ahead log del database. Poiché ogni modifica viene registrata in ordine, puoi riprodurre i dati fino a qualsiasi momento coperto dal log conservato, incluso le 16:14, un minuto prima della cancellazione.

La differenza non è incrementale. È la differenza tra "abbiamo perso un giorno" e "abbiamo perso un minuto".

Il numero che determina la scelta

Fatti una domanda, con sincerità: se perdessi tutto ciò che è stato scritto nelle ultime dodici ore, cosa succederebbe?

Per un progetto personale, un sito di documentazione o uno strumento interno i cui dati sono riproducibili: non molto. Gli snapshot notturni sono davvero la scelta giusta, e pagare per l'archiviazione continua sarebbe uno spreco.

Per qualsiasi sistema in cui scrivono dei clienti, la risposta di solito è una variante di "dovremmo mandare un'email alle persone e spiegare cosa è successo". Ordini che non esistono più. Upload scomparsi. Messaggi inviati che ora non ci sono più. Il solo costo dell'assistenza supera in genere, nell'arco di un anno, la differenza di spesa per l'infrastruttura.

L'errore non è scegliere gli snapshot. L'errore è sceglierli per impostazione predefinita, senza chiedersi mai quanto costerebbe un buco di dodici ore.

Per cosa gli snapshot sono davvero indicati

Non sono un prodotto di serie B. Coprono scenari di errore che il PITR non copre:

• Perdita dell'intero disco. Uno snapshot su storage separato ripristina tutto, inclusi i file che non appartengono al database.
• Rollback rapido e grossolano. Annullare una migrazione mal riuscita in un ambiente di staging è più veloce con uno snapshot che riproducendo un log.
• Costo. Conservare una copia al giorno costa meno che conservare ogni scrittura.
• Semplicità. Avere meno componenti è un vantaggio operativo concreto, soprattutto per un team piccolo.

Il rischio nasce quando li si considera sufficienti per un database che riceve scritture continue.

Quanto ti costa il PITR

Non è gratuito, ed è importante esplicitarne i costi:

• Storage. Devi conservare il backup di base più ogni scrittura per tutto il periodo di retention.
• Complessità. L'archiviazione deve funzionare continuamente. Un archiver che fallisce in silenzio da una settimana significa che la finestra recuperabile termina una settimana fa: ecco perché monitorare l'archivio è importante quanto configurarlo.
• Tempo di ripristino. Riprodurre un log richiede più tempo che ripristinare uno snapshot. L'RPO migliora, mentre l'RTO di solito peggiora.

È proprio quest'ultimo compromesso a cogliere molti di sorpresa. Il PITR significa perdere meno dati, non tornare online più velocemente.

La risposta a più livelli di cui la maggior parte dei team ha davvero bisogno

Nella pratica, non è una scelta tra due alternative. I database di produzione di solito richiedono tre livelli, perché possono guastarsi in tre modi diversi:

Snapshot giornalieri, conservati per una o due settimane. Un'assicurazione economica contro la perdita della macchina. Coprono anche i file non appartenenti al database che si trovano sullo stesso volume.

Dump logici giornalieri, conservati al di fuori dell'host. Un pg_dump è portabile e coerente per sua natura. Può essere ripristinato su una major version diversa, su un provider diverso o su un laptop: è ciò che serve quando il problema riguarda la piattaforma e non i dati.

Archiviazione continua, quando il database contiene dati dei clienti. Il livello che trasforma "abbiamo perso la giornata di oggi" in "abbiamo perso un minuto".

Ogni livello copre ciò che gli altri non coprono. Uno snapshot non ti aiuta a cambiare provider. Un dump logico non ti aiuta a recuperare un file che non era nel database. Nessuno dei due ti aiuta ad annullare una cancellazione avvenuta quattro ore fa.

Dove si colloca Dockup

Dockup ti offre i due livelli che coprono i guasti più comuni, ed è importante precisare quali sono.

Snapshot dei volumi, su richiesta o secondo una pianificazione con un numero di copie conservate:

dockup volume snapshot <volumeId> my-project/my-api
dockup volume schedule <volumeId> my-project/my-api --daily --retention 7
dockup volume restore <volumeId> <snapshotId> my-project/my-api

Backup logici dei database, trasferiti direttamente nello storage a oggetti e cifrati durante il trasferimento:

dockup db backup my-project/main-db --json
dockup db backups my-project/main-db --json

Per il ripristino, la seconda funzionalità ha due caratteristiche importanti. Il backup non viene mai salvato sull'host del database: viene trasferito in streaming allo storage mentre pg_dump lo genera, quindi non condivide il destino del disco da cui proviene. Inoltre, un dump che termina con un codice diverso da zero o produce zero byte viene eliminato e registrato come non riuscito, invece di rimanere nell'elenco con l'aspetto di un backup valido.

Oggi Dockup non esegue l'archiviazione continua al posto tuo. Se il tuo RPO deve davvero essere nell'ordine dei minuti, è importante saperlo prima di scegliere; ed è ragionevole eseguirla autonomamente su un database gestito, usando la piattaforma per tutto il resto.

L'esercizio che vale la pena fare questa settimana

Annota due numeri per il tuo database di produzione:

1. RPO — quanti dati puoi perdere. Misurato in tempo.
2. RTO — per quanto tempo puoi restare offline. Anche questo misurato in tempo.

Poi verifica cosa offre davvero la configurazione attuale ripristinando qualcosa. Se i numeri che hai annotato e quelli effettivamente garantiti dalla tua configurazione sono diversi, hai trovato una decisione da prendere mentre non c'è ancora nulla in fiamme: l'unico momento giusto per prenderla.

Domande frequenti

Qual è la differenza tra RPO e RTO? L'RPO indica quanti dati perdi: l'intervallo tra l'ultimo momento recuperabile e il guasto. L'RTO indica quanto dura il ripristino. Gli snapshot offrono un RPO ampio e un RTO breve; il PITR li inverte.

Posso recuperare da uno snapshot notturno le righe eliminate un'ora fa? No. Uno snapshot ripristina lo stato esistente al momento in cui è stato creato. Tutto ciò che è stato scritto dopo non si trova nel file. Per recuperare un momento arbitrario è necessaria l'archiviazione continua.

Uno snapshot di un volume equivale a un backup del database? No. Uno snapshot cattura il disco, incluso lo stato intermedio in cui si trovava il database durante una scrittura. Un dump logico è coerente internamente e portabile su altre versioni e altri provider. La maggior parte delle configurazioni di produzione richiede entrambi.

Per quanto tempo dovrei conservare i backup? Per un periodo abbastanza lungo da accorgerti di un problema. Una corruzione o una migrazione errata vengono spesso scoperte dopo diversi giorni; conservare i backup per un solo giorno significa quindi, molto spesso, che le uniche copie disponibili contengono già il danno.