In un piano di ripristino di emergenza, il tuo obiettivo del punto di ripristino (RPO) è un parametro di ripristino chiave che determina la quantità di dati che puoi permetterti di perdere. L'RPO è elencato nel tempo, da secondi a giorni. In effetti, l'RPO dipende direttamente dal tuo sistema di backup. Segna l'età dei tuoi dati di backup che devi recuperare per riprendere le normali operazioni.
Se esegui un backup notturno alle 22:00. e il tuo sistema di database si blocca irreparabilmente alle 15:00. il giorno successivo, perdi tutto ciò che è stato modificato dall'ultimo backup. Il tuo RPO in questo particolare contesto è il backup del giorno precedente, il che significa che puoi permetterti di perdere un giorno di modifiche.
Il diagramma seguente del nostro Whitepaper sul ripristino di emergenza illustra il concetto.
Per un RPO più stretto, un backup potrebbe non essere sufficiente. Quando si esegue il backup del database, si sta effettivamente acquisendo un'istantanea dei dati in un determinato momento. Pertanto, durante il ripristino di un backup, perderai le modifiche avvenute tra l'ultimo backup e l'errore.
È qui che entra in gioco il concetto di Point In Time Recovery (PITR).
Cos'è PITR?
Point In Time Recovery (PITR), come dice il nome, comporta il ripristino del database in un dato momento nel passato. Per poterlo fare, dovremo ripristinare un backup, quindi applicare tutte le modifiche avvenute dopo il backup fino a poco prima dell'errore.
Per PostgreSQL, le modifiche sono archiviate nei registri WAL (per maggiori dettagli sui WAL e sui dati che archiviano, puoi consultare questo blog).
Quindi ci sono due cose che dobbiamo assicurarci per poter eseguire un PITR:i backup e i WAL (dobbiamo configurare l'archiviazione continua per loro).
Per eseguire il PITR, dovremo recuperare il backup e quindi applicare i WAL.
Quando potrebbe essere utile?
È possibile utilizzare questa strategia ogni volta che si esegue il ripristino da un problema che ha causato il danneggiamento dei dati. Devi tenere a mente che stai cercando di ridurre al minimo la perdita di dati, ma ci sono alcuni problemi che potrebbero far sì che i dati non siano più utili in seguito.
Alcuni esempi di ciò possono essere modifiche non pianificate dei dati (DML o DDL), errori dei supporti o manutenzioni del database (come gli aggiornamenti) che portano al danneggiamento dei dati. Non sarai in grado di recuperare le modifiche ai dati avvenute dopo il problema.
Supponiamo che un utente abbia eseguito erroneamente un DML, facendo in modo che i dati di un'intera tabella vengano alterati o eliminati in modo errato. È possibile eseguire un PITR del database in una posizione separata e quindi esportare il contenuto della tabella. Puoi quindi ripristinare quella tabella nel database esistente, ripristinando effettivamente una copia di come era la tabella prima che si verificasse il problema.
Naturalmente, non è sempre possibile ripristinare solo una parte del database in questo modo, quindi in tal caso sarà necessario ripristinare tutto il database fino a un determinato punto e si avrà una perdita di dati minima ma inevitabile (ti mancherà eventuali modifiche avvenute dopo che si è verificato il problema).
Come si usa con ClusterControl?
In un blog precedente, abbiamo potuto vedere come implementare PITR manualmente, ora vediamo come utilizzare ClusterControl per eseguire questa attività.
Abilitazione del recupero temporizzato
Per abilitare la funzione PITR dobbiamo avere l'Archiviazione WAL abilitata. Per questo possiamo andare su ClusterControl -> Selezionare PostgreSQL Cluster -> Azioni nodo -> Abilita archiviazione WAL, o semplicemente andare su ClusterControl -> Selezionare PostgreSQL Cluster -> Backup -> Impostazioni e abilitare l'opzione "Abilita ripristino point-in-time (Archiviazione WAL)” come vedremo nell'immagine seguente.
Dobbiamo tenere presente che per abilitare l'archiviazione WAL, dobbiamo riavviare il nostro database. ClusterControl può farlo anche per noi.
Oltre alle opzioni comuni a tutti i backup come “Backup Directory” e “Backup Retention Period”, qui possiamo specificare anche il WAL Retention Period. Per impostazione predefinita è 0, che significa per sempre.
Per confermare che l'archiviazione WAL è abilitata, possiamo selezionare il nostro nodo Master in ClusterControl -> Seleziona cluster PostgreSQL -> Nodi e dovremmo vedere il messaggio Archiviazione WAL abilitata, come possiamo vedere nell'immagine seguente.
Creazione di un backup compatibile con il ripristino temporizzato
Avendo abilitato l'archiviazione WAL, come abbiamo visto nel passaggio precedente, possiamo creare il nostro backup compatibile con PITR. Per questo, vai su ClusterControl -> Seleziona PostgreSQL Cluster -> Backup -> Crea backup.
Possiamo creare un nuovo backup o configurarne uno pianificato. Per il nostro esempio, creeremo istantaneamente un singolo backup.
Qui dobbiamo scegliere il metodo “pg_basebackup”, compatibile con PITR, il server da cui verrà prelevato il backup (per essere compatibile con PITR, deve essere il master), e dove vogliamo archiviare il backup. Possiamo anche caricare il nostro backup sul cloud (AWS, Google o Azure) abilitando il pulsante corrispondente.
Quindi specifichiamo l'uso della compressione, della crittografia e della conservazione del nostro backup.
Nella sezione di backup, possiamo vedere lo stato di avanzamento del backup e informazioni come il metodo, le dimensioni, la posizione e altro.
Recupero temporizzato da un backup
Una volta terminato il backup, possiamo ripristinarlo utilizzando la funzionalità ClusterControl PITR. Per questo, nella nostra sezione di backup (ClusterControl -> Seleziona cluster PostgreSQL -> Backup), possiamo selezionare "Ripristina backup" o direttamente "Ripristina" sul backup che vogliamo ripristinare.
Qui scegliamo quale backup vogliamo ripristinare e da quale directory.
Lasciamo selezionata l'opzione "Ripristina su nodo" e proseguiamo.
Ora dobbiamo scegliere dove ripristinare il nostro backup e abilitare l'opzione PITR. Specificando l'ora, sarà l'ora fino a quando ci riprenderemo. Tieni presente che viene utilizzato il fuso orario UTC e che il nostro servizio PostgreSQL nel master verrà riavviato.
Possiamo monitorare l'avanzamento del nostro ripristino dalla sezione Attività nel nostro ClusterControl.
Conclusione
PITR è una caratteristica necessaria per soddisfare un RPO stretto. È necessario configurarlo correttamente per garantire un piano di ripristino di emergenza corretto. ClusterControl fornisce un'interfaccia facile da usare per aiutarti a implementare PITR per i tuoi database PostgreSQL.
