Grazie alle nuove utility barman-cloud-restore e barman-cloud-wal-restore introdotto in Barman 2.11 , è ora possibile eseguire il ripristino di un'istanza PostgreSQL utilizzando un backup completo precedentemente eseguito utilizzando barman-cloud-wal-archive e barman-cloud-backup comandi. Scopriamo insieme come implementarlo nel seguente articolo.
Vale la pena notare che in Barman 2.11, tutte le utilità cloud per Barman sono ora in un pacchetto separato chiamato barman-cli-cloud .
Requisiti
1. barman-cli-cloud pacchetto
2. Un'istanza PostgreSQL
3. Un bucket AWS S3
4. Una seconda macchina virtuale dove eseguire il ripristino
In questo articolo testeremo barman-cli-cloud funzionalità in una macchina virtuale con Debian Buster e PostgreSQL 12. Per seguire correttamente le istruzioni contenute in questo articolo, assumiamo anche che tu abbia:
- configurato Postgres per archiviare i file WAL in un bucket S3 esistente utilizzando
barman-cloud-wal-archive - eseguito un backup e spedirlo allo stesso bucket S3 tramite
barman-cloud-backup
Puoi facilmente raggiungere questo obiettivo seguendo le istruzioni contenute in questi precedenti articoli del blog:
- Barman Cloud – Parte 1:Archivio WAL
- Barman Cloud – Parte 2:Backup su cloud
Configura il server di ripristino
Di conseguenza, abbiamo un bucket S3 su AWS denominato barman-s3-test che contiene già i file WAL e il backup archiviato tramite barman-cloud-wal-archive e barman-cloud-backup strumenti, ora dobbiamo configurare correttamente un server che sarà l'host per il ripristino dell'istanza PostgreSQL.
1. Installa PostgreSQL 12 dal repository PGDG ufficiale
2. Installa il repository pubblico 2ndQuadrant
3. Installa il barman-cli-cloud pacchetto:
[email protected]:~# apt update [email protected]:~# apt install barman-cli-cloud
4. Installa awscli pacchetto:
[email protected]:~# apt install awscli
5. Configura le credenziali AWS con lo strumento awscli come utente postgres:
[email protected]:~$ aws configure --profile barman-cloud AWS Access Key ID [None]: AKI***************** AWS Secret Access Key [None]: **************************************** Default region name [None]: eu-west-1 Default output format [None]: json
Esegui la procedura di ripristino
Ora che il server di ripristino è configurato correttamente, siamo pronti per avviare la procedura di ripristino.
Barman 2.11 introduce l'barman-cloud-backup-list comando che permette di recuperare informazioni sui backup effettuati con barman-cloud-backup :
[email protected]:~$ barman-cloud-backup-list \ --profile barman-cloud \ s3://barman-s3-test pg12 Backup ID End Time Begin Wal 20200713T120856 2020-07-13 12:09:05 00000001000000000000000C
Ora siamo pronti per eseguire il ripristino utilizzando il barman-cloud-restore comando:
[email protected]:~$ barman-cloud-restore \ --profile barman-cloud \ s3://barman-s3-test \ pg12 20200713T120856 \ /var/lib/postgresql/12/main/
Una volta terminato con successo il ripristino, possiamo controllare il contenuto della directory PGDATA:
[email protected]:~$ ls /var/lib/postgresql/12/main/ PG_VERSION global pg_hba.conf pg_multixact pg_serial pg_stat_tmp pg_twophase postgresql.auto.conf backup_label pg_commit_ts pg_ident.conf pg_notify pg_snapshots pg_subtrans pg_wal postgresql.conf base pg_dynshmem pg_logical pg_replslot pg_stat pg_tblspc pg_xact
Ora, per essere sicuri che il processo di ripristino abbia funzionato correttamente, dobbiamo avviare l'istanza PostgreSQL recuperata e verificare che tutto funzioni come previsto. Questo processo richiede alcuni passaggi aggiuntivi.
Innanzitutto, poiché siamo su un sistema Debian, dobbiamo copiare i file contenenti la configurazione di PostgreSQL sotto /etc/postgresql/12/main/ directory:
[email protected]:~$ cp /var/lib/postgresql/12/main/postgresql.conf /etc/postgresql/12/main/ [email protected]:~$ cp /var/lib/postgresql/12/main/pg_hba.conf /etc/postgresql/12/main/ [email protected]:~$ cp /var/lib/postgresql/12/main/pg_ident.conf /etc/postgresql/12/main/
In secondo luogo, crea il recovery.signal file:
[email protected]:~$ touch /var/lib/postgresql/12/main/recovery.signal
Quindi, disabilita il archive_command per impedire che l'istanza recuperata scriva nello stesso bucket dell'istanza originale:
[email protected]:~$ echo \"archive_command = 'cd .'\" >> /etc/postgresql/12/main/postgresql.conf
Successivamente, devi configurare PostgreSQL per recuperare i file WAL dell'ultima timeline disponibile dal bucket S3 utilizzando barman-cloud-wal-restore nel restore_command :
[email protected]:~$ echo \"restore_command = 'barman-cloud-wal-restore --profile barman-cloud s3://barman-s3-test pg12 %f %p'\" >> /etc/postgresql/12/main/postgresql.conf [email protected]:~$ echo \"recovery_target_timeline = 'latest'\" >> /etc/postgresql/12/main/postgresql.conf
IMPORTANTE :Prima di procedere assicurati che l'istanza PostgreSQL non sia in esecuzione e che la directory di destinazione (la directory dati PostgreSQL predefinita) sia vuota.
Finalmente, siamo pronti per avviare la nuova istanza recuperata:
[email protected]:~# systemctl restart [email protected]
Grande! Come possiamo vedere dal log di PostgreSQL, i file WAL vengono recuperati dal bucket S3 e l'istanza è stata avviata correttamente:
[email protected]:~$ less /var/log/postgresql/postgresql-12-main.log ... 2020-07-13 12:43:25.093 UTC [9458] LOG: starting PostgreSQL 12.3 (Debian 12.3-1.pgdg100+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 8.3.0-6) 8.3.0, 64-bit 2020-07-13 12:43:25.093 UTC [9458] LOG: listening on IPv4 address "127.0.0.1", port 5432 2020-07-13 12:43:25.095 UTC [9458] LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432" 2020-07-13 12:43:25.111 UTC [9459] LOG: database system was interrupted; last known up at 2020-07-13 12:08:56 UTC 2020-07-13 12:43:25.508 UTC [9459] LOG: starting archive recovery 2020-07-13 12:43:26.010 UTC [9459] LOG: restored log file "00000001000000000000000C" from archive 2020-07-13 12:43:26.052 UTC [9459] LOG: redo starts at 0/C000028 2020-07-13 12:43:26.054 UTC [9459] LOG: consistent recovery state reached at 0/C000138 2020-07-13 12:43:26.054 UTC [9458] LOG: database system is ready to accept read only connections 2020-07-13 12:43:26.469 UTC [9459] LOG: restored log file "00000001000000000000000D" from archive 2020-07-13 12:43:26.823 UTC [9459] LOG: redo done at 0/D0001B0 2020-07-13 12:43:27.242 UTC [9459] LOG: restored log file "00000001000000000000000D" from archive 2020-07-13 12:43:27.592 UTC [9459] LOG: selected new timeline ID: 2 2020-07-13 12:43:27.644 UTC [9459] LOG: archive recovery complete 2020-07-13 12:43:27.979 UTC [9458] LOG: database system is ready to accept connections
Conclusione
Come al solito con qualsiasi nuova versione di Barman, consigliamo a tutti di aggiornare i propri sistemi all'ultima versione. Un elenco completo di modifiche e correzioni di bug è disponibile qui.
Tieni presente che se stai già utilizzando barman-cloud-wal-archive o barman-cloud-backup installato tramite pacchetto RPM/Apt e stai aggiornando il tuo sistema, devi installare il barman-cli-cloud pacchetto. Ciò è dovuto al fatto che, con la versione Barman 2.11, tutti gli strumenti relativi al cloud fanno parte del barman-cli-cloud pacchetto come spiegato all'inizio dell'articolo.
Le prossime versioni di Barman potrebbero migliorare l'usabilità e le capacità di automazione del comando recovery, ad esempio preparando un recovery.conf o recovery.signal file come fa il vero Barman.
