pg_probackup

pg_probackup — управление резервным копированием и восстановлением кластеров баз данных Postgres Pro

Синтаксис

pg_probackup version

pg_probackup help [команда]

pg_probackup init -B каталог_копий

pg_probackup add-instance -B каталог_копий -D каталог_данных --instance имя_экземпляра

pg_probackup del-instance -B каталог_копий --instance имя_экземпляра

pg_probackup set-config -B каталог_копий --instance имя_экземпляра [параметр...]

pg_probackup set-backup -B каталог_копий --instance имя_экземпляра -i ид_резервной_копии [параметр...]

pg_probackup show-config -B каталог_копий --instance имя_экземпляра [--format=формат]

pg_probackup show -B каталог_копий [параметр...]

pg_probackup backup -B каталог_копий --instance имя_экземпляра -b режим_копирования [параметр...]

pg_probackup restore -B каталог_копий --instance имя_экземпляра [параметр...]

pg_probackup checkdb -B каталог_копий --instance имя_экземпляра -D каталог_данных [параметр...]

pg_probackup validate -B каталог_копий [параметр...]

pg_probackup merge -B каталог_копий --instance имя_экземпляра -i ид_резервной_копии [параметр...]

pg_probackup delete -B каталог_копий --instance имя_экземпляра { -i ид_резервной_копии | --delete-wal | --delete-expired | --merge-expired } [параметр...]

pg_probackup archive-push -B каталог_копий --instance имя_экземпляра --wal-file-path путь_файла_wal --wal-file-name имя_файла_wal [параметр...]

pg_probackup archive-get -B каталог_копий --instance имя_экземпляра --wal-file-path путь_файла_wal --wal-file-name имя_файла_wal [параметр...]

Описание

pg_probackup — это утилита для управления резервным копированием и восстановлением кластеров баз данных Postgres Pro. Она предназначена для регулярного создания резервных копий экземпляра Postgres Pro, позволяющих восстанавливать сервер в случае необходимости. pg_probackup поддерживает Postgres Pro версии 9.5 и новее.

Обзор

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

  • Инкрементальное копирование: выбирая один из трёх режимов инкрементального копирования, вы можете реализовать стратегию резервного копирования, соответствующую вашему профилю транзакционной нагрузки. Это позволяет сэкономить место на диске и создавать копии быстрее, чем при полном копировании. Восстановление инкрементальных копий также осуществляется быстрее, чем воспроизведение файлов WAL.

  • Проверка: автоматический контроль целостности данных и проверка резервных копий без восстановления данных кластера.

  • Контроль целостности: выполняемая по запросу проверка экземпляра Postgres Pro с помощью команды checkdb.

  • Политика хранения: управление архивами WAL и резервными копиями в соответствии с установленными правилами их хранения. Вы можете ограничить хранение резервных копий по времени или их количеству, а также переопределить время жизни (TTL) для избранных копий. Потерявшие актуальность резервные копии могут объединяться или удаляться.

  • Параллельное выполнение: выполнение внутренних процессов команд backup, restore, merge, delete, validate и checkdb в несколько параллельных потоков.

  • Сжатие: хранение копируемых данных в сжатом состоянии для экономии дискового пространства.

  • Исключение дублирования: экономия дискового пространства за счёт фильтрации файлов, не содержащих данные, таких как _vm или _fsm.

  • Удалённый режим работы: выполнение резервного копирования экземпляра Postgres Pro, находящегося в удалённой системе, и удалённое восстановление.

  • Получение резервной копии с ведомого: исключение дополнительной нагрузки на ведущий сервер.

  • Архивирование внешних каталогов: резервное копирование файлов и каталогов, расположенных вне каталога данных Postgres Pro (PGDATA), например скриптов, файлов конфигурации, журналов или SQL-дампов.

  • Каталогизация резервных копий: получение списка резервных копий и соответствующей метаинформации в виде простого текста или JSON.

  • Каталогизация архивов WAL: получение списка всех линий времени в WAL и соответствующей метаинформации в виде простого текста или JSON.

  • Частичное восстановление: восстановление только избранных баз данных.

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

Используя pg_probackup, вы можете выполнять полное или инкрементальное резервное копирование:

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

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

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

    • Страничное копирование. В режиме PAGE pg_probackup сканирует все файлы WAL в архиве с момента создания предыдущей полной или инкрементальной копии. Новая резервная копия будет содержать только страницы, фигурирующие в записях WAL. При этом необходимо, чтобы в архиве WAL сохранялись все файлы WAL, записанные после предыдущей копии. Если размер этих файлов сравним с общим размером файлов базы данных, ускорение будет менее значительным, но размер копии будет всё же меньше.

    • Копирование изменений. В режиме PTRACK Postgres Pro отслеживает изменения страниц на лету. Чтобы он работал, не требуется производить непрерывное архивирование WAL. При каждом изменении страницы отношения она помечается в специальной карте PTRACK этого отношения. Так как для одной страницы в слое PTRACK требуется всего один бит, такие карты довольно малы. Это отслеживание привносит небольшие издержки в работу сервера, но значительно ускоряет инкрементальное резервное копирование.

pg_probackup может производить копирование только работающего экземпляра, а для обеспечения целостности таких копий требуется копировать WAL. Поэтому вне зависимости от выбранного режима копирования (FULL, PAGE или DELTA), чтобы pg_probackup мог получить полноценную копию, нужно выбрать один из следующих режимов доставки WAL:

  • ARCHIVE. В таком режиме целостность копий обеспечивается посредством непрерывного архивирования. Это режим доставки WAL по умолчанию.

  • STREAM. Такие резервные копии включают все файлы, необходимые для восстановления целостного состояния кластера на момент создания копии. Вне зависимости от того, осуществляется ли непрерывное архивирование, необходимые для восстановления сегменты WAL считываются по протоколу потоковой репликации во время резервного копирования и включаются в состав резервной копии. Поэтому такие резервные копии называются автономными или самодостаточными.

Ограничения

В настоящее время pg_probackup имеет следующие ограничения:

  • pg_probackup работает с серверами версии 9.5 или новее.

  • Режим удалённого сервера на платформе Windows не поддерживается.

  • В Unix-системах копию базы Postgres Pro версии 10 можно сделать только от имени того пользователя, который запускает сервер Postgres Pro. Например, если сервер Postgres Pro запускает пользователь postgres, команду backup также должен выполнять пользователь postgres. Для удовлетворения этого требования в случае использования удалённого режима и SSH в параметре --remote-user необходимо передать postgres.

  • С PostgreSQL 9.5 функции pg_create_restore_point(text) и pg_switch_xlog() могут выполняться, только если пользователь резервного копирования имеет права суперпользователя. Поэтому резервное копирование кластера с низкой активностью в WAL обычным пользователем может занять больше времени, чем копирование того же кластера с правами суперпользователя.

  • На сервере Postgres Pro, где была сделана копия, и на сервере, где она будет восстанавливаться, должны быть одинаковые значения параметров block_size и wal_block_size и одинаковая основная версия. В зависимости от конфигурации кластера, Postgres Pro может накладывать дополнительные ограничения, например, по архитектуре процессора и версии libc/libicu.

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

Установка и подготовка

Установив pg_probackup, выполните следующие действия:

  • Инициализируйте каталог резервных копий.

  • Добавьте копируемый экземпляр в каталог копий.

  • Настройте кластер баз данных для использования pg_probackup.

  • Настройте SSH для выполнения операций pg_probackup в удалённом режиме, если вы планируете его использовать.

Инициализация каталога резервных копий

pg_probackup сохраняет все файлы копируемых данных и WAL в соответствущих подкаталогах каталога резервных копий.

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

pg_probackup init -B каталог_копий

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

Пользователь, запускающий pg_probackup, должен иметь полный доступ к каталогу_копий.

pg_probackup создаёт каталог_копий со следующими подкаталогами:

  • wal/ — каталог для файлов WAL.

  • backups/ — каталог для файлов резервных копий.

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

Определение копируемого экземпляра

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

Для определения копируемого экземпляра выполните команду:

pg_probackup add-instance -B каталог_копий -D каталог_данных --instance имя_экземпляра [параметры_удалённого_режима]

Здесь:

  • каталог_данных — каталог, содержащий данные кластера, копию которого вы хотите сделать. Для подготовки и использования pg_probackup необходимо иметь право записи в этот каталог.

  • имя_экземпляра — это имя подкаталогов, в которых будут храниться файлы копируемых данных и WAL для этого кластера.

  • параметры_удалённого_режима должны задаваться дополнительно, если каталог_данных располагается удалённо.

pg_probackup создаёт подкаталоги имя_экземпляра в каталогах backups/ и wal/ каталога резервных копий. Каталог backups/имя_экземпляра содержит файл конфигурации pg_probackup.conf с параметрами pg_probackup, относящимися к данному экземпляру копии. Если этой команде передать параметры_удалённого_режима, они будут добавлены в pg_probackup.conf.

Более подробно тонкая настройка pg_probackup описывается в Подразделе «Настройка pg_probackup».

Пользователь, запускающий pg_probackup, должен иметь полный доступ к каталогу_копий и как минимум доступ на чтение всего содержимого каталога_данных. Если вы зададите путь к каталогу копий в переменной окружения BACKUP_PATH, соответствующий параметр в командах pg_probackup можно не указывать.

Настройка кластера баз данных

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

Для выполнения резервного копирования роль backup должна иметь следующие разрешения на сервере Postgres Pro (только в базе данных, к которой производится подключение):

Для PostgreSQL 9.5:

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

Для Postgres Pro 9.6:

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

Для Postgres Pro версии 10 или новее:

BEGIN;
CREATE ROLE backup WITH LOGIN;
GRANT USAGE ON SCHEMA pg_catalog TO backup;
GRANT EXECUTE ON FUNCTION pg_catalog.current_setting(text) TO backup;
GRANT EXECUTE ON FUNCTION pg_catalog.pg_is_in_recovery() TO backup;
GRANT EXECUTE ON FUNCTION pg_catalog.pg_start_backup(text, boolean, boolean) TO backup;
GRANT EXECUTE ON FUNCTION pg_catalog.pg_stop_backup(boolean, boolean) TO backup;
GRANT EXECUTE ON FUNCTION pg_catalog.pg_create_restore_point(text) TO backup;
GRANT EXECUTE ON FUNCTION pg_catalog.pg_switch_wal() TO backup;
GRANT EXECUTE ON FUNCTION pg_catalog.pg_last_wal_replay_lsn() TO backup;
GRANT EXECUTE ON FUNCTION pg_catalog.txid_current() TO backup;
GRANT EXECUTE ON FUNCTION pg_catalog.txid_current_snapshot() TO backup;
GRANT EXECUTE ON FUNCTION pg_catalog.txid_snapshot_xmax(txid_snapshot) TO backup;
GRANT EXECUTE ON FUNCTION pg_catalog.pg_control_checkpoint() TO backup;
COMMIT;

В файле pg_hba.conf разрешите подключение к кластеру баз данных пользователю с именем backup.

Программа pg_probackup должна читать непосредственно файлы кластера, поэтому запускать pg_probackup (или подключаться к нему удалённо) нужно от имени пользователя ОС, который имеет доступ на чтение всех файлов и каталогов внутри каталога данных кластера (PGDATA), подлежащего копированию.

В зависимости от того, будете ли вы делать самодостаточные или архивные копии, конфигурация кластера Postgres Pro будет разной (об особенностях рассказывается ниже). Чтобы получить копию кластера баз данных с ведомого сервера, запустить pg_probackup в удалённом режиме или создать резервную копию PTRACK, требуется дополнительная настройка.

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

Настройка потокового резервного копирования

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

  • Дайте право REPLICATION роли backup:

    ALTER ROLE backup WITH REPLICATION;
  • В файле pg_hba.conf разрешите выполнение репликации для роли backup.

  • Установите для параметра max_wal_senders достаточно большое значение, предусматривающее минимум одно подключение для процесса резервного копирования.

  • Задайте для параметра wal_level значение выше minimal.

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

После этих подготовительных действий вы можете делать резервные копии в режимах FULL, PAGE, DELTA и PTRACK, используя потоковую доставку WAL.

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

Для выполнения копирования в режиме PAGE, восстановления на момент времени и создания резервных копий с использованием режима доставки WAL ARCHIVE должно осуществляться непрерывное архивирование WAL. Чтобы настроить непрерывное архивирование, выполните следующие действия:

  • Задайте для параметра wal_level значение выше minimal.

  • Если вы настраиваете резервное копирование на ведущем сервере, параметр archive_mode должен иметь значение on или always. Для выполнения резервного копирования на ведомом требуется значение always.

  • Установите параметр archive_command:

    archive_command = 'путь_инсталляции/pg_probackup archive-push -B каталог_копий --instance имя_экземпляра --wal-file-path=%p --wal-file-name=%f [параметры_удалённого_режима]'

Здесь путь_инсталляции — путь к каталогу установленной версии pg_probackup, которую вы хотите использовать, каталог_копий и имя_экземпляра должны указывать на уже проинициализированный для данного кластера БД копируемый экземпляр, а параметры_удалённого_режима должны задаваться только в случае расположения архива WAL в удалённой системе. Подробнее все возможные параметры archive-push рассматриваются в описании archive-push.

После этих подготовительных действий вы сможете использовать режим доставки WAL ARCHIVE и делать резервные копии в режиме PAGE, а также выполнять восстановление на момент времени.

Вы можете просмотреть текущее состояние архива WAL, воспользовавшись командой show. За подробностями обратитесь к Подразделу «Просмотр оглавления архива WAL».

Если вы планируете выполнять страничное копирование и/или делать копии с ведомого сервера, используя режим доставки WAL ARCHIVE, при недостаточной транзакционной активности может потребоваться долго ждать заполнения очередного сегмента WAL. Чтобы ограничить время ожидания, вы можете воспользоваться параметром Postgres Pro archive_timeout на ведущем сервере. Значение этого параметра должно быть меньше значения --archive-timeout (по умолчанию 5 минут), чтобы заполненный сегмент успел передаться ведомому серверу и попасть в архив WAL, прежде чем копирование прервётся по тайм-ауту, заданному параметром --archive-timeout.

Примечание

Вместо использования команды pg_probackup archive-push вы можете воспользоваться любым другим средством, при условии, что в процессе непрерывного архивирования сегменты WAL будут попадать в каталог каталог_копий/wal/имя_экземпляра. Для сжатия сегментов, если в нём есть потребность, должен использоваться алгоритм gzip, а сжатые файлы сегментов должны иметь расширение .gz.

Примечание

Организовать непрерывное архивирование можно не только с помощью параметров archive_mode и archive_command, но и применяя утилиту pg_receivexlog. В этом случае аргумент pg_receivexlog -D каталог должен указывать на каталог каталог_копий/wal/имя_экземпляра. Программа pg_probackup принимает сжатые WAL, которые может сохранять pg_receivexlog. Стратегию архивирования «без потерь» можно реализовать только с использованием pg_receivexlog.

Настройка копирования с ведомого сервера

С Postgres Pro 9.6 или новее pg_probackup может копировать данные с ведомого сервера. Для этого требуется дополнительная настройка:

После этих подготовительных действий вы можете делать резервные копии с ведомого сервера в режимах FULL, PAGE, DELTA или PTRACK, используя режим доставки WAL ARCHIVE или STREAM.

Копирование с ведомого сервера имеет следующие ограничения:

  • Если ведомый сервер повышается до ведущего во время копирования, копирование прерывается с ошибкой.

  • Все необходимые для резервной копии записи WAL должны содержать полные страницы. Для этого требуется включить режим full_page_writes на ведущем сервере и отказаться от использования в archive_command утилит, удаляющих полные страницы из файлов WAL, как, например, pg_compresslog.

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

Для логической проверки кластера БД требуется дополнительная настройка (предполагается, что настройка производится для роли backup):

  • Установите расширение amcheck или amcheck_next в каждой базе кластера:

    CREATE EXTENSION amcheck;
  • Дайте роли backup в каждой базе данных кластера следующие права:

GRANT SELECT ON TABLE pg_catalog.pg_am TO backup;
GRANT SELECT ON TABLE pg_catalog.pg_class TO backup;
GRANT SELECT ON TABLE pg_catalog.pg_database TO backup;
GRANT SELECT ON TABLE pg_catalog.pg_namespace TO backup;
GRANT SELECT ON TABLE pg_catalog.pg_extension TO backup;
GRANT EXECUTE ON FUNCTION bt_index_check(oid) TO backup;
GRANT EXECUTE ON FUNCTION bt_index_check(oid, bool) TO backup;

Настройка частичного восстановления

Если вы планируете производить частичное восстановление, выполните следующее дополнительное действие:

  • Дайте право на чтение pg_catalog.pg_database роли backup в той базе данных, через которую выполняется подключение к серверу Postgres Pro:

    GRANT SELECT ON TABLE pg_catalog.pg_database TO backup;

Настройка удалённого режима

Программа pg_probackup поддерживает удалённый режим, в котором резервное копирование, восстановление и архивирование WAL могут выполняться удалённо. В этом режиме каталог резервных копий находится в локальной системе, а целевой экземпляр Postgres Pro работает на удалённом компьютере. В настоящее время это поддерживается с использованием только одного сетевого протокола — SSH.

Настройте SSH

Если вы хотите использовать pg_probackup в удалённом режиме (применяя SSH), выполните следующие действия:

  • Установите pg_probackup в обеих системах: backup_host (сервер резервного копирования) и db_host (сервер баз данных).

  • Для организации связи между узлами настройте SSH-соединение без пароля для подключения пользователя backup на компьютере backup_host к серверу db_host под именем postgres:

    [backup@backup_host] ssh-copy-id postgres@db_host
  • Если вы будете использовать непрерывное архивирование WAL, настройте подключение по SSH пользователя backup в системе backup_host к системе db_host под именем пользователя postgres без указания пароля:

    [postgres@db_host] ssh-copy-id backup@backup_host

Здесь:

  • backup_host — система, в которой находится каталог копий.

  • db_host — система, в которой функционирует кластер Postgres Pro.

  • backup — пользователь в системе backup_host, от имени которого запускается pg_probackup.

  • postgres — пользователь в системе db_host, от имени которого запускается кластер Postgres Pro.

pg_probackup работает в удалённом режиме по протоколу SSH следующим образом:

  • В удалённом режиме поддерживаются только следующие команды: add-instance, backup, restore, archive-push и archive-get.

  • При запуске в удалённом режиме основной процесс pg_probackup в локальной системе подключается к удалённой по протоколу SSH и запускает в удалённой системе один или несколько агентов, которые называются удалёнными агентами. Количество удалённых агентов определяется значением параметра -j/--threads.

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

  • Удалённые агенты стараются минимизировать сетевой трафик и количество операций взаимодействия узлов.

  • Основной процесс обычно запускается в системе backup_host и подключается к системе db_host, но в случае команд archive-push и archive-get основной процесс запускается в системе db_host и подключается к backup_host.

  • После завершения передачи данных удалённые агенты завершаются и подключения SSH закрываются.

  • Если какой-либо удалённый агент столкнулся с ошибкой, все агенты завершаются, а основной процесс pg_probackup выдаёт информацию о возникшей ошибке и также нештатно завершается.

  • Сжатие данных всегда осуществляется в системе db_host, а распаковка — в системе backup_host.

Примечание

Вы можете задать дополнительные ограничительные параметры SSH для защиты целевой системы в случае компрометации используемой учётной записи.

Настройка копирования PTRACK

Режим копирования PTRACK можно использовать только с серверами Postgres Pro Standard и Postgres Pro Enterprise или с модифицированным PostgreSQL. Ссылки на модификации PTRACK для ванильного PostgreSQL находятся здесь.

Если вы хотите копировать данные в режиме PTRACK, выполните следующие дополнительные действия:

  • Установите для параметра ptrack_enable значение on.

  • Дайте права на выполнение функций PTRACK роли backup в каждой базе данных кластера:

    GRANT EXECUTE ON FUNCTION pg_catalog.pg_ptrack_clear() TO backup;
    GRANT EXECUTE ON FUNCTION pg_catalog.pg_ptrack_get_and_clear(oid, oid) TO backup;
  • Роль backup должна иметь доступ ко всем базам данных в кластере.

Использование

Создание резервной копии

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

pg_probackup backup -B каталог_копий --instance имя_экземпляра -b режим_копирования

Здесь режим_копирования может быть следующим:

  • FULL — создаётся полная резервная копия, содержащая все файлы данных кластера, необходимые для его восстановления.

  • DELTA — считываются все файлы данных в каталоге данных и создаётся инкрементальная копия для страниц, изменённых со времени предыдущего копирования.

  • PAGE — создаётся инкрементальная резервная копия с файлами WAL, записанными после предыдущей полной или инкрементальной копии. Из файлов данных при этом считываются только изменённые страницы.

  • PTRACK — создаётся инкрементальная резервная копия со страницами, изменения в которых отслеживались на лету.

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

Режим ARCHIVE

Режим ARCHIVE используется в качестве режима доставки WAL по умолчанию.

Например, чтобы сделать полную копию в режиме доставки WAL ARCHIVE, выполните:

pg_probackup backup -B каталог_копий --instance имя_экземпляра -b FULL

Резервное копирование ARCHIVE требует организации непрерывного архивирования, посредством которого считываются сегменты WAL, требующиеся для восстановления согласованного состояния кластера на момент создания копии.

В процессе резервного копирования pg_probackup помещает файлы WAL, содержащие записи от Start LSN до Stop LSN, в каталог каталог_копий/wal/имя_экземпляра. pg_probackup также проверяет, что записи WAL между Start LSN и Stop LSN корректно читаются. Это позволяет исключить риск хранения в архиве повреждённого WAL.

Режим STREAM

Режим STREAM может использоваться в качестве альтернативного режима доставки WAL.

Например, чтобы сделать полную резервную копию в потоковом режиме, добавьте флаг --stream к команде, показанной выше:

pg_probackup backup -B каталог_копий --instance имя_экземпляра -b FULL --stream --temp-slot

Необязательный параметр --temp-slot обеспечивает наличие необходимых сегментов в случае прокрутки WAL до завершения резервного копирования.

В отличие от копий ARCHIVE, копии типа STREAM включают все сегменты WAL, необходимые для восстановления согласованного состояния кластера на момент создания копии.

В процессе выполнения команды backup программа pg_probackup передаёт файлы WAL, содержащие записи от Start LSN до Stop LSN в каталог каталог_копий/backups/имя_экземпляра/ид_резервной_копии/database/pg_wal. Чтобы исключить риск архивирования испорченных файлов WAL, pg_probackup также проверяет, что записи WAL от Start LSN до Stop LSN прочитываются корректно.

Даже если вы используете непрерывное архивирование, копирование в режиме STREAM может быть полезно в следующих случаях:

  • Копии типа STREAM могут быть восстановлены на сервере, не имеющем файлового доступа к архиву WAL.

  • Копии типа STREAM позволяют восстановить состояние кластера на тот момент времени, для которого уже нет файлов WAL.

  • Копирование в режиме STREAM можно производить с ведомого сервера, не дожидаясь заполнения сегментов WAL, что могло бы занять длительное время при небольшом объёме трафика WAL.

Проверка страниц

Когда в кластере БД включены контрольные суммы, pg_probackup использует их для проверки целостности файлов данных в процессе резервного копирования. При чтении каждой страницы pg_probackup проверяет, совпадает ли вычисленная сумма с контрольной суммой, хранящейся в заголовке страницы. Это гарантирует, что в кластере Postgres Pro и самой резервной копии не содержатся испорченные страницы. Заметьте, что pg_probackup читает файлы данных непосредственно из файловой системы, поэтому при активной записи в момент копирования возможны ложные выявления некорректных контрольных сумм из-за частичной записи. В случае несовпадения контрольной суммы страница считывается повторно, и контрольная сумма проверяется ещё раз.

Страница признаётся испорченной, если проверка контрольной суммы не проходит более 100 раз. В этом случае резервное копирование прерывается.

Даже если контрольные суммы не включены, pg_probackup всегда проверяет целостность заголовков страниц.

Внешние каталоги

Чтобы заархивировать каталог, размещённый вне каталога данных, воспользуйтесь необязательным параметром --external-dirs, в котором можно задать путь к нужному каталогу. Если вы хотите заархивировать несколько внешних каталогов, их пути нужно разделить двоеточиями в Linux или точками с запятой в Windows.

Например, чтобы в системе Linux включить каталоги /etc/dir1 и /etc/dir2 в полную копию экземпляра имя_экземпляра, которая будет размещаться в каталоге_копий, выполните:

pg_probackup backup -B каталог_копий --instance имя_экземпляра -b FULL --external-dirs=/etc/dir1:/etc/dir2

Например, чтобы включить каталоги C:\dir1 и C:\dir2 в полную копию экземпляра instance_name, которая будет размещаться в каталоге backup_dir, в Windows нужно выполнить:

pg_probackup backup -B каталог_копий --instance имя_экземпляра -b FULL --external-dirs=C:\dir1;C:\dir2

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

Чтобы нужные каталоги включались в каждую резервную копию вашего кластера, их список можно сохранить в файле конфигурации pg_probackup.conf, воспользовавшись командой set-config с ключом --external-dirs.

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

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

pg_probackup checkdb [-B каталог_копий [--instance имя_экземпляра]] [-D каталог_данных] [параметры_подключения]

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

По умолчанию pg_probackup выполняет подобную проверку страницы автоматически в процессе создания копии. Команда checkdb позволяет при желании проводить проверки страниц в кластере, не создавая резервные копии (при этом даже необязательно настраивать копирование кластера в pg_probackup).

Чтобы провести проверку кластера, приложение pg_probackup должно подключиться к нему. Обычно для получения требуемых параметров подключения достаточно указать связанный с данным кластером копируемый экземпляр. Однако если параметры -B и --instance опускаются, параметры_соединения и каталог_данных необходимо задать в командной строке или в переменных окружения.

Важно понимать, что проверка на физическом уровне не позволяет выявить логические несоответствия, потерю или обнуление блоков или целых файлов и другие подобные аномалии. Провести логическую проверку в некотором объёме позволяют расширения amcheck и amcheck_next.

Если вы хотите помимо физической проверки проверить также все индексы во всех базах, используя эти расширения, вы можете передать команде checkdb флаг --amcheck:

pg_probackup checkdb -D каталог_данных --amcheck [параметры_соединения]

Проверку на физическом уровне можно отключить, воспользовавшись флагом --skip-block-validation. В этом случае задавать каталог_копий и каталог_данных не нужно, требуется задать только параметры подключения:

pg_probackup checkdb --amcheck --skip-block-validation [параметры_соединения]

Логическая проверка может быть более доскональной, если запустить её с ключом --heapallindexed. В этом случае будет дополнительно проверено, что в индексе действительно представлены все кортежи кучи, которые должны в него попасть, но это создаст дополнительную нагрузку на процессор, память и подсистему ввода/вывода.

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

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

Если вы хотите пропустить проверку резервной копии, вы можете передать командам backup и restore флаг --no-validate.

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

Например, чтобы убедиться, что вы можете восстановить кластер баз данных из резервной копии, остановившись на транзакции с идентификатором 4242, выполните команду:

pg_probackup validate -B каталог_копий --instance имя_экземпляра --recovery-target-xid=4242

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

Если вы укажете идентификатор копии в ключе -i/--backup-id, будет проверена только резервная копия с указанным идентификатором. Если идентификатор копии указывается вместе с параметрами точки восстановления, команда validate проверит, возможно ли восстановить указанную резервную копию до заданной точки.

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

pg_probackup validate -B каталог_копий --instance имя_экземпляра -i PT8XFX --recovery-target-time='2017-05-18 14:18:11+03'

Если вы укажете ид_резервной_копии, относящийся к инкрементальной копии, будут проверены все нужные ей родительские копии, начиная с полной.

Если вы опустите все параметры, будут проверены все резервные копии.

Восстановление кластера

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

pg_probackup restore -B каталог_копий --instance имя_экземпляра -i ид_резервной_копии

Здесь:

  • backup_dir — каталог, в котором хранятся все файлы резервных копий и метаданные.

  • имя_экземпляра — имя экземпляра резервной копии кластера, которая будет восстановлена.

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

Если кластер, подлежащий восстановлению, содержит табличные пространства, pg_probackup по умолчанию восстанавливает их в исходные расположения. Чтобы сменить расположения табличных пространств, воспользуйтесь параметром --tablespace-mapping/-T. В противном случае при восстановлении кластера на том же сервере произойдёт ошибка, если эти табличные пространства будут использоваться, так как восстанавливаемые данные нужно будет записать в те же каталоги.

Используя параметр --tablespace-mapping/-T, вы должны задать абсолютные пути к старому и новому каталогу табличного пространства. Если путь содержит знак равно (=), экранируйте его обратной косой чертой. Данный параметр может указываться неоднократно для перемещения нескольких табличных пространств. Например:

pg_probackup restore -B каталог_копий --instance имя_экземпляра -D каталог_данных -j 4 -i ид_резервной_копии -T каталог_табл_пространства1=новый_каталог_табл_пространства1 -T каталог_табл_пространства2=новый_каталог_табл_пространства2

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

Если восстанавливалась копия типа STREAM, восстановление завершается сразу, и кластер возвращается в согласованное состояние на момент времени, в который была сделана резервная копия. Для копий типа ARCHIVE Postgres Pro воспроизводит все имеющиеся в архиве сегменты WAL, в результате чего восстанавливается самое последнее состояние кластера. Это поведение можно изменить, определив параметры точки восстановления для команды restore. Заметьте, что использовать параметры точки восстановления при восстановлении копий типа STREAM возможно, если в архиве WAL находятся сегменты, захватывающие момент начала создания резервной копии.

Восстановление кластера на удалённом компьютере описано в подразделе Использование pg_probackup в удалённом режиме.

Примечание

По умолчанию команда restore проверяет указанную резервную копию перед восстановлением кластера. Если вы проводите проверку копий регулярно и хотели бы сэкономить время при восстановлении кластера, вы можете добавить ключ --no-validate для пропуска проверки и ускорения восстановления.

Частичное восстановление

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

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

pg_probackup restore -B каталог_копий --instance имя_экземпляра --db-include=имя_базы

Ключ --db-include может добавляться многократно. Например, чтобы восстановить только базы db1 и db2, выполните следующую команду:

pg_probackup restore -B каталог_копий --instance имя_экземпляра --db-include=db1 --db-include=db2

Чтобы исключить одну или несколько баз из числа восстанавливаемых, используйте ключ --db-exclude:

pg_probackup restore -B каталог_копий --instance имя_экземпляра --db-exclude=имя_базы

Ключ --db-exclude может добавляться многократно. Например, чтобы при восстановлении исключить базы данных db1 и db2, выполните следующую команду:

pg_probackup restore -B каталог_копий --instance имя_экземпляра -i ид_резервной_копии --db-exclude=db1 --db-exclude=db2

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

Примечание

Базы template0 и template1 восстанавливаются всегда.

Выполнение восстановления на момент времени (PITR)

Если вы настраивали непрерывное архивирование WAL до создания резервных копий, вы можете восстановить состояние кластера на любой момент времени (до заданной точки восстановления), используя с командами restore и validate параметры точки восстановления.

Если параметр -i/--backup-id не задан, pg_probackup автоматически выбирает резервную копию, ближайшую к заданной цели восстановления, и начинает процесс восстановления. В противном случае pg_probackup попытается восстановить до заданной цели восстановления именно копию с заданным ид_резервной_копии.

  • Чтобы восстановить состояние кластера на определённый момент времени, укажите это время в параметре --recovery-target-time, в формате timestamp. Например:

    pg_probackup restore -B каталог_копий --instance имя_экземпляра --recovery-target-time='2017-05-18 14:18:11+03'
  • Чтобы восстановить состояние кластера до определённой транзакции, воспользуйтесь ключом --recovery-target-xid:

    pg_probackup restore -B каталог_копий --instance имя_экземпляра --recovery-target-xid=687
  • Чтобы восстановить состояние кластера до определённой позиции в журнале (LSN), воспользуйтесь ключом --recovery-target-lsn:

    pg_probackup restore -B каталог_копий --instance имя_экземпляра --recovery-target-lsn=16/B374D848
  • Чтобы восстановить состояние кластера до заданной именованной точки восстановления, воспользуйтесь ключом --recovery-target-name:

    pg_probackup restore -B каталог_копий --instance имя_экземпляра --recovery-target-name='before_app_upgrade'
  • Чтобы восстановить последнее возможное состояние, исходя из содержимого архива WAL, передайте в параметре --recovery-target значение latest:

    pg_probackup restore -B каталог_копий --instance имя_экземпляра --recovery-target='latest'
  • Чтобы восстановить самое раннее из возможных согласованное состояние кластера, передайте в параметре --recovery-target значение immediate:

    pg_probackup restore -B каталог_копий --instance имя_экземпляра --recovery-target='immediate'

Использование pg_probackup в удалённом режиме

Программа pg_probackup поддерживает работу в удалённом режиме, то есть может выполнять операции backup и restore удалённо, используя SSH. В этом режиме каталог резервных копий располагается в локальной системе, а целевой экземпляр Postgres Pro работает в удалённой. При этом pg_probackup должен быть установлен в обеих системах.

Примечание

pg_probackup рассчитывает на то, что узлы будут взаимодействовать между собой с использованием SSH без пароля.

Типичная схема его использования выглядит так:

Например, чтобы создать полную архивную копию кластера Postgres Pro, работающего в удалённой системе с адресом 192.168.0.2, подключившись к серверу по SSH через порт 2302 с именем пользователя postgres, выполните:

pg_probackup backup -B каталог_копий --instance имя_экземпляра -b FULL --remote-user=postgres --remote-host=192.168.0.2 --remote-port=2302

Чтобы восстановить последнюю имеющуюся копию в удалённой системе с адресом 192.168.0.2, подключившись к серверу по SSH через порт 2302 с именем пользователя postgres, выполните:

pg_probackup restore -B каталог_копий --instance имя_экземпляра --remote-user=postgres --remote-host=192.168.0.2 --remote-port=2302

Для восстановления архивных копий или восстановления на момент времени в удалённом режиме требуется дополнительная информация: целевой адрес, порт и имя пользователя для установления SSH-подключения c сервера БД к системе, где находится каталог копий. Эту информацию будет использовать команда restore_command для копирования сегментов WAL из архива в каталог Postgres Pro pg_wal.

Для передачи этой информации вы можете задать параметры удалённого архива WAL.

Например, для восстановления последней копии в удалённой системе, настроенной для приёма подключения пользователя postgres по адресу 192.168.0.2 через порт 2302, с использованием каталога резервных копий в системе, настроенной для подключения пользователя backup по адресу 192.168.0.3 через порт 2303, выполните:

pg_probackup restore -B каталог_копий --instance имя_экземпляра --remote-user=postgres --remote-host=192.168.0.2 --remote-port=2302 --archive-host=192.168.0.3 --archive-port=2303 --archive-user=backup

Переданные аргументы будут использоваться при составлении команды restore_command в recovery.conf:

restore_command = 'путь_инсталляции/pg_probackup archive-get -B каталог_копий --instance имя_экземпляра --wal-file-path=%p --wal-file-name=%f --remote-host=192.168.0.3 --remote-port=2303 --remote-user=backup'

Также вы можете воспользоваться ключом --restore-command и передать всю команду restore_command целиком:

pg_probackup restore -B каталог_копий --instance имя_экземпляра --remote-user=postgres --remote-host=192.168.0.2 --remote-port=2302 --restore-command='путь_инсталляции/pg_probackup archive-get -B каталог_копий --instance имя_экземпляра --wal-file-path=%p --wal-file-name=%f --remote-host=192.168.0.3 --remote-port=2303 --remote-user=backup'

Примечание

Использование удалённого режима на платформе Windows в настоящее время не поддерживается.

Запуск pg_probackup в параллельных потоках

Команды backup, restore, merge, delete, checkdb и validate могут выполняться в несколько параллельных потоков. Это может существенно ускорять работу pg_probackup при наличии достаточных ресурсов (ядер процессора, производительности дисковой подсистемы и сети).

Параллельным выполнением управляет ключ командной строки -j/--threads. Например, чтобы запустить резервное копирование в четыре параллельных потока, выполните:

pg_probackup backup -B каталог_копий --instance имя_экземпляра -b FULL -j 4

Примечание

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

Настройка pg_probackup

Проинициализировав каталог резервных копий и добавив определение копируемого экземпляра, вы можете использовать файл pg_probackup.conf в каталоге каталог_копий/backups/имя_экземпляра для тонкой настройки конфигурации pg_probackup.

Например, команды backup и checkdb работают через обычное подключение Postgres Pro. Чтобы каждый раз не задавать параметры подключения в командной строке, вы можете определить их в файле конфигурации pg_probackup.conf с помощью команды set-config.

Примечание

Редактировать pg_probackup.conf вручную не рекомендуется.

Изначально pg_probackup.conf содержит следующие параметры:

  • PGDATA — путь к каталогу данных кластера, который будет копироваться.

  • system-identifier — уникальный идентификатор экземпляра Postgres Pro.

Вы можете дополнительно установить параметры удалённого режима, хранения копий, ведения журнала и сжатия, используя команду set-config:

pg_probackup set-config -B каталог_копий --instance имя_экземпляра
[--external-dirs=путь_внешнего_каталога] [параметры_удалённого_режима] [параметры_соединения] [параметры_хранения] [параметры_журнала]

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

pg_probackup show-config -B каталог_копий --instance имя_экземпляра

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

Указание параметров подключения

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

Если не задано ничего, используются значения по умолчанию. В частности, pg_probackup пытается подключиться к Unix-сокету локального сервера (или к localhost в Windows), а в качестве имени базы данных и имени пользователя выбирает значение переменной окружения PGUSER либо имя текущего пользователя ОС.

Управление каталогом резервных копий

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

Просмотр информации о резервных копиях

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

pg_probackup show -B каталог_копий

pg_probackup выводит список всех имеющихся резервных копий. Например:

BACKUP INSTANCE 'node'
======================================================================================================================================
 Instance  Version  ID      Recovery time           Mode    WAL Mode  TLI  Time    Data   WAL  Zratio  Start LSN   Stop LSN    Status
======================================================================================================================================
 node      10       PYSUE8  2019-10-03 15:51:48+03  FULL    ARCHIVE   1/0   16s  9047kB  16MB    4.31  0/12000028  0/12000160  OK
 node      10       P7XDQV  2018-04-29 05:32:59+03  DELTA   STREAM    1/1   11s    19MB  16MB    1.00  0/15000060  0/15000198  OK
 node      10       P7XDJA  2018-04-29 05:28:36+03  PTRACK  STREAM    1/1   21s    32MB  32MB    1.00  0/13000028  0/13000198  OK
 node      10       P7XDHU  2018-04-29 05:27:59+03  PAGE    STREAM    1/1   15s    33MB  16MB    1.00  0/11000028  0/110001D0  OK
 node      10       P7XDHB  2018-04-29 05:27:15+03  FULL    STREAM    1/0   11s    39MB  16MB    1.00  0/F000028   0/F000198   OK

Для каждой копии выдаются следующие сведения:

  • Instance — имя экземпляра.

  • Version — базовая версия Postgres Pro.

  • ID — идентификатор резервной копии.

  • Recovery time — самое ранее время, на которое можно восстановить кластер из данной копии.

  • Mode — режим, в котором была сделана копия. Возможные значения: FULL (полная), PAGE (страничная), DELTA (инкрементальная), PTRACK (копирование изменений).

  • WAL Mode — режим доставки WAL. Возможные значения: STREAM (потоковый) и ARCHIVE (архивный).

  • TLI — идентификаторы линии времени текущей копии и её родителя.

  • Time — время, за которое была выполнена данная копия.

  • Data — объём файлов данных в этой копии. Это значение не включает в себя объём файлов WAL. Для копий, сделанных в режиме STREAM, общий размер можно рассчитать, сложив значения Data и WAL.

  • WAL — размер несжатых файлов WAL, которые должны быть применены в процессе восстановления копии для достижения согласованного состояния.

  • Zratio — коэффициент сжатия, вычисленный как отношение «uncompressed-bytes» (объём несжатых данных в байтах) к «data-bytes» (итоговый объём данных).

  • Start LSN — последовательный номер в журнале WAL, соответствующий началу процесса копирования. С этой позиции накатываются изменения (REDO) в процессе восстановления Postgres Pro.

  • Stop LSN — последовательный номер в журнале WAL, соответствующий окончанию процесса копирования. Это позиция точки согласованности при восстановлении Postgres Pro.

  • Status — состояние резервной копии. Возможные варианты:

    • OK — резервная копия сделана и пригодна к использованию.

    • DONE — резервная копия сделана, но не проверена.

    • RUNNING — резервное копирование выполняется.

    • MERGING — резервная копия объединяется.

    • DELETING — файлы резервной копии удаляются.

    • CORRUPT — некоторые файлы резервной копии повреждены.

    • ERROR — резервное копирование было прервано из-за неожиданной ошибки.

    • ORPHAN — резервная копия непригодна к использованию, так как её родительская копия испорчена или отсутствует.

Восстановить кластер из копии можно только для копий с состоянием OK или DONE.

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

pg_probackup show -B каталог_копий --instance имя_экземпляра -i ид_резервной_копии

Пример вывода:

#Configuration
backup-mode = FULL
stream = false
compress-alg = zlib
compress-level = 1
from-replica = false

#Compatibility
block-size = 8192
wal-block-size = 8192
checksum-version = 1
program-version = 2.1.3
server-version = 10

#Result backup info
timelineid = 1
start-lsn = 0/04000028
stop-lsn = 0/040000f8
start-time = '2017-05-16 12:57:29'
end-time = '2017-05-16 12:57:31'
recovery-xid = 597
recovery-time = '2017-05-16 12:57:31'
expire-time = '2020-05-16 12:57:31'
data-bytes = 22288792
wal-bytes = 16777216
uncompressed-bytes = 39961833
pgdata-bytes = 39859393
status = OK
parent-backup-id = 'PT8XFX'
primary_conninfo = 'user=backup passfile=/var/lib/pgsql/.pgpass port=5432 sslmode=disable sslcompression=1 target_session_attrs=any'

В расширенном выводе представлены дополнительные атрибуты:

  • compress-alg — алгоритм сжатия, используемый при получении резервной копии. Возможные значения: zlib, pglz и none (сжатие не производилось).

  • compress-level — уровень сжатия, применяемый в процессе резервного копирования.

  • from-replica — признак того, что копия была сделана с ведомого сервера. Возможные значения: 1, 0.

  • block-size — значение параметра block_size, установленное в кластере Postgres Pro, с которого была сделана копия.

  • checksum-version — признак включения параметра data_checksums в исходном кластере Postgres Pro. Возможные значения: 1, 0.

  • program-version — полная версия программы pg_probackup, которая создала эту копию.

  • start-time — время начала резервного копирования.

  • end-time — время окончания резервного копирования.

  • expire-time — время, когда закреплённая копия может быть ликвидирована при удалении неактуальных копий.

  • uncompressed-bytes — размер файлов данных до добавления заголовков страниц и сжатия. В случае использования сжатия оценить его эффективность можно, сопоставив объём uncompressed-bytes (байтов несжатых данных) с data-bytes (байтов данных).

  • pgdata-bytes — размер файлов данных Postgres Pro на момент копирования. Эффективность инкрементального метода копирования можно оценить, сопоставив объём pgdata-bytes (байтов в PGDATA) с uncompressed-bytes (байтов несжатых данных).

  • recovery-xid — идентификатор транзакции, соответствующей моменту окончания резервного копирования.

  • parent-backup-id — идентификатор родительской копии. Определён только для инкрементальных копий.

  • primary_conninfo — параметры подключения libpq, с использованием которых производилось подключение к кластеру Postgres Pro для получения этой резервной копии. Пароль в эти параметры не включается.

Вы также можете получить подробную информацию о резервной копии в формате JSON:

pg_probackup show -B каталог_копий --instance имя_экземпляра --format=json -i backup_id

Пример вывода:

[
  {
      "instance": "node",
      "backups": [
          {
              "id": "PT91HZ",
              "parent-backup-id": "PT8XFX",
              "backup-mode": "DELTA",
              "wal": "ARCHIVE",
              "compress-alg": "zlib",
              "compress-level": 1,
              "from-replica": false,
              "block-size": 8192,
              "xlog-block-size": 8192,
              "checksum-version": 1,
              "program-version": "2.1.3",
              "server-version": "10",
              "current-tli": 16,
              "parent-tli": 2,
              "start-lsn": "0/8000028",
              "stop-lsn": "0/8000160",
              "start-time": "2019-06-17 18:25:11+03",
              "end-time": "2019-06-17 18:25:16+03",
              "recovery-xid": 0,
              "recovery-time": "2019-06-17 18:25:15+03",
              "data-bytes": 106733,
              "wal-bytes": 16777216,
              "primary_conninfo": "user=backup passfile=/var/lib/pgsql/.pgpass port=5432 sslmode=disable sslcompression=1 target_session_attrs=any",
              "status": "OK"
          }
      ]
  }
]

Просмотр оглавления архива WAL

Чтобы получить информацию об архиве WAL для каждого экземпляра, выполните команду:

pg_probackup show -B каталог_копий [--instance имя_экземпляра] --archive

pg_probackup выводит список всех имеющихся файлов WAL, сгруппированных по линиям времени. Например:

ARCHIVE INSTANCE 'node'
===================================================================================================================
 TLI  Parent TLI  Switchpoint  Min Segno         Max Segno         N segments  Size    Zratio  N backups  Status
===================================================================================================================
 5    1           0/B000000    000000000000000B  000000000000000C  2           685kB   48.00   0          OK
 4    3           0/18000000   0000000000000018  000000000000001A  3           648kB   77.00   0          OK
 3    2           0/15000000   0000000000000015  0000000000000017  3           648kB   77.00   0          OK
 2    1           0/B000108    000000000000000B  0000000000000015  5           892kB   94.00   1          DEGRADED
 1    0           0/0          0000000000000001  000000000000000A  10          8774kB  19.00   1          OK

Для каждой линии времени выдаются следующие сведения:

  • TLI — идентификатор линии времени.

  • Parent TLI — идентификатор линии времени, от которой была ответвлена данная.

  • Switchpoint — LSN момента, когда эта линия времени ответвилась от родительской.

  • Min Segno — первый сегмент WAL, относящийся к этой линии времени.

  • Max Segno — последний сегмент WAL, относящийся к этой линии времени.

  • N segments — количество сегментов WAL, относящихся к этой линии времени.

  • Size — объём, который занимают файлы на диске.

  • Zratio — коэффициент сжатия, вычисляемый по формуле N segments * wal_segment_size * wal_block_size / Size.

  • N backups — число копий, относящихся к этой линии времени. Для получения подробных сведений об этих копиях воспользуйтесь форматом JSON.

  • Status — состояние архива WAL для этой линии времени. Возможные значения:

    • OK — в архиве присутствуют все сегменты WAL между Min Segno и Max Segno.

    • DEGRADED — некоторые сегменты WAL в интервале между Min Segno и Max Segno отсутствуют. Понять, какие именно, можно, получив отчёт в формате JSON.

Чтобы получить более подробную информацию об архиве WAL в формате JSON, выполните команду:

pg_probackup show -B каталог_копий [--instance имя_экземпляра] --archive --format=json

Пример вывода:

[
  {
      "instance": "replica",
      "timelines": [
          {
              "tli": 5,
              "parent-tli": 1,
              "switchpoint": "0/B000000",
              "min-segno": "000000000000000B",
              "max-segno": "000000000000000C",
              "n-segments": 2,
              "size": 685320,
              "zratio": 48.00,
              "closest-backup-id": "PXS92O",
              "status": "OK",
              "lost-segments": [],
              "backups": []
          },
          {
              "tli": 4,
              "parent-tli": 3,
              "switchpoint": "0/18000000",
              "min-segno": "0000000000000018",
              "max-segno": "000000000000001A",
              "n-segments": 3,
              "size": 648625,
              "zratio": 77.00,
              "closest-backup-id": "PXS9CE",
              "status": "OK",
              "lost-segments": [],
              "backups": []
          },
          {
              "tli": 3,
              "parent-tli": 2,
              "switchpoint": "0/15000000",
              "min-segno": "0000000000000015",
              "max-segno": "0000000000000017",
              "n-segments": 3,
              "size": 648911,
              "zratio": 77.00,
              "closest-backup-id": "PXS9CE",
              "status": "OK",
              "lost-segments": [],
              "backups": []
          },
          {
              "tli": 2,
              "parent-tli": 1,
              "switchpoint": "0/B000108",
              "min-segno": "000000000000000B",
              "max-segno": "0000000000000015",
              "n-segments": 5,
              "size": 892173,
              "zratio": 94.00,
              "closest-backup-id": "PXS92O",
              "status": "DEGRADED",
              "lost-segments": [
                  {
                      "begin-segno": "000000000000000D",
                      "end-segno": "000000000000000E"
                  },
                  {
                      "begin-segno": "0000000000000010",
                      "end-segno": "0000000000000012"
                  }
              ],
              "backups": [
                  {
                      "id": "PXS9CE",
                      "backup-mode": "FULL",
                      "wal": "ARCHIVE",
                      "compress-alg": "none",
                      "compress-level": 1,
                      "from-replica": "false",
                      "block-size": 8192,
                      "xlog-block-size": 8192,
                      "checksum-version": 1,
                      "program-version": "2.1.5",
                      "server-version": "10",
                      "current-tli": 2,
                      "parent-tli": 0,
                      "start-lsn": "0/C000028",
                      "stop-lsn": "0/C000160",
                      "start-time": "2019-09-13 21:43:26+03",
                      "end-time": "2019-09-13 21:43:30+03",
                      "recovery-xid": 0,
                      "recovery-time": "2019-09-13 21:43:29+03",
                      "data-bytes": 104674852,
                      "wal-bytes": 16777216,
                      "primary_conninfo": "user=backup passfile=/var/lib/pgsql/.pgpass port=5432 sslmode=disable sslcompression=1 target_session_attrs=any",
                      "status": "OK"
                  }
              ]
          },
          {
              "tli": 1,
              "parent-tli": 0,
              "switchpoint": "0/0",
              "min-segno": "0000000000000001",
              "max-segno": "000000000000000A",
              "n-segments": 10,
              "size": 8774805,
              "zratio": 19.00,
              "closest-backup-id": "",
              "status": "OK",
              "lost-segments": [],
              "backups": [
                  {
                      "id": "PXS92O",
                      "backup-mode": "FULL",
                      "wal": "ARCHIVE",
                      "compress-alg": "none",
                      "compress-level": 1,
                      "from-replica": "true",
                      "block-size": 8192,
                      "xlog-block-size": 8192,
                      "checksum-version": 1,
                      "program-version": "2.1.5",
                      "server-version": "10",
                      "current-tli": 1,
                      "parent-tli": 0,
                      "start-lsn": "0/4000028",
                      "stop-lsn": "0/6000028",
                      "start-time": "2019-09-13 21:37:36+03",
                      "end-time": "2019-09-13 21:38:45+03",
                      "recovery-xid": 0,
                      "recovery-time": "2019-09-13 21:37:30+03",
                      "data-bytes": 25987319,
                      "wal-bytes": 50331648,
                      "primary_conninfo": "user=backup passfile=/var/lib/pgsql/.pgpass port=5432 sslmode=disable sslcompression=1 target_session_attrs=any",
                      "status": "OK"
                  }
              ]
          }
      ]
  },
  {
      "instance": "master",
      "timelines": [
          {
              "tli": 1,
              "parent-tli": 0,
              "switchpoint": "0/0",
              "min-segno": "0000000000000001",
              "max-segno": "000000000000000B",
              "n-segments": 11,
              "size": 8860892,
              "zratio": 20.00,
              "status": "OK",
              "lost-segments": [],
              "backups": [
                  {
                      "id": "PXS92H",
                      "parent-backup-id": "PXS92C",
                      "backup-mode": "PAGE",
                      "wal": "ARCHIVE",
                      "compress-alg": "none",
                      "compress-level": 1,
                      "from-replica": "false",
                      "block-size": 8192,
                      "xlog-block-size": 8192,
                      "checksum-version": 1,
                      "program-version": "2.1.5",
                      "server-version": "10",
                      "current-tli": 1,
                      "parent-tli": 1,
                      "start-lsn": "0/4000028",
                      "stop-lsn": "0/50000B8",
                      "start-time": "2019-09-13 21:37:29+03",
                      "end-time": "2019-09-13 21:37:31+03",
                      "recovery-xid": 0,
                      "recovery-time": "2019-09-13 21:37:30+03",
                      "data-bytes": 1328461,
                      "wal-bytes": 33554432,
                      "primary_conninfo": "user=backup passfile=/var/lib/pgsql/.pgpass port=5432 sslmode=disable sslcompression=1 target_session_attrs=any",
                      "status": "OK"
                  },
                  {
                      "id": "PXS92C",
                      "backup-mode": "FULL",
                      "wal": "ARCHIVE",
                      "compress-alg": "none",
                      "compress-level": 1,
                      "from-replica": "false",
                      "block-size": 8192,
                      "xlog-block-size": 8192,
                      "checksum-version": 1,
                      "program-version": "2.1.5",
                      "server-version": "10",
                      "current-tli": 1,
                      "parent-tli": 0,
                      "start-lsn": "0/2000028",
                      "stop-lsn": "0/2000160",
                      "start-time": "2019-09-13 21:37:24+03",
                      "end-time": "2019-09-13 21:37:29+03",
                      "recovery-xid": 0,
                      "recovery-time": "2019-09-13 21:37:28+03",
                      "data-bytes": 24871902,
                      "wal-bytes": 16777216,
                      "primary_conninfo": "user=backup passfile=/var/lib/pgsql/.pgpass port=5432 sslmode=disable sslcompression=1 target_session_attrs=any",
                      "status": "OK"
                  }
              ]
          }
      ]
  }
]

В основном в этом формате представлены те же поля, что и в текстовом формате, с некоторыми исключениями:

  • Размер выражается в байтах.

  • Атрибут closest-backup-id содержит идентификатор самой последней доступной копии, принадлежащей к одной из предыдущих линий времени. Вы можете использовать эту копию для восстановления на момент, относящийся к этой линии времени. Если такой копии не существует, данный атрибут будет пустым.

  • В массиве lost-segments представлены интервалы отсутствующих сегментов на линиях времени в непригодном состоянии (DEGRADED). На линиях времени в целостном состоянии OK массив lost-segments пуст.

  • В массиве backups перечисляются все резервные копии, относящиеся к данной линии времени. Если к линии времени не относятся резервные копии, этот массив пуст.

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

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

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

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

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

--retention-redundancy=избыточность

Определяет количество полных резервных копий, которое должно сохраняться в каталоге копий.

--retention-window=окно

Определяет самый ранний момент времени, на который pg_probackup может выполнить восстановление. В этом параметре задаётся количество дней от текущего момента. Например, если retention-window=7, pg_probackup может удалить все резервные копии старее семи дней, вместе с соответствующими файлами WAL.

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

pg_probackup set-config -B каталог_копий --instance имя_экземпляра --retention-redundancy=2 --retention-window=7

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

pg_probackup delete -B каталог_копий --instance имя_экземпляра --delete-expired

pg_probackup удалит все резервные копии, не удовлетворяющие установленной политике сохранения.

Если вы хотите также удалить файлы WAL, которые больше не требуются ни для каких копий, добавьте ключ --delete-wal:

pg_probackup delete -B каталог_копий --instance имя_экземпляра --delete-expired --delete-wal

Примечание

Вы также можете удалить или объединить старые резервные копии после создания новой, передав флаги --delete-expired, --merge-expired и аргументы --delete-wal, --retention-window и --retention-redundancy с командой backup.

Вы можете установить или переопределить текущую политику хранения, добавив параметры --retention-redundancy и --retention-window непосредственно при выполнении команд delete или backup:

pg_probackup delete -B каталог_копий --instance имя_экземпляра --delete-expired --retention-window=7 --retention-redundancy=2

Так как для инкрементальных копий требуется наличие всех родительских полных копий и всех предыдущих инкрементальных копий, даже по истечении срока их хранения эти копии нельзя удалить, пока минимум одна инкрементальная копия в цепочке удовлетворяет политике хранения. Чтобы не хранить устаревшие копии, которые всё ещё нужны для восстановления нужной инкрементальной копии, вы можете объединить их с ней, воспользовавшись ключом --merge-expired команды backup или delete.

Предположим, что вы заархивировали экземпляр node в каталог_копий со значением параметра --retention-window, равным 7, и на 10 апреля 2019 г. у вас есть следующие копии:

BACKUP INSTANCE 'node'
===================================================================================================================================
 Instance  Version  ID      Recovery time           Mode   WAL     TLI  Time    Data   WAL  Zratio  Start LSN   Stop LSN    Status
===================================================================================================================================
 node      10       P7XDHR  2019-04-10 05:27:15+03  FULL   STREAM  1/0   11s   200MB  16MB     1.0  0/18000059  0/18000197  OK
 node      10       P7XDQV  2019-04-08 05:32:59+03  PAGE   STREAM  1/0   11s    19MB  16MB     1.0  0/15000060  0/15000198  OK
 node      10       P7XDJA  2019-04-03 05:28:36+03  DELTA  STREAM  1/0   21s    32MB  16MB     1.0  0/13000028  0/13000198  OK
 -------------------------------------------------------retention window--------------------------------------------------------
 node      10       P7XDHU  2019-04-02 05:27:59+03  PAGE   STREAM  1/0   31s    33MB  16MB     1.0  0/11000028  0/110001D0  OK
 node      10       P7XDHB  2019-04-01 05:27:15+03  FULL   STREAM  1/0   11s   200MB  16MB     1.0  0/F000028   0/F000198   OK
 node      10       P7XDFT  2019-03-29 05:26:25+03  FULL   STREAM  1/0   11s   200MB  16MB     1.0  0/D000028   0/D000198   OK

Несмотря на то, что копии P7XDHB и P7XDHU выходят за рамки окна хранения, их нельзя удалить, так как от них зависят последующие инкрементальные копии P7XDJA и P7XDQV, которые всё ещё нужны. Поэтому, если вы выполните команду delete с ключом --delete-expired, будет удалена только полная копия P7XDFT.

С ключом --merge-expired резервная копия P7XDJA объединяется с нижележащими P7XDHU и P7XDHB и становится полной, поэтому хранить две предыдущие просроченные копии больше не нужно:

pg_probackup delete -B каталог_копий --instance node --delete-expired --merge-expired
pg_probackup show -B каталог_копий
BACKUP INSTANCE 'node'
==================================================================================================================================
 Instance  Version  ID      Recovery time           Mode  WAL     TLI  Time    Data   WAL  Zratio  Start LSN   Stop LSN    Status
==================================================================================================================================
 node      10       P7XDHR  2019-04-10 05:27:15+03  FULL  STREAM  1/0   11s   200MB  16MB     1.0  0/18000059  0/18000197  OK
 node      10       P7XDQV  2019-04-08 05:32:59+03  PAGE  STREAM  1/0   11s    19MB  16MB     1.0  0/15000060  0/15000198  OK
 node      10       P7XDJA  2019-04-03 05:28:36+03  FULL  STREAM  1/0   21s    32MB  16MB     1.0  0/13000028  0/13000198  OK

Поле Time (Время) для объединённой копии показывает время, которое заняла процедура объединения.

Закрепление копий

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

pg_probackup set-backup -B каталог_копий --instance имя_экземпляра -i ид_резервной_копии --ttl=30d

Эта команда задаёт срок хранения заданной резервной копии 30 дней, начиная с момента, указанного в атрибуте recovery-time этой копии.

Вы также можете явно задать время истечения срока хранения копии, воспользовавшись ключом --expire-time. Например:

pg_probackup set-backup -B каталог_копий --instance имя_экземпляра -i ид_резервной_копии --expire-time='2020-01-01 00:00:00+03'

Также можно воспользоваться ключами --ttl и --expire-time команды backup и сразу закрепить создаваемую копию:

pg_probackup backup -B каталог_копий --instance имя_экземпляра -b FULL --ttl=30d
pg_probackup backup -B каталог_копий --instance имя_экземпляра -b FULL --expire-time='2020-01-01 00:00:00+03'

Определить, закреплена ли копия, можно с помощью команды show:

pg_probackup show -B каталог_копий --instance имя_экземпляра -i ид_резервной_копии

Если копия закреплена, атрибут expire-time содержит время окончания срока её хранения:

...
recovery-time = '2017-05-16 12:57:31'
expire-time = '2020-01-01 00:00:00+03'
data-bytes = 22288792
...

Атрибут expire-time присутствует только в метаданных закреплённых резервных копий.

Примечание

Для закреплённой инкрементальной копии неявным образом закрепляются все нужные ей родительские копии.

Отменить закрепление копии можно, передав нулевой аргумент --ttl команде set-backup. Например:

pg_probackup set-backup -B каталог_копий --instance имя_экземпляра -i ид_резервной_копии --ttl=0

Политика хранения архива WAL

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

Предположим, что вы заархивировали экземпляр node в каталог_копий и настроили непрерывное архивирование WAL:

pg_probackup show -B каталог_копий --instance node
BACKUP INSTANCE 'node'
====================================================================================================================================
 Instance  Version  ID      Recovery Time           Mode   WAL Mode  TLI  Time   Data   WAL  Zratio  Start LSN   Stop LSN    Status
====================================================================================================================================
 node      11       PZ9442  2019-10-12 10:43:21+03  DELTA  STREAM    1/0   10s  121kB  16MB    1.00  0/46000028  0/46000160  OK
 node      11       PZ943L  2019-10-12 10:43:04+03  FULL   STREAM    1/0   10s  180MB  32MB    1.00  0/44000028  0/44000160  OK
 node      11       PZ7YR5  2019-10-11 19:49:56+03  DELTA  STREAM    1/1   10s  112kB  32MB    1.00  0/41000028  0/41000160  OK
 node      11       PZ7YMP  2019-10-11 19:47:16+03  DELTA  STREAM    1/1   10s  376kB  32MB    1.00  0/3E000028  0/3F0000B8  OK
 node      11       PZ7YK2  2019-10-11 19:45:45+03  FULL   STREAM    1/0   11s  180MB  16MB    1.00  0/3C000028  0/3C000198  OK
 node      11       PZ7YFO  2019-10-11 19:43:04+03  FULL   STREAM    1/0   10s   30MB  16MB    1.00  0/2000028   0/200ADD8   OK

Вы можете проверить состояние архива WAL, запустив команду show с ключом --archive:

pg_probackup show -B каталог_копий --instance node --archive
ARCHIVE INSTANCE 'node'
===============================================================================================================
 TLI  Parent TLI  Switchpoint  Min Segno         Max Segno         N segments  Size  Zratio  N backups  Status
===============================================================================================================
 1    0           0/0          0000000000000001  0000000000000047  71          36MB  31.00   6          OK

Операция очистки WAL без ключа --wal-depth может удалить лишь один сегмент:

pg_probackup delete -B каталог_копий --instance node --delete-wal
ARCHIVE INSTANCE 'node'
===============================================================================================================
 TLI  Parent TLI  Switchpoint  Min Segno         Max Segno         N segments  Size  Zratio  N backups  Status
===============================================================================================================
 1    0           0/0          0000000000000002  0000000000000047  70          34MB  32.00   6          OK

Например, если вы хотите оставить только те сегменты, которые могут применяться к последней копии, воспользуйтесь параметром --wal-depth:

pg_probackup delete -B каталог_копий --instance node --delete-wal --wal-depth=1
ARCHIVE INSTANCE 'node'
================================================================================================================
 TLI  Parent TLI  Switchpoint  Min Segno         Max Segno         N segments  Size   Zratio  N backups  Status
================================================================================================================
 1    0           0/0          0000000000000046  0000000000000047  2           143kB  228.00  6          OK

Также вы можете использовать параметр --wal-depth с командой backup:

pg_probackup backup -B каталог_данных --instance node -b DELTA --wal-depth=1 --delete-wal
ARCHIVE INSTANCE 'node'
===============================================================================================================
 TLI  Parent TLI  Switchpoint  Min Segno         Max Segno         N segments  Size  Zratio  N backups  Status
===============================================================================================================
 1    0           0/0          0000000000000048  0000000000000049  1           72kB  228.00  7          OK

Объединение резервных копий

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

pg_probackup merge -B каталог_копий --instance имя_экземпляра -i ид_резервной_копии

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

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

pg_probackup show -B каталог_копий --instance имя_экземпляра -i ид_резервной_копии

Если процесс объединения ещё не закончен, вы увидите состояние MERGING. В случае прерывания операции объединения она может быть перезапущена.

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

Для удаления резервной копии, ставшей ненужной, выполните команду:

pg_probackup delete -B каталог_копий --instance имя_экземпляра -i ид_резервной_копии

Эта команда удалит резервную копию с заданным ид_резервной_копии вместе со всеми инкрементальными копиями, которые от неё зависят (если таковые найдутся). Таким образом вы можете удалить некоторые последние инкрементальные копии, сохранив предыдущую полную копию и некоторые следующие за ней инкрементальные копии.

Для удаления старых файлов WAL, которые не нужны для восстановления никаких из оставшихся резервных копий, воспользуйтесь ключом --delete-wal:

pg_probackup delete -B каталог_копий --instance имя_экземпляра --delete-wal

Чтобы удалить резервные копии, считающиеся ненужными согласно текущей политике хранения, воспользуйтесь ключом --delete-expired:

pg_probackup delete -B каталог_копий --instance имя_экземпляра --delete-expired

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

pg_probackup delete -B каталог_копий --instance имя_экземпляра --delete-expired --merge-expired

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

Прежде чем объединять или удалять резервные копии, вы можете выполнить команду delete с параметром --dry-run и получить в результате состояние всех имеющихся копий в соответствии с текущей политикой хранения; никакие необратимые действия при этом выполняться не будут.

Справка по командной строке

Команды

В этом подразделе описываются команды pg_probackup. Необязательные параметры этих команд заключаются в квадратные скобки. В подробностях все параметры описываются в подразделе Параметры.

version

pg_probackup version

Выводит версию pg_probackup.

help

pg_probackup help [команда]

Выдаёт справку по командам pg_probackup. Если в параметрах задаётся одна из команд pg_probackup, выводит подробную информацию по параметрам, которые принимает эта команда.

init

pg_probackup init -B каталог_копий [--help]

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

За подробностями обратитесь к подразделу Инициализация каталога копий.

add-instance

pg_probackup add-instance -B каталог_копий -D каталог_данных --instance имя_экземпляра [--help]

Инициализирует новый копируемый экземпляр в каталоге каталог_копий и создаёт файл конфигурации pg_probackup.conf, управляющий параметрами pg_probackup, относящимися к кластеру в указанном каталоге_данных.

За подробностями обратитесь к подразделу Определение копируемого экземпляра.

del-instance

pg_probackup del-instance -B каталог_копий --instance имя_экземпляра [--help]

Удаляет все резервные копии и файлы WAL, связанные с указанным экземпляром.

set-config

pg_probackup set-config -B каталог_копий --instance имя_экземпляра
[--help] [--pgdata=путь_к_pgdata]
[--retention-redundancy=избыточность][--retention-window=окно][--wal-depth=глубина_wal]
[--compress-algorithm=алгоритм_сжатия] [--compress-level=уровень_сжатия]
[-d имя_базы] [-h сервер] [-p порт] [-U имя_пользователя]
[--archive-timeout=тайм-аут] [--external-dirs=путь_внешнего_каталога]
[--restore-command=команда]
[параметры_удалённого_режима] [параметры_удалённого_архива_wal] [параметры_журнала]

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

Все поддерживаемые параметры описываются в подразделе Параметры.

Редактировать pg_probackup.conf вручную не рекомендуется.

set-backup

pg_probackup set-backup -B каталог_копий --instance имя_экземпляра -i ид_резервной_копии
{--ttl=время_жизни | --expire-time=время} [--help]

Устанавливает заданные для конкретной резервной копии параметры в конфигурационном файле backup.control или изменяет ранее определённые значения.

Все поддерживаемые параметры описываются в подразделе Параметры закрепления.

show-config

pg_probackup show-config -B каталог_копий --instance имя_экземпляра [--format=plain|json]

Выводит содержимое файла pg_probackup.conf, размещённого в каталоге каталог_копий/backups/имя_экземпляра. Вы можете добавить параметр --format=json для получения результата в формате JSON. По умолчанию параметры конфигурации выводятся обычным текстом.

Чтобы изменить содержимое pg_probackup.conf, используйте команду set-config.

show

pg_probackup show -B каталог_копий
[--help] [--instance имя_экземпляра [-i ид_резервной_копии | --archive]] [--format=plain|json]

Показывает содержимое каталога копий. Если задано имя_экземпляра и ид_резервной_копии, выводится подробная информация об этой копии. С указанием --archive эта команда показывает содержимое архива WAL в данном каталоге.

По умолчанию содержимое каталога представляется в виде обычного текста. Вы можете передать параметр --format=json, чтобы получить результат в формате JSON.

Более подробно использование этой команды описывается в подразделах Управление каталогом резервных копий и Просмотр оглавления архива WAL.

backup

pg_probackup backup -B каталог_копий -b режим_копирования --instance имя_экземпляра
[--help] [-j число_потоков] [--progress]
[-C] [--stream [-S slot_name] [--temp-slot]] [--backup-pg-log]
[--no-validate] [--skip-block-validation]
[-w --no-password] [-W --password]
[--archive-timeout=тайм-аут] [--external-dirs=путь_внешнего_каталога]
[параметры_соединения] [параметры_сжатия] [параметры_удалённого_режима]
[параметры_хранения] [параметры_закрепления] [параметры_журнала]

Создаёт резервную копию экземпляра Postgres Pro.

-b режим
--backup-mode=режим

Выбирает режим резервного копирования. Поддерживаются следующие режимы:

  • FULL — создаётся полная резервная копия, содержащая все файлы данных кластера, необходимые для его восстановления.

  • DELTA — считываются все файлы данных в каталоге данных и создаётся инкрементальная копия для страниц, изменённых со времени предыдущего копирования.

  • PAGE — создаётся инкрементальная резервная копия с файлами WAL, которые были изменены со времени последней полной или инкрементальной копии.

  • PTRACK — создаётся инкрементальная резервная копия со страницами, изменения в которых отслеживались на лету.

-C
--smooth-checkpoint

Растягивает выполнение контрольной точки во времени. По умолчанию pg_probackup пытается произвести контрольную точку максимально быстро.

--stream

Создаёт потоковую резервную копию (STREAM), включая в неё все необходимые файлы WAL, получаемые от сервера по протоколу репликации.

--temp-slot

Создаёт временный слот физической репликации для передачи WAL с архивируемого экземпляра Postgres Pro. Это гарантирует, что все нужные сегменты WAL будут доступны, если в процессе копирования произойдёт переключение сегментов WAL. Этот параметр может использоваться только вместе с параметром --stream. По умолчанию имя слота — pg_probackup_slot, но его можно поменять, воспользовавшись параметром --slot/-S.

-S имя_слота
--slot=имя_слота

Задаёт слот репликации для передачи WAL. Этот параметр можно указать только вместе с параметром --stream.

--backup-pg-log

Включает в резервную копию каталог log. Этот каталог обычно содержит журналы сообщений сервера. По умолчанию каталог log в копию не включается.

-E путь_внешнего_каталога
--external-dirs=путь_внешнего_каталога

Включает в создаваемую копию указанный каталог. Этот параметр полезен для архивирования скриптов, SQL-дампов и файлов конфигурации, расположенных вне каталога данных. Если вы хотите архивировать несколько внешних каталогов, их пути нужно разделять двоеточием в Linux или точкой с запятой в Windows.

--archive-timeout=время_ожидания

Задаёт тайм-аут для архивирования сегментов WAL и потоковой передачи (в секундах). По умолчанию pg_probackup ждёт выполнения этих операций 300 секунд.

--skip-block-validation

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

--no-validate

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

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

За подробностями обратитесь к подразделу Создание резервной копии.

restore

pg_probackup restore -B каталог_копий --instance имя_экземпляра
[--help] [-D каталог_данных] [-i ид_резервной_копии]
[-j число_потоков] [--progress]
[-T СТАРЫЙ_КАТАЛОГ=НОВЫЙ_КАТАЛОГ] [--external-mapping=СТАРЫЙ_КАТАЛОГ=НОВЫЙ_КАТАЛОГ] [--skip-external-dirs]
[-R | --restore-as-replica] [--no-validate] [--skip-block-validation] [--force]
[--restore-command=команда]
[параметры_точки_восстановления] [параметры_журнала] [параметры_удалённого_режима]
[параметры_частичного_восстановления] [параметры_удалённого_архива_wal]

Восстанавливает экземпляр Postgres Pro из резервной копии, расположенной в каталоге каталог_копий. Если вы укажете один или несколько параметров точки восстановления, pg_probackup найдёт ближайшую к этой точке копию и выполнит восстановление до заданной точки. Если ни идентификатор копии, ни параметры точки восстановления не задаются, pg_probackup выполняет восстановление, используя самую последнюю копию.

-R
--restore-as-replica

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

-T СТАРЫЙ_КАТАЛОГ=НОВЫЙ_КАТАЛОГ
--tablespace-mapping=СТАРЫЙ_КАТАЛОГ=НОВЫЙ_КАТАЛОГ

Перемещает табличное пространство из каталога СТАРЫЙ_КАТАЛОГ в НОВЫЙ_КАТАЛОГ во время восстановления. И СТАРЫЙ_КАТАЛОГ, и НОВЫЙ_КАТАЛОГ должны задаваться абсолютными путями. Если путь содержит знак равно (=), экранируйте этот знак обратной косой чертой. Данный параметр может указываться неоднократно для перемещения нескольких табличных пространств.

--external-mapping=СТАРЫЙ_КАТАЛОГ=НОВЫЙ_КАТАЛОГ

Перемещает внешний каталог, включённый в резервную копию, из каталога СТАРЫЙ_КАТАЛОГ в НОВЫЙ_КАТАЛОГ во время восстановления. И СТАРЫЙ_КАТАЛОГ, и НОВЫЙ_КАТАЛОГ должны задаваться абсолютными путями. Если путь содержит знак равно (=), экранируйте этот знак обратной косой чертой. Данный параметр может указываться неоднократно для нескольких каталогов.

--skip-external-dirs

Пропускать внешние каталоги, включённые в резервную копию указанием --external-dirs. Содержимое этих каталогов не будет восстановлено.

--skip-block-validation

Отключает проверку контрольных сумм на уровне блоков для ускорения проверки целостности. При автоматической проверке перед восстановлением будут проверяться только контрольные суммы на уровне файлов.

--no-validate

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

--restore-command=команда

Задаёт значение для параметра restore_command. Например: --restore-command='cp /mnt/server/archivedir/%f "%p"'

--force

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

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

За подробностями обратитесь к подразделу Восстановление кластера.

checkdb

pg_probackup checkdb
[-B каталог_копий] [--instance имя_экземпляра] [-D каталог_данных]
[--help] [-j число_потоков] [--progress]
[--skip-block-validation] [--amcheck] [--heapallindexed]
[параметры_соединения] [параметры_журнала]

Проверяет целостность кластера баз данных Postgres Pro, выявляя физические и логические повреждения.

--amcheck

Производит логическую проверку индексов для указанного экземпляра Postgres Pro, если не были выявлены повреждения при проверке файлов данных. Для проверки индексов в базе данных в ней должно быть установлено расширение amcheck или amcheck_next. В базах данных, где amcheck отсутствует, индексы проверяться не будут.

--skip-block-validation

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

--heapallindexed

Проверяет, отражены ли в индексах все кортежи кучи, которые должны быть проиндексированы. Этот ключ можно использовать только вместе с --amcheck.

Эта проверка возможна, только если вы используете расширение amcheck версии 2.0 или новее либо amcheck_next любой версии.

Также вы можете задать параметры соединения и ведения журнала.

За подробностями обратитесь к подразделу Проверка кластера.

validate

pg_probackup validate -B каталог_копий
[--help] [--instance имя_экземпляра] [-i ид_резервной_копии]
[-j число_потоков] [--progress]
[--skip-block-validation]
[параметры_точки_восстановления] [параметры_журнала]

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

За подробностями обратитесь к подразделу Проверка копии.

merge

pg_probackup merge -B каталог_копий --instance имя_экземпляра -i ид_резервной_копии
[--help] [-j число_потоков] [--progress]
[параметры_журнала]

Объединяет указанную инкрементальную копию с её родительской полной копией, вместе со всеми инкрементальными копиями между ними. В результате полная копия будет вмещать в себя все данные, а инкрементальные копии будут удалены как избыточные.

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

delete

pg_probackup delete -B каталог_копий --instance имя_экземпляра
[--help] [-j число_потоков] [--progress]
[--retention-redundancy=избыточность][--retention-window=окно][--wal-depth=глубина_wal]
[--delete-wal] {-i ид_резервной_копии | --delete-expired [--merge-expired] | --merge-expired}
[--dry-run]
[параметры_журнала]

Удаляет копию с заданным идентификатором (ид_резервной_копии) или запускает процедуру удаления резервных копий или заархивированных файлов WAL, не удовлетворяющих текущей политике хранения.

За подробностями обратитесь к подразделам Удаление резервных копий, Параметры хранения и Настройка политики хранения.

archive-push

pg_probackup archive-push -B каталог_копий --instance имя_экземпляра
--wal-file-path=путь_файла_wal --wal-file-name=имя_файла_wal
[--help] [--compress] [--compress-algorithm=алгоритм_сжатия]
[--compress-level=уровень_сжатия] [--overwrite]
[параметры_удалённого_режима] [параметры_журнала]

Копирует файлы WAL в соответствующий подкаталог каталога копий, проверяя целевой экземпляр по имени_экземпляра и значению system-identifier. Если параметры экземпляра резервной копии и кластера не совпадают, операция копирования не выполняется, и выдаётся ошибка: Refuse to push WAL segment segment_name into archive. Instance parameters mismatch. (Отказано в помещении сегмента имя_сегмента в архив. Параметры экземпляра не совпадают.) Для каждого файла WAL, помещаемого в каталог копий, вы увидите в журнале Postgres Pro такое сообщение: pg_probackup archive-push completed successfully (Операция pg_probackup archive-push завершена успешно).

Если файлы, которые требуется копировать, уже имеются в каталоге копий, pg_probackup вычисляет и сравнивает их контрольные суммы. В случае совпадения контрольных сумм archive-push пропускает соответствующий файл и выдаёт код успешного завершения. Если же они не совпадают, операция archive-push завершается с ошибкой. Если вы хотите заменять существующие файлы WAL в случае несовпадения контрольных сумм, добавьте к команде archive-push ключ --overwrite.

В процессе копирования содержимое файлов сначала помещается во временный файл с расширением .part. После переноса содержимого выполняется атомарная операция переименования. Тем самым гарантируется, что в случае ошибки команды archive-push непрерывное архивирование не остановится и что при параллельном архивировании WAL из разных источников в один архив повреждение архива исключено. В конце операции скопированные в архив сегменты WAL сбрасываются на диск.

Команду archive-push можно использовать в значении параметра archive_command Postgres Pro при настройке непрерывного архивирования WAL.

За подробностями обратитесь к подразделам Параметры архивирования и Параметры сжатия.

archive-get

pg_probackup archive-get -B каталог_копий --instance имя_экземпляра --wal-file-path=путь_файла_wal --wal-file-name=имя_файла_wal
[--help] [параметры_удалённого_режима] [параметры_журнала]

Копирует файлы WAL из соответствующего подкаталога каталога резервных копий в каталог журнала предзаписи кластера. Эта команда автоматически устанавливается программой pg_probackup в значении параметра restore_command в recovery.conf при восстановлении архивных копий с применением архива WAL. Устанавливать её вручную не нужно.

Параметры

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

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

Если некоторый параметр задаётся несколькими способами, значение в командной строке имеет наивысший приоритет, а значение в pg_probackup.conf — наименьший.

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

Ниже приведён список параметров общего характера.

-B каталог
--backup-path=каталог
BACKUP_PATH

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

-D каталог
--pgdata=каталог
PGDATA

Задаёт абсолютный путь к каталогу данных кластера. Этот параметр является обязательным только для команды add-instance. Другие команды могут получать этот путь из переменной окружения PGDATA или из файла конфигурации pg_probackup.conf.

-i ид_резервной_копии
--backup-id=ид_резервной_копии

Задаёт уникальный идентификатор резервной копии.

-j число_потоков
--threads=число_потоков

Задаёт число параллельных потоков, запускаемых командами backup, restore, merge, validate и checkdb.

--progress

Включает вывод прогресса выполнения операций.

--help

Выводит подробную информацию по параметрам, которые принимает эта команда.

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

Если настроено непрерывное архивирование WAL, вы можете передать один из этих параметров с командой restore или validate, чтобы указать момент, до которого должен быть восстановлен или проверен кластер баз данных.

--recovery-target=immediate|latest

Определяет, когда остановить восстановление:

  • Со значением immediate восстановление завершается сразу после достижения согласованного состояния выбранной копии, либо последней копии из имеющихся, если параметр -i/--backup_id опущен. Такое поведение по умолчанию применяется для копий типа STREAM.

  • Со значением latest восстановление продолжается до тех пор, пока не будут применены все имеющиеся в архиве сегменты WAL. Такое поведение по умолчанию применяется для копий типа ARCHIVE.

--recovery-target-timeline=линия_времени

Выбирает линию времени для восстановления. По умолчанию выбирается линия времени указанной резервной копии.

--recovery-target-lsn=lsn

Указывает, до какого последовательного номера в журнале предзаписи должно производиться восстановление. Может использоваться только при восстановлении кластеров версии 10 или выше.

--recovery-target-name=имя_цели_восстановления

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

--recovery-target-time=время

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

--recovery-target-xid=ид_транзакции

Указывает идентификатор транзакции, вплоть до которой будет производиться восстановление.

--recovery-target-inclusive=логическое_значение

Указывает на необходимость остановки сразу после (true) либо до (false) достижения целевой точки. Этот параметр можно использовать только вместе с параметром --recovery-target-name, --recovery-target-time, --recovery-target-lsn или --recovery-target-xid. Значение по умолчанию определяется параметром recovery_target_inclusive.

--recovery-target-action=pause|promote|shutdown

Задаёт действие (recovery_target_action), которое должен выполнить сервер по достижении цели восстановления.

По умолчанию: pause

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

Эти параметры могут использоваться с командами backup и delete.

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

--retention-redundancy=избыточность

Указывает, сколько полных резервных копий должно сохраняться в каталоге данных. Должно быть неотрицательным целым числом. Ноль отключает сохранение.

По умолчанию: 0

--retention-window=окно

Количество дней, в течение которого возможно восстановление. Должно быть неотрицательным целым числом. При нулевом значении окно восстановления отсутствует.

По умолчанию: 0

--wal-depth=глубина_wal

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

По умолчанию: 0

--delete-wal

Удаляет файлы WAL, которые не являются необходимыми для восстановления кластера из имеющихся резервных копий.

--delete-expired

Удаляет резервные копии, не удовлетворяющие политике сохранения, определённой в файле конфигурации pg_probackup.conf.

--merge-expired

Объединяет самую старую инкрементальную копию, удовлетворяющую требованиям политики хранения, с её родительскими копиями, срок хранения которых истёк.

--dry-run

Выводит текущее состояние всех имеющихся резервных копий, но никакие операции, например, удаление или объединение старых копий, при этом не производятся.

Параметры закрепления

Эти параметры могут использоваться с командами backup и set-backup.

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

--ttl=время_жизни

Задаёт время, на которое закрепляется резервная копия. Значение должно быть неотрицательным целым. Нулевое значение отменяет установленное ранее закрепление резервной копии. Поддерживаются следующие единицы измерения: ms (миллисекунды), s (секунды), min (минуты), h (часы), d (дни). По умолчанию подразумеваются секунды.

Например: --ttl=30d

--expire-time=время

Определяет момент времени, до которого будет храниться резервная копия. Время должно задаваться в формате ISO-8601.

Например: --expire-time='2020-01-01 00:00:00+03'

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

Эти параметры могут использоваться с любой командой.

--log-level-console=уровень_сообщений

Управляет уровнем сообщений, которые будут выводиться в журнал консоли. Допустимые уровни: verbose, log, info, warning, error и off. Каждый уровень включает все последующие, и с каждым последующим уровнем объём сообщений уменьшается. Вариант off отключает вывод в журнал консоли.

По умолчанию: info

Примечание

Все выводимые в консоль сообщения журнала передаются через stderr, чтобы их можно было отделить от вывода команд show и show-config.

--log-level-file=уровень_сообщений

Управляет уровнем сообщений, которые будут выводиться в файл журнала. Допустимые уровни: verbose, log, info, warning, error и off. Каждый уровень включает все последующие, и с каждым последующим уровнем объём сообщений уменьшается. Вариант off отключает вывод в файл журнала.

По умолчанию: off

--log-filename=файл_журнала

Определяет имена для создаваемых файлов журналов. Имена файлов обрабатываются по шаблону strftime, так что вы можете использовать спецкоды с % для выбора имён файлов, зависящих от времени.

По умолчанию: pg_probackup.log

Например, если задать шаблон pg_probackup-%u.log, pg_probackup будет записывать журнал в отдельные файлы по дням недели, и символы %u в имени будут заменяться соответствующим десятичным номером: pg_probackup-1.log в понедельник, pg_probackup-2.log во вторник и т. д.

Этот параметр действует, если включена запись в журнал (параметром --log-level-file).

--error-log-filename=файл_журнала_событий

Определяет имена только для файлов журналов ошибок. Имена файлов обрабатываются по шаблону strftime, так что вы можете использовать спецкоды с % для выбора имён файлов, зависящих от времени.

По умолчанию: none

Например, если задать шаблон error-pg_probackup-%u.log, pg_probackup будет записывать журнал в отдельные файлы по дням недели, и символы %u в имени будут заменяться соответствующим десятичным номером: error-pg_probackup-1.log в понедельник, error-pg_probackup-2.log во вторник и т. д.

Этот параметр полезен для диагностики и решения возникающих проблем.

--log-directory=каталог_журнала

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

По умолчанию: $BACKUP_PATH/log/

--log-rotation-size=размер_журнала_для_ротации

Максимальный размер отдельного файла журнала. Если это значение достигается, файл журнала прокручивается при выполнении какой-либо команды pg_probackup, за исключением help и version. Нулевое значение отключает прокрутку в зависимости от размера. Поддерживаются следующие единицы: kB (по умолчанию), MB, GB, TB.

По умолчанию: 0

--log-rotation-age=возраст_журнала_для_ротации

Максимальное время жизни отдельного файла журнала. Если это значение достигается, файл журнала прокручивается при выполнении какой-либо команды pg_probackup, за исключением help и version. Время создания последнего файла журнала сохраняется в $BACKUP_PATH/log/log_rotation. Нулевое значение отключает прокрутку по времени. Поддерживаемые единицы: ms (миллисекунды), s (секунды), min (минуты, по умолчанию), h (часы), d (дни).

По умолчанию: 0

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

Эти параметры могут использоваться с командами backup и checkdb.

pg_probackup поддерживает все переменные окружения libpq.

-d имя_бд
--pgdatabase=имя_бд
PGDATABASE

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

-h сервер
--pghost=сервер
PGHOST

Указывает имя системы, в которой работает сервер. Если значение начинается с косой черты, оно определяет каталог Unix-сокета.

По умолчанию: localhost

-p порт
--pgport=порт
PGPORT

Указывает TCP-порт или расширение файла локального Unix-сокета, через который сервер принимает подключения.

По умолчанию: 5432

-U имя_пользователя
--pguser=имя_пользователя
PGUSER

Имя пользователя для подключения.

-w
--no-password

Не выдавать запрос на ввод пароля. Если сервер требует аутентификацию по паролю и пароль не доступен с помощью других средств, таких как файл .pgpass или переменная окружения PGPASSWORD, попытка соединения не удастся. Этот параметр может быть полезен в пакетных заданиях и скриптах, где нет пользователя, который вводит пароль.

-W
--password

Запрашивать пароль.

Параметры сжатия

Эти параметры могут использоваться с командами backup и archive-push.

--compress-algorithm=алгоритм_сжатия

Определяет алгоритм, который будет использоваться для сжатия файлов данных. Возможные значения: zlib, pglz и none. Значение zlib или pglz включает сжатие. По умолчанию сжатие отключено. Для команды archive-push алгоритм сжатия pglz не поддерживается.

По умолчанию: none

--compress-level=уровень_сжатия

Определяет уровень сжатия (от 0 до 9, где 0 обозначает отсутствие сжатия, а 9 — наилучшее). Этот параметр может использоваться только вместе с --compress-algorithm.

По умолчанию: 1

--compress

Альтернативный вариант одновременного указания --compress-algorithm=zlib и --compress-level=1.

Параметры архивации

Эти параметры могут использоваться с командой archive-push в значении параметра archive_command и с командой archive-get в значении restore_command.

Дополнительно вы можете задать параметры удалённого сервера и ведения журнала.

--wal-file-path=путь_файла_wal

Задаёт путь файла WAL в archive_command и restore_command. В качестве значения для данного параметра укажите %p для правильной его обработки.

--wal-file-name=имя_файла_wal

Задаёт имя файла WAL в archive_command и restore_command. В качестве значения для данного параметра укажите %f для правильной его обработки.

--overwrite

Разрешает перезапись файлов WAL в архиве. Этот ключ действует при выполнении команды archive-push, когда указанный подкаталог каталога резервных копий уже содержит данный файл WAL, и его нужно заменить новой копией. Без этого ключа archive-push сообщит, что сегмент WAL уже существует, и прервёт операцию. Если заменяемый файл не изменился, archive-push пропускает его, независимо от указания --overwrite.

Параметры удалённого режима

В этом подразделе описываются параметры, связанные с удалённым выполнением операций pg_probackup по SSH. Эти параметры могут использоваться с командами add-instance, set-config, backup, restore, archive-push и archive-get.

Подробнее о настройке и использовании удалённого режима рассказывается в Подразделе «Настройка удалённого режима» и Подразделе «Использование pg_probackup в удалённом режиме».

--remote-proto=протокол

Задаёт протокол для удалённого выполнения операций. В настоящее время поддерживается только протокол SSH. Возможные значения:

  • ssh — включает удалённый режим с использованием SSH. Этот вариант используется по умолчанию.

  • none — явным образом отключает удалённый режим.

Этот параметр можно не задавать, если указывается --remote-host.

--remote-host=целевой_адрес

Задаёт имя или IP-адрес целевого удалённого сервера.

--remote-port=порт

Задаёт целевой порт на удалённом сервере.

По умолчанию: 22

--remote-user=имя_пользователя

Задаёт имя пользователя на удалённом сервере для SSH-соединения. В отсутствие этого параметра используется имя текущего пользователя, устанавливающего SSH-соединения.

--remote-path=путь

Задаёт каталог, в котором pg_probackup установлен на удалённой системе.

--ssh-options=параметры_ssh

Задаёт строку параметров командной строки для SSH. Например, следующим образом можно установить свойства keep-alive для SSH-подключений, которые будет открывать pg_probackup: --ssh-options='-o ServerAliveCountMax=5 -o ServerAliveInterval=60'. Полный список всех параметров можно найти в руководстве по ssh_config.

Параметры удалённого архива WAL

В этом подразделе описываются параметры, позволяющие задать аргументы archive-get для использования удалённого режима в команде restore_command при восстановлении копий типа ARCHIVE или осуществления восстановления PITR.

--archive-host=целевой_адрес

Задаёт значение аргумента --remote-host для команды archive-get.

--archive-port=порт

Задаёт значение аргумента --remote-port для команды archive-get.

По умолчанию: 22

--archive-user=имя_пользователя

Задаёт значение аргумента --remote-user для команды archive-get. В отсутствие этого указания используется имя пользователя, запускающего кластер Postgres Pro.

По умолчанию: пользователь Postgres Pro

Параметры частичного восстановления

В этом подразделе описываются параметры, связанные с частичным восстановлением кластера. Эти параметры могут передаваться с командой restore.

--db-exclude=имя_бд

Задаёт имя базы данных, которая должна быть исключена из числа восстанавливаемых. Все остальные базы данных в кластере будут восстанавливаться, включая template0 и template1. Этот параметр можно задать несколько раз, таким образом исключив несколько баз данных.

--db-include=имя_бд

Задаёт имя базы данных, которая должна восстанавливаться. Все остальные базы данных восстанавливаться не будут, за исключением template0 и template1. Этот параметр можно задать несколько раз, таким образом выбрав для восстановления несколько баз данных.

Репликационные параметры

В этом разделе описываются параметры, относящиеся к резервному копированию с ведомого сервера.

Примечание

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

--master-db=имя_бд

Устаревший параметр. Указывает имя базы данных на главном сервере, к которой будет выполнено подключение. Это подключение используется только для управления резервным копированием, так что возможно подключение к любой существующей базе данных. Его можно задать в pg_probackup.conf с помощью команды set-config.

По умолчанию: postgres, принятое по умолчанию в Postgres Pro имя базы данных

--master-host=сервер

Устаревший параметр. Указывает имя компьютера, на котором работает ведущий сервер.

--master-port=порт

Устаревший параметр. Задаёт TCP-порт или расширение файла Unix-сокета, через который сервер принимает подключения.

По умолчанию: 5432, стандартный порт Postgres Pro

--master-user=имя_пользователя

Устаревший параметр. Задаёт имя пользователя для подключения.

Если не задано, подразумевается postgres, имя пользователя по умолчанию в Postgres Pro

--replica-timeout=тайм-аут

Устаревший параметр. Время ожидания передачи сегментов средствами репликации (в секундах). По умолчанию pg_probackup ожидает 300 секунд. Вы также можете определить этот параметр в файле конфигурации pg_probackup.conf с помощью команды set-config.

По умолчанию: 300 sec

Практические примеры

Во всех последующих примерах предполагается использование удалённого режима по протоколу SSH. Если вы хотите выполнять резервное копирование и восстановление локально, пропустите этап «Настройка SSH-подключения без пароля» и не указывайте никакие параметры --remote-*.

Показанные здесь действия выполнялись в среде с Ubuntu 18.04, Postgres Pro 11 и pg_probackup 2.2.0.

  • backup_host — система, где находится каталог резервных копий.

  • backupman — пользователь в системе backup_host, от имени которого выполняются все операции pg_probackup.

  • /mnt/backups — путь к каталогу резервных копий в системе backup_host.

  • postgres_host — система, в которой работает Postgres Pro.

  • postgres — пользователь в системе postgres_host, от имени которого запускается кластер Postgres Pro.

  • /var/lib/postgresql/11/main — путь к каталогу данных Postgres Pro в системе postgres_host.

  • backupdb — база данных, через которую выполняется подключение к кластеру Postgres Pro.

Минимальная настройка

Данный сценарий иллюстрирует настройку для выполнения полного и разностного копирования.

  1. Настройте подключение через SSH с backup_host к postgres_host:

    [backupman@backup_host] ssh-copy-id postgres@postgres_host
  2. Настройте кластер Postgres Pro.

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

    postgres=#
    CREATE DATABASE backupdb;

    Подключитесь к базе backupdb, создайте роль probackup и дайте ей следующие права:

    backupdb=#
    BEGIN;
    CREATE ROLE probackup WITH LOGIN REPLICATION;
    GRANT USAGE ON SCHEMA pg_catalog TO probackup;
    GRANT EXECUTE ON FUNCTION pg_catalog.current_setting(text) TO probackup;
    GRANT EXECUTE ON FUNCTION pg_catalog.pg_is_in_recovery() TO probackup;
    GRANT EXECUTE ON FUNCTION pg_catalog.pg_start_backup(text, boolean, boolean) TO probackup;
    GRANT EXECUTE ON FUNCTION pg_catalog.pg_stop_backup(boolean, boolean) TO probackup;
    GRANT EXECUTE ON FUNCTION pg_catalog.pg_create_restore_point(text) TO probackup;
    GRANT EXECUTE ON FUNCTION pg_catalog.pg_switch_wal() TO probackup;
    GRANT EXECUTE ON FUNCTION pg_catalog.pg_last_wal_replay_lsn() TO probackup;
    GRANT EXECUTE ON FUNCTION pg_catalog.txid_current() TO probackup;
    GRANT EXECUTE ON FUNCTION pg_catalog.txid_current_snapshot() TO probackup;
    GRANT EXECUTE ON FUNCTION pg_catalog.txid_snapshot_xmax(txid_snapshot) TO probackup;
    GRANT EXECUTE ON FUNCTION pg_catalog.pg_control_checkpoint() TO probackup;
    COMMIT;
  3. Проинициализируйте каталог резервных копий:

    [backupman@backup_host]$ pg_probackup-11 init -B /mnt/backups
    INFO: Backup catalog '/mnt/backups' successfully inited
  4. Добавьте экземпляр pg-11 в каталог резервных копий:

    [backupman@backup_host]$ pg_probackup-11 add-instance -B /mnt/backups --instance 'pg-11' --remote-host=postgres_host --remote-user=postgres -D /var/lib/postgresql/11/main
    INFO: Instance 'node' successfully inited
  5. Сделайте полную резервную копию:

    [backupman@backup_host] pg_probackup-11 backup -B /mnt/backups --instance 'pg-11' -b FULL --stream --remote-host=postgres_host --remote-user=postgres -U probackup -d backupdb
    INFO: Backup start, pg_probackup version: 2.2.0, instance: node, backup ID: PZ7YK2, backup mode: FULL, wal mode: STREAM, remote: true, compress-algorithm: none, compress-level: 1
    INFO: Start transferring data files
    INFO: Data files are transferred
    INFO: wait for pg_stop_backup()
    INFO: pg_stop backup() successfully executed
    INFO: Validating backup PZ7YK2
    INFO: Backup PZ7YK2 data files are valid
    INFO: Backup PZ7YK2 resident size: 196MB
    INFO: Backup PZ7YK2 completed
  6. Взгляните на содержимое каталога копий:

    [backupman@backup_host] pg_probackup-11 backup -B /mnt/backups --instance 'pg-11'
    
    BACKUP INSTANCE 'pg-11'
    ==================================================================================================================================
     Instance  Version  ID      Recovery Time           Mode   WAL Mode  TLI  Time   Data   WAL  Zratio  Start LSN  Stop LSN   Status
    ==================================================================================================================================
     node      11       PZ7YK2  2019-10-11 19:45:45+03  FULL  STREAM    1/0   11s  180MB  16MB    1.00  0/3C000028  0/3C000198  OK
  7. Сделайте инкрементальную резервную копию в режиме DELTA:

    [backupman@backup_host] pg_probackup-11 backup -B /mnt/backups --instance 'pg-11' -b delta --stream --remote-host=postgres_host --remote-user=postgres -U probackup -d backupdb
    INFO: Backup start, pg_probackup version: 2.2.0, instance: node, backup ID: PZ7YMP, backup mode: DELTA, wal mode: STREAM, remote: true, compress-algorithm: none, compress-level: 1
    INFO: Parent backup: PZ7YK2
    INFO: Start transferring data files
    INFO: Data files are transferred
    INFO: wait for pg_stop_backup()
    INFO: pg_stop backup() successfully executed
    INFO: Validating backup PZ7YMP
    INFO: Backup PZ7YMP data files are valid
    INFO: Backup PZ7YMP resident size: 32MB
    INFO: Backup PZ7YMP completed
  8. Добавьте несколько параметров в файл конфигурации pg_probackup, чтобы их не надо было задавать в командной строке:

    [backupman@backup_host] pg_probackup-11 set-config -B /mnt/backups --instance 'pg-11' --remote-host=postgres_host --remote-user=postgres -U probackup -d backupdb
  9. Сделайте ещё одну инкрементальную копию в режиме DELTA, опустив некоторые из предыдущих параметров:

    [backupman@backup_host] pg_probackup-11 backup -B /mnt/backups --instance 'pg-11' -b delta --stream
    INFO: Backup start, pg_probackup version: 2.2.0, instance: node, backup ID: PZ7YR5, backup mode: DELTA, wal mode: STREAM, remote: true, compress-algorithm: none, compress-level: 1
    INFO: Parent backup: PZ7YMP
    INFO: Start transferring data files
    INFO: Data files are transferred
    INFO: wait for pg_stop_backup()
    INFO: pg_stop backup() successfully executed
    INFO: Validating backup PZ7YR5
    INFO: Backup PZ7YR5 data files are valid
    INFO: Backup PZ7YR5 resident size: 32MB
    INFO: Backup PZ7YR5 completed
  10. Взгляните на конфигурацию экземпляра:

    [backupman@backup_host] pg_probackup-11 show-config -B /mnt/backups --instance 'pg-11'
    
    # Backup instance information
    pgdata = /var/lib/postgresql/11/main
    system-identifier = 6746586934060931492
    xlog-seg-size = 16777216
    # Connection parameters
    pgdatabase = backupdb
    pghost = postgres_host
    pguser = probackup
    # Replica parameters
    replica-timeout = 5min
    # Archive parameters
    archive-timeout = 5min
    # Logging parameters
    log-level-console = INFO
    log-level-file = OFF
    log-filename = pg_probackup.log
    log-rotation-size = 0
    log-rotation-age = 0
    # Retention parameters
    retention-redundancy = 0
    retention-window = 0
    wal-depth = 0
    # Compression parameters
    compress-algorithm = none
    compress-level = 1
    # Remote access parameters
    remote-proto = ssh
    remote-host = postgres_host

    Заметьте, что параметры, не переопределённые командой set-config, имеют значения по умолчанию.

  11. Взгляните на содержимое каталога копий:

    [backupman@backup_host] pg_probackup-11 backup -B /mnt/backups --instance 'pg-11'
    
    ====================================================================================================================================
     Instance  Version  ID      Recovery Time           Mode   WAL Mode  TLI  Time   Data   WAL  Zratio  Start LSN   Stop LSN    Status
    ====================================================================================================================================
     node      11       PZ7YR5  2019-10-11 19:49:56+03  DELTA  STREAM    1/1   10s  112kB  32MB    1.00  0/41000028  0/41000160  OK
     node      11       PZ7YMP  2019-10-11 19:47:16+03  DELTA  STREAM    1/1   10s  376kB  32MB    1.00  0/3E000028  0/3F0000B8  OK
     node      11       PZ7YK2  2019-10-11 19:45:45+03  FULL   STREAM    1/0   11s  180MB  16MB    1.00  0/3C000028  0/3C000198  OK

Версионирование

При разработке pg_probackup используется семантическое версионирование.

Авторы

Postgres Professional, Москва, Россия.

Благодарности

Программа pg_probackup основана на pg_arman, которая изначально была написана в NTT, а затем её развивал и поддерживал Микаэль Пакье.