Наличието на редовни резервни копия на вашата база данни PostgreSQL само по себе си не е достатъчно за възстановяване при аварии – трябва да се уверите, че архивните файлове са достъпни и здрави, ако и когато е необходимо за процедура по възстановяване. Прочетете, за да видите някои примери за това как да настроите автоматизирано тестване на резервни копия на PostgreSQL.
Архивни копия, направени с помощта на pg_basebackup
pg_basebackup резервните копия съдържат цялата директория с данни за клъстер от база данни. Тази директория обикновено се пакетира в tarball, понякога с допълнителен tarball за WAL файлове, които са създадени от началото на архивирането.
За да тествате такъв pg_basebackup tarball, първо разопаковайте tarball в празна директория. Ако има отделен tarball WAL файл, разопаковайте го в pg_wal директория в новата директория:
$ 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.gzВече можете да стартирате процес на PostgreSQL сървър за тази директория:
$ pg_ctl -D path/to/backup-test start(Забележка:pg_ctl е инструмент от командния ред, включен в стандартната дистрибуция на Postgres. Той е достъпен навсякъде, където е самият Postgres, подобно на другите включени инструменти като psql и pg_dump .Научете повече за pg_ctl тук.)
Ако вече има инсталиран/изпълнен PostgreSQL сървър на тази машина, вероятно ще искате да стартирате на порт, различен от 5432 по подразбиране:
$ pg_ctl -D path/to/backup-test -o "-p 6000 -k /tmp" startАко всичко е било успешно досега, ще искате да проверите дали данните във вашата възстановена база данни са здрави. Ако имате автоматизирани тестови скриптове за изпълнение срещу вашата база данни, сега би било подходящ момент да стартирате поне малък набор от тези тестове срещу тази възстановена база данни. Ако не, можете да хакнете някои бързи проверки с помощта на psql:
$ psql -p 6000 -d mydb -o /dev/null -c "select * from users limit 1"Горната команда прави проста заявка към таблица, която трябва да съществува. Изходният код на psql трябва да ви каже дали заявката е била успешна или не. Разбира се, можете да изпълнявате по-сложни заявки или да стартирате .sql файл или дори отделен testscript, който ще се свърже с тази база данни и ще стартира тестове.
Когато приключите с тестването, можете да спрете процеса на сървъра на Postgres с:
$ pg_ctl -D path/to/backup-test stopИ почистете цялата директория на клъстера на извлечената база данни:
$ rm -rf path/to/backup-testЕто как изглежда, когато всичко е събрано:
#!/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.gzРезервни копия, направени с помощта на pg_dump
pg_dump инструментът (docs) може да се използва и за създаване на резервни копия – това е по-гъвкаво, тъй като можете по избор да изберете базата данни/схемата/таблиците, които искате да архивирате, за разлика отpg_basebackup което е процес на всичко или нищо.
С pg_dump , можете да генерирате единичен .sql скрипт или двоичен .pgdmp файл, който съдържа всички данни (и по избор също DDL изразите за създаване на таблици/индекси и т.н.). За да възстановите такъв файл, трябва да се свържете със сървър на livedatabase и да изпълните SQL командите във файла .sql/.pgdmp. Докато можете да използвате обикновения psql за да стартирате .sql файла, ще трябва да използвате pg_restore команда (docs) за стартиране на файла .pgdmp.
За да тестваме такива архиви, първо извличаме файла и след това създаваме нов, празен клъстер от база данни:
$ rm -rf path/to/backup-test
$ pg_ctl -D path/to/backup-test initdbи стартирайте PostgreSQL сървър на него, като слушате на порт 6000 както преди:
$ pg_ctl -D path/to/backup-test -o "-p 6000 -k /tmp" startВъзможно е да се генерира pg_dump файлове, които са напълно самостоятелни, но също така е възможно да се генерират, за да не са така. Следователно, в зависимост от това как е генериран дъмпът, може да са необходими някои стъпки за настройка:
- създайте база данни
- създайте таблици, индекси и т.н.
- предоставяне на привилегии
След като това стане, можете да използвате или psql или pg_restore за да върнете данните към живот:
# 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.pgdmpКакто и преди, на този етап могат да се извършат тестове, за да се гарантира здравината на съхранените данни.
Ето как изглежда всичко заедно:
#!/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.*Внимавайте за тригери
Докато възстановявате pg_dump архивиране, данните се вмъкват в таблици, подобно на това, когато приложението го прави. Ако имате тригери, които се свързват с външни услуги, за да уведомяват за вмъкване на ред, най-добре е да ги деактивирате по време на процедурата за възстановяване.
При извикване на pg_dump за да излъчвате sql файлове, можете да използвате опцията--disable-triggers да кажете на pg_dump за генериране на скрипт за деактивиране на тригерите по време на вмъкване.
При извикване на pg_restore на база данни, която вече има тригери, можете да използвате --disable-triggers в pg_restore за постигане на същия ефект.
PITR тестване
Възстановяването по точката (PITR) в Postgres разчита на пълно архивиране, направено с помощта наpg_basebackup и поредица от WAL файлове от този момент до момента, в който искате да възстановите. Следователно тестването на PITR включва тестване на пълния архив, както и на последващите WAL файлове.
За автоматично тестване на архивиране нямаме конкретна цел за възстановяване. Всички архивирани WAL файлове от последното архивиране нататък до последния трябва да бъдат тествани. Най-лесният начин да тествате това е да следвате същите стъпки като за pg_basebackup метод за изпитване, само с една допълнителна стъпка. След като разопаковате най-новото архивно копие, извлечете всички подходящи и налични WAL файлове и ги поставете в pg_wal преди да стартирате сървъра на Postgres. По-конкретно:
#!/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.gzТова трябва да провери дали и последното архивиране, и следващите WAL файлове са добри, така че да могат да се използват за PITR, ако и когато е необходимо.
