Het hebben van regelmatige back-ups van uw PostgreSQL-database alleen is niet voldoende voor noodherstel - u moet ervoor zorgen dat de back-upbestanden toegankelijk en gezond zijn als en wanneer dat nodig is voor een herstelprocedure. Lees verder om enkele voorbeelden te zien van het instellen van geautomatiseerd testen van PostgreSQL-back-ups.
Back-ups gemaakt met pg_basebackup
De pg_basebackup backups bevatten de volledige datadirectory voor een databasecluster. Deze map is meestal verpakt in een tarball, soms met een extra tarball voor WAL-bestanden die zijn gemaakt sinds het begin van de back-up.
Om zo'n pg_basebackup te testen tarball, pak eerst de tarball uit in een lege map. Als er een apart WAL-bestand tarball is, pak dat dan uit in depg_wal map in de nieuwe map:
$ mkdir backup-test
$ cd backup-test
$ tar --no-same-owner xvf /path/to/base.tar.gz
$ mkdir -p pg_wal
$ cd pg_wal
$ tar --no-same-owner xvf /path/to/pg_wal.tar.gzU kunt nu een PostgreSQL-serverproces voor deze map starten:
$ pg_ctl -D path/to/backup-test start(Opmerking:pg_ctl is een opdrachtregeltool die is opgenomen in de standaard Postgres-distributie. Het is overal beschikbaar waar Postgres zelf is, vergelijkbaar met de andere meegeleverde tools zoals psql en pg_dump .Lees hier meer over pg_ctl.)
Als er al een PostgreSQL-server op deze machine is geïnstalleerd/ draait, wilt u waarschijnlijk op een andere poort dan de standaard 5432 starten:
$ pg_ctl -D path/to/backup-test -o "-p 6000 -k /tmp" startAls alles tot nu toe is gelukt, wilt u controleren of de gegevens in uw herstelde database gezond zijn. Als u geautomatiseerde testscripts heeft om tegen uw database uit te voeren, zou het nu een goed moment zijn om op zijn minst een klein aantal van die tests uit te voeren tegen deze herstelde database. Als dat niet het geval is, kun je een aantal snelle controles hacken met psql:
$ psql -p 6000 -d mydb -o /dev/null -c "select * from users limit 1"De bovenstaande opdracht voert een eenvoudige query uit op een tabel die zou moeten bestaan. De exit-code van psql zou u moeten vertellen of de query succesvol was of niet. Natuurlijk kunt u complexere zoekopdrachten uitvoeren, of een .sql-bestand uitvoeren, of zelfs een afzonderlijk testscript dat verbinding maakt met deze database en tests uitvoert.
Als u klaar bent met testen, kunt u het Postgres-serverproces stoppen met:
$ pg_ctl -D path/to/backup-test stopEn ruim de hele uitgepakte databaseclusterdirectory op:
$ rm -rf path/to/backup-testZo ziet het eruit als alles in elkaar zit:
#!/bin/bash
# exit immediately if any step fails
set -eo pipefail
# fetch the latest backup
# TODO: copy out base.tar.gz and pg_wal.tar.gz of latest backup
# create a directory to work in
BACKUP_DIR=/tmp/backup-test
rm -rf $BACKUP_DIR
mkdir $BACKUP_DIR
# unpack the backup archives
tar -C $BACKUP_DIR --no-same-owner xvf /path/to/base.tar.gz
mkdir -p $BACKUP_DIR/pg_wal
tar -C $BACKUP_DIR/pg_wal --no-same-owner xvf /path/to/pg_wal.tar.gz
# start a new Postgres server for the cluster on port 6000
pg_ctl -D $BACKUP_DIR -o "-p 6000 -k /tmp" start
# perform a simple test
psql -p 6000 -d mydb -o /dev/null -c "select * from users limit 1"
# shutdown the server
pg_ctl -D $BACKUP_DIR stop
# cleanup the files
rm -rf $BACKUP_DIR /path/to/base.tar.gz /path/to/pg_wal.tar.gzBack-ups gemaakt met pg_dump
De pg_dump tool (docs) kan ook worden gebruikt om back-ups te maken - dit is flexibeler omdat u optioneel de database/schema/tabellen kunt selecteren waarvan u een back-up wilt maken, in tegenstelling totpg_basebackup wat een alles-of-niets proces is.
Met pg_dump , kunt u een enkele .sql script of een binaire .pgdmp bestand dat alle gegevens bevat (en optioneel ook de DDL-instructies voor het maken van tabellen/indexen enz.). Om een dergelijk bestand te herstellen, moet u verbinding maken met een livedatabase-server en de SQL-opdrachten uitvoeren in het .sql/.pgdmp-bestand. Hoewel je de gewone psql . kunt gebruiken om het .sql-bestand uit te voeren, moet u de pg_restore gebruiken commando (docs) om het .pgdmp-bestand uit te voeren.
Om dergelijke back-ups te testen, halen we eerst het bestand op en maken dan een nieuw, leeg databasecluster:
$ rm -rf path/to/backup-test
$ pg_ctl -D path/to/backup-test initdben start er een PostgreSQL-server op, luisterend op poort 6000 zoals eerder:
$ pg_ctl -D path/to/backup-test -o "-p 6000 -k /tmp" startHet is mogelijk om pg_dump . te genereren bestanden die volledig op zichzelf staan, maar het is ook mogelijk om ze niet te genereren. Daarom kunnen, afhankelijk van hoe de dump is gegenereerd, enkele instellingsstappen vereist zijn:
- maak een database
- tabellen, indexen enz. maken
- rechten verlenen
Zodra dat is gebeurd, kunt u ofwel psql . gebruiken of pg_restore om de gegevens weer tot leven te brengen:
# for .sql files
$ psql -p 6000 -h /tmp -v ON_ERROR_STOP=1 -1 -b -f path/to/dump.sql
# for .pgdmp files
$ pg_restore -p 6000 -h /tmp -d mydb -C -1 -f path/to/dump.pgdmpNet als voorheen kunnen op dit punt tests worden uitgevoerd om de gezondheid van de herstelde gegevens te garanderen.
Hier is hoe het eruit ziet, alles bij elkaar:
#!/bin/bash
# exit immediately if any step fails
set -eo pipefail
# fetch the latest dump
# TODO: copy out the dump.sql or dump.pgdmp of latest backup
# create an empty database cluster
BACKUP_DIR=/tmp/backup-test
rm -rf $BACKUP_DIR
pg_ctl -D $BACKUP_DIR initdb
# start a new Postgres server for the cluster on port 6000
pg_ctl -D $BACKUP_DIR -o "-p 6000 -k /tmp" start
# TODO: perform any specific setup steps here
# restore the file, .sql:
psql -p 6000 -h /tmp -v ON_ERROR_STOP=1 -1 -b -f path/to/dump.sql
# or .pgdmp:
pg_restore -p 6000 -h /tmp -d mydb -C -1 -f path/to/dump.pgdmp
# perform a simple test
psql -p 6000 -d mydb -o /dev/null -c "select * from users limit 1"
# shutdown the server
pg_ctl -D $BACKUP_DIR stop
# cleanup the files
rm -rf $BACKUP_DIR /path/to/dump.*Pas op voor triggers
Tijdens het herstellen van een pg_dump back-up, gegevens worden in tabellen ingevoegd, net zoals wanneer een toepassing dit doet. Als je triggers hebt die verbinding maken met externe services om rij-invoegingen te melden, kun je ze het beste uitschakelen tijdens de herstelprocedure.
Bij het aanroepen van pg_dump om sql-bestanden uit te zenden, kunt u de optie--disable-triggers . gebruiken om pg_dump te vertellen om een script te genereren om de triggers uit te schakelen tijdens het invoegen.
Bij het aanroepen van pg_restore op een database die al triggers heeft, kunt u de --disable-triggers . gebruiken in pg_restore om hetzelfde effect te bereiken.
PITR-testen
Point-in-time-recovery (PITR) in Postgres is afhankelijk van een volledige back-up die wordt gemaakt met pg_basebackup , en een reeks WAL-bestanden vanaf dat punt tot het moment waarop u wilt herstellen. Het testen van PITR omvat daarom het testen van de volledige back-up en de daaropvolgende WAL-bestanden.
Voor geautomatiseerde back-uptests hebben we geen specifiek hersteldoel. Alle gearchiveerde WAL-bestanden vanaf de laatste back-up tot de meest recente moeten worden getest. De eenvoudigste manier om dit te testen is door dezelfde stappen te volgen als voor de pg_basebackup testmethode, met slechts één extra stap. Haal na het uitpakken van de laatste back-up alle relevante en beschikbare WAL-bestanden op en plaats ze in pg_wal voordat u de Postgres-server start. Specifiek:
#!/bin/bash
# exit immediately if any step fails
set -eo pipefail
# fetch the latest backup
# TODO: copy out base.tar.gz and pg_wal.tar.gz of latest backup
# create a directory to work in
BACKUP_DIR=/tmp/backup-test
rm -rf $BACKUP_DIR
mkdir $BACKUP_DIR
# unpack the backup archives
tar -C $BACKUP_DIR --no-same-owner xvf /path/to/base.tar.gz
mkdir -p $BACKUP_DIR/pg_wal
tar -C $BACKUP_DIR/pg_wal --no-same-owner xvf /path/to/pg_wal.tar.gz
# --> this is the new extra step <--
# TODO: fetch all WAL files from the WAL archive since the last
# backup, and place them in $BACKUP_DIR/pg_wal
# start a new Postgres server for the cluster on port 6000
pg_ctl -D $BACKUP_DIR -o "-p 6000 -k /tmp" start
# perform a simple test
psql -p 6000 -d mydb -o /dev/null -c "select * from users limit 1"
# shutdown the server
pg_ctl -D $BACKUP_DIR stop
# cleanup the files
rm -rf $BACKUP_DIR /path/to/base.tar.gz /path/to/pg_wal.tar.gzHiermee moet worden gecontroleerd of zowel de laatste back-up als de daaropvolgende WAL-bestanden goed zijn, zodat ze indien en wanneer nodig voor PITR kunnen worden gebruikt.