Общие параметры

Параметры резервного копирования

Параметры восстановления и проверки

Параметры удаления

Параметры сохранения

Параметры подключения

pg_probackup также принимает из командной строки следующие параметры подключения:

Первоначальная настройка

Независимо от того или иного сценария использования, сначала требуется выполнить настройку сервера Postgres Pro и инициализацию каталога резервных копий.

Настройка pg_probackup, как и дальнейшая работа с утилитой, выполняется пользователем-владельцем службы Postgres Pro (обычно postgres).

Для выполнения резервного копирования pg_probackup требуется подключение к серверу БД от имени пользователя с правами, достаточными для выполнения некоторых административных функций. Если планируется использовать автономные резервные копии, пользователь также должен обладать атрибутом REPLICATION. Можно подключаться от имени суперпользователя, но лучше создать отдельного пользователя со следующими минимально необходимыми правами:

CREATE ROLE backup WITH LOGIN REPLICATION;
GRANT USAGE ON SCHEMA pg_catalog TO backup;
GRANT EXECUTE ON FUNCTION current_setting(text) TO backup;
GRANT EXECUTE ON FUNCTION pg_is_in_recovery() TO backup;
GRANT EXECUTE ON FUNCTION pg_start_backup(text, boolean, boolean) TO backup;
GRANT EXECUTE ON FUNCTION pg_stop_backup() TO backup;
GRANT EXECUTE ON FUNCTION pg_stop_backup(boolean) TO backup;
GRANT EXECUTE ON FUNCTION pg_switch_xlog() TO backup;
GRANT EXECUTE ON FUNCTION txid_current() TO backup;
GRANT EXECUTE ON FUNCTION txid_current_snapshot() TO backup;
GRANT EXECUTE ON FUNCTION txid_snapshot_xmax(txid_snapshot) TO backup;
     

При использовании сервера Postgres Pro необходимы дополнительные права для выполнения инкрементального копирования:

GRANT EXECUTE ON FUNCTION pg_ptrack_clear() TO backup;
GRANT EXECUTE ON FUNCTION pg_ptrack_get_and_clear(oid, oid) TO backup;
     

Конфигурация сервера Postgres Pro в pg_hba.conf должна разрешать подключение для выбранного пользователя. Если планируется использовать автономные резервные копии, должно быть разрешено и подключение по протоколу репликации; кроме того, значение max_wal_senders должно быть достаточно большим, чтобы допускать подключение pg_probackup для копирования файлов WAL во время выполнения резервной копии.

В параметре wal_level должен быть задан уровень не ниже replica (а для версий до 9.5 включительно — archive).

Для первоначальной инициализации каталога резервных копий выполните команду:

pg_probackup init -B каталог_резервных_копий -D каталог_данных
     

Ключ -B указывает расположение каталога, который будет в дальнейшем использоваться как каталог резервных копий. Поскольку расположение каталога необходимо для всех команд pg_probackup, имеет смысл один раз задать его в переменной окружения BACKUP_PATH.

Ключ -D указывает расположение каталога с данными сервера. Его удобно задать с помощью переменной окружения PGDATA, чтобы не указывать каждый раз в командной строке. В дальнейших примерах оба этих ключа будут для краткости опускаться.

Утилита создаёт указанный каталог, а также необходимые файлы и подкаталоги внутри него:

Каталог резервных копий может быть создан и заранее, но должен быть пустым.

Автономные резервные копии

Самый простой способ резервного копирования, не требующий организации непрерывного архивирования на сервере Postgres Pro — автономные резервные копии. Они содержат как файлы кластера баз данных, так и файлы WAL, необходимые для восстановления.

Из автономной копии, в отсутствие архива WAL-файлов, кластер можно восстановить ровно на момент создания этой копии.

Чтобы сделать автономную резервную копию, выполните команду:

pg_probackup backup -b full --stream
     

Дополнительно в этой команде необходимо указать параметры для соединения с сервером. Эти параметры задаются точно так же, как и в других утилитах Postgres Pro: либо ключами в командной строке (-h/--host, -p/--port, -U/--username, -d/--dbname), либо переменными окружения (PGHOST, PGPORT, PGUSER, PGDATABASE), либо выбираются значения по умолчанию (локальное подключение, имя пользователя БД и имя базы данных совпадает с именем пользователя ОС). В качестве базы данных можно использовать любую БД кластера.

Чтобы просмотреть существующие резервные копии, выполните команду:

pg_probackup show
     

Выводится следующая информация:

Более подробную информацию о копии можно получить, указав в команде show её идентификатор:

pg_probackup show ид_резервной_копии
     

Каждая резервная копия автоматически проверяется на совпадение контрольных сумм сразу после её создания, чтобы убедиться, что она корректно записана на диск. Повторно проверить корректность копии можно, выполнив команду:

pg_probackup validate ид_резервной_копии
     

За подробностями обратитесь к Подразделу «Проверка целостности кластера и резервной копии» и Подразделу «Проверка резервных копий».

Чтобы восстановить кластер из сделанной резервной копии, сначала остановите службу Postgres Pro (если она работает), а затем выполните команду:

pg_probackup restore ид_резервной_копии
     

Затем запустите сервер. При старте сервер Postgres Pro восстановит согласованное состояние из файлов WAL и будет готов к работе.

Обратите внимание, что восстановление из резервной копии может быть выполнено только утилитой pg_probackup. Внутри каталога каталог_резервных_копий/backups/ид_резервной_копии/database/ можно обнаружить файлы, соответствующие содержимому каталога данных сервера, но скопировать их вручную нельзя: pg_probackup всегда хранит файлы данных в упакованном виде, чтобы они занимали меньше места на диске.

Непрерывное архивирование и полные копии

Использование непрерывного архивирования позволяет восстанавливать кластер не только на момент создания резервной копии, но и на произвольный момент. В большинстве случаев pg_probackup применяется совместно с непрерывным архивированием.

Заметьте, что автономные резервные копии всё равно могут оказаться полезными:

Для настройки непрерывного архивирования на сервере Postgres Pro дополнительно присвойте указанные значения параметрам:

Копирование файлов по сети (например, с помощью rsync) в настоящее время не поддерживается; файлы должны быть доступны в файловой системе сервера. Для доступа к файлам на удалённом сервере можно использовать сетевую файловую систему.

Для создания резервной копии выполните команду (также указав при необходимости параметры подключения к серверу):

pg_probackup backup -b full
     

В такую резервную копию попадут только файлы данных кластера. Необходимые для восстановления файлы WAL будут взяты из архива в каталог_резервных_копий/wal/.

Чтобы восстановить кластер из резервной копии, убедитесь в том, что сервер остановлен, а затем выполните:

pg_probackup restore
     

Произойдёт восстановление баз данных из последней доступной резервной копии и будет создан файл recovery.conf для доступа к архивированным файлам WAL. При запуске сервер Postgres Pro автоматически восстановит состояние, используя все имеющиеся в архиве файлы WAL.

Чтобы восстановить кластер на произвольный момент времени в прошлом, можно дополнительно указать следующие параметры (соответствующие аналогичным параметрам восстановления в recovery.conf):

pg_probackup автоматически выбирает резервную копию, ближайшую к указанной точке, и начинает восстановление.

Приведённые команды будут работать с автономными резервными копиями точно так же, как и с полными, используя при необходимости файлы WAL как из самой копии, так и из архива.

Вы можете вызвать команду restore с указанием идентификатора конкретной резервной копии, чтобы восстановить кластер на момент времени, указанный в поле 'Recovery time' этой копии:

pg_probackup restore ид_резервной_копии
     

Если это автономная копия, то при восстановлении архив WAL не будет задействован; для полной копии архив будет использован только для восстановления согласованности.

Если в команде restore указать и идентификатор резервной копии, и один из ключей --time или --xid, то восстановление начнётся с заданной копии и продолжится до указанной точки. Обычно в таком режиме нет необходимости, так как можно не указывать идентификатор и подходящая резервная копия будет выбрана автоматически.

Инкрементальные резервные копии

В дополнение к полным резервным копиям pg_probackup позволяет делать инкрементальные копии, в которые попадают только те страницы данных, которые изменились с момента выполнения предыдущей резервной копии. За счёт этого резервные копии получаются меньшего размера, и в ряде случаев процесс резервного копирования выполняется быстрее.

Существует два режима выполнения инкрементальных копий: с отслеживанием изменений либо по журналу (PAGE), либо в процессе работы (PTRACK).

В первом случае pg_probackup сканирует файлы WAL, находящиеся в архиве, с момента выполнения прошлой резервной копии (полной или инкрементальной). В новую резервную копию попадут только те страницы, изменения в которых отмечены в журнале.

При таком способе необходимо, чтобы в архиве находились все файлы WAL с момента выполнения прошлой резервной копии. Если суммарный размер этих файлов сопоставим с размером кластера, то такой способ не даст выигрыша по времени (хотя по-прежнему может дать выигрыш по размеру резервной копии).

pg_probackup backup -b page
     

Второй способ с отслеживанием изменений в процессе работы требует сервера Postgres Pro и не будет работать со стандартным PostgreSQL, но для него не требуется архивирование журнала.

При включённом параметре ptrack_enable сервер Postgres Pro отслеживает изменения в страницах данных: каждый раз, когда формируется запись журнала WAL, затрагивающая определённую страницу того или иного отношения, эта страница отмечается в специальном слое ptrack этого отношения. Поскольку на каждую страницу необходим только один бит в этом слое, он не занимает много места, но позволяет существенно ускорить выполнение резервного копирования. Отслеживание требует незначительных накладных расходов в процессе работы сервера.

Когда утилита pg_probackup выполняет резервное копирование (в любом режиме, полном или инкрементальном), она очищает слой ptrack обрабатываемых отношений. Таким образом, при следующем запуске резервного копирования в инкрементальную копию попадут только те страницы, которые были изменены с момента выполнения прошлой копии.

pg_probackup backup -b ptrack
     

Если резервное копирование завершится с ошибкой (например, будет прервано), у части отношений слой ptrack скорее всего уже будет очищен. В этом случае следующая инкрементальная копия окажется бесполезной, так как будет содержать только часть изменений. То же касается и ситуации, когда параметр ptrack_enable был включён уже после выполнения полной копии или выключался на какое-то время. В настоящее время pg_probackup не проверяет, что отслеживание изменений оставалось включённым в течение всего времени, охваченного инкрементом. Поэтому в таких ситуациях перед тем, как выполнять инкрементальные резервные копии, сначала необходимо заново сделать полную.

Чтобы восстановить кластер из инкрементальной резервной копии, pg_probackup сначала восстанавливает полную резервную копию, а затем последовательно накладывает на неё все необходимые инкрементальные копии. Это происходит автоматически; управление восстановлением осуществляется точно так же, как для полных копий.

Инкрементальную копию можно сделать автономной (указав ключ --stream). Автономность здесь понимается только как независимость от архива WAL: для восстановления понадобятся и полная копия и, если необходимо, предыдущие инкрементальные копии.

Настройка политики сохранения резервных копий

По умолчанию все резервные копии, которые создаёт pg_probackup, сохраняются в предназначенном для них каталоге. Для экономии дискового пространства вы можете настроить политику сохранения копий, чтобы в соответствии с ней система периодически удаляла ненужные резервные копии.

Чтобы настроить эту политику, задайте одну или несколько следующих переменных в файле pg_probackup.conf:

Чтобы просмотреть параметры текущей политики сохранения копий, выполните эту команду:

pg_probackup retention show

Чтобы очистить каталог резервных копий в соответствии с политикой их сохранения, запустите:

pg_probackup retention purge

pg_probackup удаляет все резервные копии и соответствующие файлы WAL, которые не удовлетворяют политике, определённой в файле pg_probackup.conf. Если установлены параметры redundancy и window, pg_probackup оставляет только те резервные копии, которые удовлетворяют обоим условиям. Например, если задать параметры redundancy=2 и window=7, pg_probackup очищает каталог копий, чтобы в нём оставалось только две полных резервных копии, если минимум одна из них старее 7 дней.

Политику по умолчанию также можно переопределить, используя параметры командной строки --redundancy и --window. Например:

pg_probackup retention purge --redundancy=3 --window=5

В результате pg_probackup будет сохранять три резервные копии, и минимум одна из них будет старее пяти дней.

Удаление резервных копий

Ставшую ненужной резервную копию можно удалить, указав её идентификатор в команде delete:

pg_probackup delete ид_резервной_копии
     

Эта команда удалит указанную копию, а также все следующие за ней инкрементальные копии, если они существуют.

Таким образом можно удалить последние инкрементальные копии, сохранив предыдущую полную копию и часть следующих за ней инкрементальных копий. В этом случае следующая резервная копия в режиме PTRACK окажется некорректной, так как не будет содержать часть изменений с момента создания последней оставшейся копии. Поэтому в таком случае необходимо создавать либо полную резервную копию, либо инкрементальную в режиме PAGE (если все необходимые файлы WAL сохранились в архиве).

Если указан ключ --wal, при удалении будут также удалены файлы WAL, которые больше не нужны для восстановления никаких оставшихся резервных копий. Это безопасный режим, поскольку удаление любой резервной копии не приведёт к потере файлов WAL, которые могут понадобиться.

Для того, чтобы удалить ненужные файлы журнала WAL, не удаляя резервные копии, воспользуйтесь командой delwal:

pg_probackup delwal
     

Эта команда действует аналогично ключу --wal команды delete, но не удаляет никакие резервные копии.

В команде delwal можно также указать идентификатор резервной копии. В этом случае будут удалены все файлы WAL, кроме тех, которые нужны для восстановления из указанной копии и более поздних.

pg_probackup delwal ид_резервной_копии
     

Будьте осторожны с этим режимом, поскольку он позволяет удалить файлы WAL, необходимые для восстановления из какой-либо существующей резервной копии.

Вы также можете настроить политику сохранения копий, чтобы в соответствии с ней система периодически удаляла ненужные резервные копии. Подробности описаны в Подразделе «Настройка политики сохранения резервных копий».

Резервная копия с реплики

Если используется репликация, то, начиная с версии сервера 9.6, резервная копия может быть выполнена не только с основного сервера, но и с реплики. Резервная копия с реплики ничем не отличается от резервной копии с ведущего сервера (конечно, надо иметь в виду возможные задержки репликации). Инкрементальные резервные копии на уровне страниц с ведомого сервера не поддерживаются.

В настоящий момент требуется, чтобы на ведущем сервере был включён параметр full_page_writes (в будущем это требование возможно будет снято, если в кластере включены контрольные суммы на страницах данных).

Вы можете использовать для pg_probackup один и тот же каталог резервных копий, доступный в файловой системе обоих серверов. В этом случае все резервные копии, независимо от того, были ли они сделаны на ведущем сервере или на реплике, будут отображаться вместе и ими можно будет одинаково управлять как с одного сервера, так и с другого.

Резервная копия может быть использована для восстановления как ведущего сервера, так и реплики, в зависимости от того, на каком из серверов будет вызвана утилита pg_probackup с командой restore. Обратите внимание: если после pg_probackup сразу же запустить сервер Postgres Pro, он запустится в качестве ведущего. Если предполагается использовать его в качестве реплики, необходимо вручную отредактировать созданный файл recovery.conf: как минимум убрать все указания на конечную точку восстановления (recovery_target, recovery_target_time и recovery_target_xid), указать в качестве целевой линии времени 'latest' и добавить параметр standby_mode = 'on'. Вероятно, вам также понадобится добавить параметр primary_conninfo для потоковой репликации и задать hot_standby = 'on' в конфигурации сервера для горячего резерва.

Параллельное выполнение

Резервное копирование, восстановление и проверка копии могут выполняться в несколько параллельных потоков. Это может существенно ускорить процесс при наличии достаточных ресурсов (ядер процессора, пропускной способности дисковой подсистемы и сети).

Параллельное выполнение управляется ключом -j/--threads, например:

pg_probackup backup -b full -j 4
     

или

pg_probackup restore -j 4
     

Заметьте, что параллельное восстановление относится только к переносу данных из резервной копии в каталог кластера. При запуске сервера Postgres Pro он будет последовательно применять записи WAL (из архива или из локального каталога), и в настоящее время этот процесс всегда выполняется в один поток.

Проверка целостности кластера и резервной копии

Если в кластере включены контрольные суммы на страницах данных, pg_probackup использует эту информацию для того, чтобы выполнять проверку корректности файлов. При чтении каждой страницы проверяется совпадение записанной в ней контрольной суммы с рассчитанным значением. Таким образом гарантируется, что в резервную копию не попадут уже повреждённые страницы, а при создании полной резервной копии попутно будет проверено состояние всего кластера.

В резервной копии страницы хранятся в упакованном виде — незанятые их области не копируются (см. Раздел 65.6). Поэтому восстановленный кластер не будет в точности совпадать с оригиналом, но сохранит при этом двоичную совместимость.

Независимо от конфигурации сервера, pg_probackup подсчитывает контрольную сумму для каждого файла, записанного в резервную копию. Контрольная сумма проверяется сразу после завершения резервного копирования и перед восстановлением, так что повреждение резервной копии будет обнаружено своевременно.

Проверка резервных копий

До восстановления кластера баз данных вы можете проверить имеющиеся резервные копии. Чтобы убедиться, что восстановление возможно, запустите команду validate с точными параметрами, которые вы планируете использовать для восстановления. Программа pg_probackup проверит, все ли требуемые файлы резервных копий присутствуют и могут быть использованы для восстановления баз данных при необходимости.

Например, чтобы убедиться, что вы можете восстановить кластер баз данных из определённой копии (с ид_резервной копии) до транзакции с указанным xid, выполните команду:

pg_probackup validate --xid=xid ид_резервной_копии

Список доступных параметров приведён в Разделе «Параметры».

Если проверка проходит успешно, pg_probackup выдаёт сообщение об этом. В случае же неудачи вы получите сообщение об ошибке с указанием точного времени и идентификатора транзакции, до которой возможно восстановление.