Перейти к содержимому

18 Занятие 18: Резервное копирование / Основы pg_probackup

Исходная страница в нативном Markdown: Резервное копирование / Основы pg_probackup
Примечание

Эта страница извлечена из официального PDF в нативный Markdown. Текст слайдов, код и комментарии сохранены в порядке чтения; исходные PDF и HTML остаются эталоном макета. HTML source: pgpro_18_probackup_1.html Archive: PGPRO-handouts-16.zip Страниц PDF: 31

Page 1: Резервное копирование / Основы pg_probackup

Авторские права

© Postgres Professional, 2023–2026 Авторы: Алексей Береснев, Илья Баштанов, Павел Толмачев, Игорь Гнатюк Фото: Олег Бартунов (монастырь Пху и пик Бхрикути, Непал)

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

Некоммерческое использование материалов курса (презентации, демонстрации) разрешается без ограничений. Коммерческое использование возможно только с письменного разрешения компании Postgres Professional. Запрещается внесение изменений в материалы курса.

Обратная связь

Отзывы, замечания и предложения направляйте по адресу: edu@postgrespro.ru

Отказ от ответственности

Компания Postgres Professional не несет никакой ответственности за любые повреждения и убытки, включая потерю дохода, нанесенные прямым или непрямым, специальным или случайным использованием материалов курса. Компания Postgres Professional не предоставляет каких-либо гарантий на материалы курса. Материалы курса предоставляются на основе принципа «как есть» и компания Postgres Professional не обязана предоставлять сопровождение, поддержку, обновления, расширения и изменения.

Page 2: Темы

  • Резервное копирование
  • Полное копирование

Page 3: Резервное копирование

Риски и требования

  • Характеристики
  • Общая классификация
  • Инструменты PostgreSQL
  • Возможности pg_probackup

Page 4: Риски и требования

Резервное копирование снижает риски потери данных

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

Комментарии преподавателя

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

Основные причины, приводящие к возможной потере данных:

● природные и антропогенные катастрофы;

● отказы и сбои оборудования;

● ошибки в программном обеспечении;

● намеренная порча или кража оборудования;

● взлом или компрометация компьютерных систем;

● человеческие ошибки.

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

● расписание резервного копирования;

● процедуры проверки целостности и исправности копий;

● систему хранения резервных копий в надлежащих условиях;

● план восстановления системы с помощью резервных копий;

● средства защиты системы резервного копирования и самих копий.

Желательно обеспечить минимальное время копирования и восстановления и ограничить пространство для хранения копий.

Page 5: Характеристики

Source slide page 5: Характеристики{#source-figure-005 caption=“Source slide page 5: Характеристики”}

Идеальные характеристики

  • отношение времени работы системы к общему времени → 100 %
  • RTO — целевое время восстановления
  • → 0
  • RPO — целевая точка восстановления
  • → 0

Комментарии преподавателя

Идеальная система никогда не простаивает, и отношение времени продуктивной работы системы к общему времени ее эксплуатации равно 100%.

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

Оценка максимального периода времени, за который данные могут быть потеряны вследствие инцидента, связана с периодичностью и способами выполнения резервного копирования. Такая оценка выражается показателем Recovery Point Objective (RPO).

После обнаружения инцидента требуется время для восстановления системы. Показатель Recovery Time Objective (RTO) указывает целевое время, по истечении которого система восстанавливается для обслуживания клиентов.

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

Page 6: Общая классификация

По вовлеченности администратора

  • неконтролируемое (unattended)
  • контролируемое (attended)
  • По плановости
    • незапланированное (non-scheduled)
    • календарное (scheduled)
  • По полноте резервирования данных
    • полное (full)
    • инкрементальное (incremental)

Комментарии преподавателя

Принятая в системах резервного копирования классификация подразделяет резервное копирование по следующим критериям:

● по степени вовлеченности администратора в процесс резервного копирования на требующее контроля и автоматическое неконтролируемое копирование;

● является ли резервное копирование незапланированным, или же оно выполняется в соответствии с календарным расписанием;

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

Незапланированное резервное копирование осуществляется с помощью команды администратора (attended non-scheduled backup).

Однако чаще всего заранее создается календарный план резервного копирования, в котором фиксируется периодичность автоматического выполнения полного (full) или инкрементального (incremental) резервного копирования. Другое название инкрементальных копий — разностные копии (в конкретных системах резервного копирования понятия инкрементальных и разностных копий могут отличаться). Инкрементальные копии содержат данные, измененные с момента последнего резервного копирования, поэтому размер такой копии меньше, чем у полной.

СУБД имеют свою специфику: резервные копии могут включать или не включать журналы, содержать данные всего экземпляра или отдельных баз данных и т. п.

Page 7: Инструменты PostgreSQL

COPY, pg\_dump, pg\_dumpall

  • высокое RPO
  • pg_basebackup
    • нет каталога и хранилища резервных копий
    • нет политик хранения и удержания копий
    • нет инкрементального копирования
    • невозможна параллельная работа

Комментарии преподавателя

Собственные инструменты PostgreSQL позволяют выполнять как логическое копирование всего кластера или отдельных объектов, так и физическое копирование кластера. Эти инструменты подробно рассмотрены в курсе DBA3.

Однако имеющиеся в PostgreSQL инструменты неудобны для промышленного использования.

Средства логического резервирования не удовлетворяют поставленным требованиям из-за крайне высокого RPO.

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

Другой недостаток штатных инструментов — отсутствие политик, определяющих правила хранения копий и их последующего удаления.

Кроме того, производительность штатной утилиты pg_basebackup из-за ее однопоточности явно недостаточна для резервирования больших объемов данных.

Page 8: Возможности pg_probackup

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

  • Локальное или удаленное копирование, поддержка S3
  • Постраничное инкрементальное копирование
  • Восстановление выбранных баз данных
  • Параллельное резервирование и восстановление
  • Сжатие данных и поддержка CFS
  • Резервирование файлов вне каталога данных

Комментарии преподавателя

Утилита pg_probackup — система резервного копирования и восстановления корпоративного уровня, разработанная компанией Postgres Professional.

Утилита работает с централизованным каталогом копий и поддерживает инкрементальное копирование и восстановление.

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

Хранилище копий позволяет выполнять сложные операции, такие как слияние копий, и реализовывать политики их хранения. Имея каталог копий, можно проверять целостность данных и возможность восстановления на заданный момент времени (PITR, Point In Time Recovery), не выполняя само восстановление.

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

Другие важные возможности pg_probackup: восстановление из копии отдельных баз данных, поддержка сжатия данных и файловой системы CFS (Compressed File System), резервирование с физической реплики и резервирование файлов, находящихся вне PGDATA (например, файлов конфигурации), поддержка хранилищ S3, возможность ограничивать скорость записи данных на диск (для снижения нагрузки на систему ввода-вывода).

https://postgrespro.ru/docs/enterprise/16/app-pgprobackup

Page 9: Полное копирование

Локальная работа

  • Полная копия
  • Сжатие
  • Удаленная работа
  • Архивирование WAL

Page 10: Локальная работа

Source slide page 10: Локальная работа{#source-figure-010 caption=“Source slide page 10: Локальная работа”}

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

  • Простота
    • каталог резервных копий на локальной машине
    • архива WAL нет
    • используется потоковый режим

Комментарии преподавателя

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

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

Пользователь, запускающий pg_probackup, должен иметь полный доступ к каталогу копий. Каталог может содержать резервные копии разных кластеров баз данных; перед первым копированием кластера в каталог нужно выполнить команду pg_probackup add-instance для инициализации подкаталогов и метаданных.

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

https://postgrespro.ru/docs/enterprise/16/app-initdb#APP-INITDB-ALLOW-G ROUP-ACCESS

Page 11: Подготовка pg_probackup

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

student$ ls -l $(which pg_probackup)
lrwxrwxrwx 1 root root 34 июл 14 11:04 /usr/bin/pg_probackup ->
/opt/pgpro/ent-16/bin/pg_probackup

При локальной работе пользователь, запускающий pg_probackup, должен иметь доступ на чтение файлов каталога данных копируемого экземпляра. Для этого достаточно: при инициализации кластера запустить утилиту initdb с ключом -g; дать группе postgres право чтения каталога PGDATA; включить пользователя в группу postgres. Все эти действия были выполнены при настройке виртуальной машины курса. Работа с pg_probackup начинается с создания и инициализации каталога резервных копий.

student$ sudo mkdir /var/probackup

Утилите pg_probackup необходим доступ в этот каталог. Мы будем запускать утилиту от имени пользователя student, поэтому сделаем его владельцем каталога.

student$ sudo chown student: /var/probackup

Для инициализации каталога резервных копий используется команда init утилиты pg_probackup, параметр -B указывает местоположение каталога:

student$ pg_probackup init \
  -B /var/probackup
INFO: Backup catalog '/var/probackup' successfully initialized

Заглянем в каталог, чтобы проверить результаты инициализации.

student$ tree --noreport /var/probackup
/var/probackup
├── backups
└── wal

При инициализации были созданы два подкаталога: backups — для резервных копий, wal — для архива журнала предзаписи. Утилита pg_probackup имеет встроенную систему помощи. Получить информацию об отдельных командах утилиты можно командой help:

student$ pg_probackup help init

Или так:

student$ pg_probackup init --help
pg_probackup init -B backup-dir
  -B, --backup-path=backup-dir     location of the backup storage area
                 [--s3=s3-interface-provider]
      --dry-run                   perform a trial run without any changes

Следующий шаг — добавление копируемого экземпляра в каталог копий — выполняется командой add-instance: ключ -D указывает путь к каталогу данных копируемого экземпляра (PGDATA); ключ –instance задает имя экземпляра в каталоге копий.

student$ pg_probackup add-instance \
  -B /var/probackup --instance ent-16 \
  -D /var/lib/pgpro/ent-16
INFO: Instance 'ent-16' successfully initialized

Снова проверим содержимое каталога копий.

Page 12: Page 12

student$ tree --noreport /var/probackup
/var/probackup
├── backups
│   └── ent-16
│       ├── locks
│       └── pg_probackup.conf
└── wal
    └── ent-16

В результате: в каталогах backups и wal появились подкаталоги с именем экземпляра; для экземпляра создан файл конфигурации pg_probackup.conf. Содержимое файла конфигурации можно посмотреть средствами ОС, а полную информацию о конфигурации покажет команда show-config утилиты pg_probackup:

student$ pg_probackup show-config \
  -B /var/probackup --instance ent-16
# Backup instance information
pgdata = /var/lib/pgpro/ent-16
system-identifier = 7662291690466855210
xlog-seg-size = 16777216
postgres-edition = Postgres Pro enterprise 16
wal-tree = false
# Connection parameters
pgdatabase = student
# Archive parameters
archive-timeout = 5min
# Logging parameters
log-level-console = INFO
log-level-file = OFF
log-format-console = PLAIN
log-format-file = PLAIN
log-filename = pg_probackup.log
log-rotation-size = 0TB
log-rotation-age = 0d
# 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
# Backup instance information
write-rate-limit = 0GBps

Утилита сохранила в параметре system-identifier уникальный идентификатор экземпляра. Перед выполнением резервного копирования сохраненный идентификатор сверяется с идентификатором резервируемого экземпляра; при несовпадении резервирование не выполняется. Это защищает копии от ошибочных действий администратора. Рекомендуется использовать для резервного копирования непривилегированную роль с атрибутом replication. Такая роль создана заранее:

student$ psql
=> \du backup
      List of roles
 Role name | Attributes
-----------+-------------
 backup    | Replication

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

=> CREATE DATABASE pgpro_probackup_1 OWNER backup TEMPLATE templateprobackup;
CREATE DATABASE
=> \c pgpro_probackup_1
You are now connected to database "pgpro_probackup_1" as user "student".

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

Page 13: Page 13

=> SELECT routine_name
FROM information_schema.routine_privileges
WHERE grantee = 'backup';
      routine_name
-------------------------
 pg_backup_stop
 txid_current
 txid_current_snapshot
 txid_snapshot_xmax
 pg_control_checkpoint
 current_setting
 set_config
 pg_last_wal_replay_lsn
 pg_is_in_recovery
 pg_create_restore_point
 pg_switch_wal
 pg_backup_start
(12 rows)

Утилита pg_probackup использует стандартные параметры подключения к базе данных. Пользовательские параметры удобно записать в файл конфигурации с помощью команды set-config:

student$ pg_probackup set-config \
  -B /var/probackup --instance ent-16 \
  -d pgpro_probackup_1 \
  -U backup \
  --log-level-console=ERROR

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

student$ pg_probackup show-config \
  -B /var/probackup --instance ent-16 \
  | egrep '^(pg|log-level-console)'
pgdata = /var/lib/pgpro/ent-16
pgdatabase = pgpro_probackup_1
pguser = backup
log-level-console = ERROR

Page 14: Полная копия

Source slide page 14: Полная копия{#source-figure-014 caption=“Source slide page 14: Полная копия”}

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

  • Потоковый способ доставки → автономная копия

Комментарии преподавателя

Команда pg_probackup backup -b FULL формирует резервную копию, состоящую из базовой копии кластера и сегментов журнала предзаписи.

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

Если указать параметр –stream, записи журнала передаются потоковым способом. Если параметр не указать, утилита журнальные записи не получает; предполагается, что для экземпляра СУБД настроена файловая непрерывная архивация.

Оба варианта передачи WAL рассматриваются в курсе DBA3 «Резервное копирование и репликация».

Page 15: Сжатие

Source slide page 15: Сжатие{#source-figure-015 caption=“Source slide page 15: Сжатие”}

Сжимаются файлы данных и файлы сегментов WAL

--compress-algorithm=zstd
--compress-level=1

Комментарии преподавателя

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

Сжатие настраивается с помощью параметров –compress-algorithm и – compress-level, в которых можно указать алгоритм и уровень сжатия. Поддерживаются алгоритмы zstd, lz4, zlib и pglz, если соответствующие библиотеки установлены в системе, а значение возможных уровней сжатия зависит от алгоритма.

Параметр –compress задает алгоритм сжатия по умолчанию и устанавливает его уровень в единицу, то есть переопределяет параметры –compress-algorithm и –compress-level и не может быть использован одновременно с ними.

https://postgrespro.ru/docs/enterprise/16/app-pgprobackup#PBK-COMPRE SSION-OPTS

Page 16: Полная потоковая резервная копия

Получим автономную резервную копию c потоковой доставкой записей WAL: параметр -b FULL запрашивает полную копию; параметр –stream включает потоковую доставку WAL (по умолчанию используется файловая архивация); параметр –compress включает сжатие методом, установленным по умолчанию.

student$ pg_probackup backup \
  -B /var/probackup  --instance ent-16 \
  -b FULL \
  --stream \
  --compress

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

student$ pg_probackup show \
  -B /var/probackup --instance ent-16
==========================================================================================
===================================================
 Instance  Version  ID      Recovery Time                  Mode  WAL Mode  TLI  Time
Data   WAL  Zalg  Zratio  Start LSN  Stop LSN   Status
==========================================================================================
===================================================
 ent-16    16       TIUPNC  2026-07-27 23:45:19.717871+03  FULL  STREAM    1/0   36s
83MB  16MB  zstd    3,93  0/C000028  0/C001820  OK

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

student$ pg_probackup validate \
  -B /var/probackup --instance ent-16 \
  --log-level-console=INFO \
  -i TIUPNC
INFO: Validating backup TIUPNC
INFO: validate_tablespace_map_content start
INFO: Backup TIUPNC data files are valid
INFO: Backup TIUPNC WAL segments are valid
INFO: Backup TIUPNC is valid.
INFO: Validate of backup TIUPNC completed.

Команда show может показывать информацию о копии по ее идентификатору.

student$ pg_probackup show \
  -B /var/probackup --instance ent-16 \
  -i TIUPNC
#Configuration
backup-mode = FULL
stream = true
compress-alg = zstd
compress-level = 1
from-replica = false
#Compatibility
block-size = 8192
xlog-block-size = 8192
checksum-version = 1
program-version = 2.8.14
server-version = 16
cfs-backup-version = 1
hostname = course
#Result backup info
timelineid = 1
start-lsn = 0/C000028
stop-lsn = 0/C001820
start-time = '2026-07-27 23:45:12+03'
end-time = '2026-07-27 23:45:48+03'

Page 17: Page 17

backup-threads = 1
validate-threads = 1
end-validation-time = '2026-07-27 23:45:49+03'
recovery-xid = 963
recovery-time = '2026-07-27 23:45:19.717871+03'
data-bytes = 87369329
wal-bytes = 16777216
uncompressed-bytes = 343261318
pgdata-bytes = 343260869
status = OK
primary_conninfo = 'user=backup reusepass=1 channel_binding=prefer port=5432
sslmode=prefer sslcompression=0 sslcertmode=allow sslsni=1
ssl_min_protocol_version=TLSv1.2 gssencmode=prefer krbsrvname=postgres gssdelegation=0
target_session_attrs=any target_server_type=any hostorder=sequential
load_balance_hosts=disable'
content-crc = 1928193629

Поддерживается также вывод информации о копии в формате JSON. Эти данные сохраняются в каталоге резервной копии в файле backup.control, а информация о контрольных суммах — в файле backup_content.control. Удалим всю информацию об экземпляре, включая созданные резервные копии:

student$ pg_probackup del-instance \
  -B /var/probackup --instance ent-16

Page 18: Удаленная работа

Source slide page 18: Удаленная работа{#source-figure-018 caption=“Source slide page 18: Удаленная работа”}

Утилита запускается на сервере резервного копирования

  • Подключение к целевым серверам по SSH
  • Удаленная работа на целевом сервере выполняется агентами

Комментарии преподавателя

В удаленном режиме утилиту pg_probackup запускают на сервере резервного копирования (на котором расположен каталог копий); она подключается к целевому серверу по протоколу SSH (Secure Shell), запускает на нем процессы-агенты и с их помощью может выполнять резервное копирование, восстановление и архивирование WAL. Количество запускаемых агентов определяется параметром –threads. При ошибке любого агента аварийно завершаются остальные агенты экземпляра и породившая их команда pg_probackup.

На всех серверах должна быть установлена одна и та же версия pg_probackup.

При подключении по SSH аутентификация выполняется без ввода пароля, по ключу.

Параметры SSH-соединения:

● –remote-host — целевой сервер для копирования и восстановления;

● –remote-user — пользователь ОС, от имени которого работает агент на целевом сервере (владелец экземпляра Postgres);

● –remote-port — TCP-порт для подключения по SSH к целевому серверу.

https://postgrespro.ru/docs/enterprise/16/app-pgprobackup#PBK-CONFIGU RING-THE-REMOTE-MODE

Page 19: Удаленная работа

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

student$ pg_probackup add-instance \
  -B /var/probackup --instance ent-16 \
  -D /var/lib/pgpro/ent-16 \
  --log-level-console=ERROR \
  --remote-host=localhost \
  --remote-user=postgres

Не забудем о настройках конфигурации:

student$ pg_probackup set-config \
  -B /var/probackup --instance ent-16 \
  -d pgpro_probackup_1 \
  -U backup

Теперь выполним полное резервное копирование удаленного сервера, также используя потоковую доставку записей WAL:

student$ pg_probackup backup \
  -B /var/probackup --instance ent-16 \
  -b FULL \
  --stream

В каталоге резервных копий появилась запись:

student$ pg_probackup show \
  -B /var/probackup --instance ent-16
==========================================================================================
====================================================
 Instance  Version  ID      Recovery Time                  Mode  WAL Mode  TLI  Time
Data   WAL  Zalg  Zratio  Start LSN  Stop LSN   Status
==========================================================================================
====================================================
 ent-16    16       TIUPOG  2026-07-27 23:45:54.041458+03  FULL  STREAM    1/0   23s
328MB  16MB  none    1,00  0/E000028  0/E0001E8  OK

Page 20: Архивирование WAL

Source slide page 20: Архивирование WAL{#source-figure-020 caption=“Source slide page 20: Архивирование WAL”}

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

Комментарии преподавателя

Для инкрементального резервного копирования в режиме PAGE необходим архив журнала предзаписи, который дает возможность восстановления на момент в прошлом (PITR, Point-In-Time Recovery).

При создании резервной копии pg_probackup предполагает, что на копируемом экземпляре настроен механизм пополнения архива — обычно файловым способом. Команда архивирования должна корректно работать в случае сбоев, гарантировать сохранение файлов на диске и быть достаточно производительной. Чтобы не настраивать такую команду самостоятельно, удобно задать в параметре archive_command команду pg_probackup archive-push.

В данном случае утилиту pg_probackup вызывает СУБД, поэтому при работе через SSH целевым сервером, который указывается в параметрах –remote-*, будет сервер резервного копирования с каталогом резервных копий.

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

https://postgrespro.ru/docs/enterprise/16/app-pgprobackup#PBK-SETTING-UP-CONTINUOUS-WAL-ARCHIVING ​

Page 21: Архивирование WAL

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

=> ALTER SYSTEM SET archive_mode = on;
ALTER SYSTEM

Для команды архивирования целевым будет сервер резервного копирования, в нашем случае это localhost. Команда подключается к серверу по SSH от имени владельца каталога резервных копий — пользователя student.

=> ALTER SYSTEM SET archive_command =
'pg_probackup archive-push '
'-B /var/probackup --instance=ent-16'
' --wal-file-path=%p'
' --wal-file-name=%f'
' --remote-host=localhost'
' --remote-user=student';
ALTER SYSTEM

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

student$ sudo systemctl restart postgrespro-ent-16.service
student$ psql pgpro_probackup_1

Посмотрим на содержимое архива WAL:

student$ pg_probackup show \
  -B /var/probackup \
  --archive
ARCHIVE INSTANCE 'ent-16'
==========================================================================================
=======
 TLI  Parent TLI  Switchpoint  Min Segno  Max Segno  N segments  Size  Zratio  N backups
Status
==========================================================================================
=======

Пока архив пуст. Создадим таблицу и принудительно переключим сегмент WAL.

=> CREATE TABLE t AS SELECT 'Перед копированием в режиме ARCHIVE.' col1;
SELECT 1
=> SELECT pg_switch_wal();
 pg_switch_wal
---------------
 0/F00FBC4
(1 row)

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

=> VACUUM t;
VACUUM

Сегмент WAL попал в архив:

student$ pg_probackup show \
  -B /var/probackup \
  --archive
ARCHIVE INSTANCE 'ent-16'
==========================================================================================
=====================================
 TLI  Parent TLI  Switchpoint  Min Segno                 Max Segno                 N
segments  Size  Zratio  N backups  Status
==========================================================================================
=====================================
 1    0           0/0          00000001000000000000000F  00000001000000000000000F  1
     16MB  1,00    1          OK

Page 22: Page 22

Выполним полное резервное копирование. Поскольку настроена непрерывная файловая архивация, копировать WAL не нужно — параметр –stream не указываем.

student$ pg_probackup backup \
  -B /var/probackup --instance ent-16 \
  -b FULL

Теперь в каталоге имеются две полные копии:

student$ pg_probackup show \
  -B /var/probackup --instance ent-16
==========================================================================================
======================================================
 Instance  Version  ID      Recovery Time                  Mode  WAL Mode  TLI  Time
Data   WAL  Zalg  Zratio  Start LSN   Stop LSN    Status
==========================================================================================
======================================================
 ent-16    16       TIUPP6  2026-07-27 23:46:20.915738+03  FULL  ARCHIVE   1/0   18s
328MB  16MB  none    1,00  0/11000028  0/120000C0  OK
 ent-16    16       TIUPOG  2026-07-27 23:45:54.041458+03  FULL  STREAM    1/0   23s
328MB  16MB  none    1,00  0/E000028   0/E0001E8   OK

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

student$ sudo systemctl stop postgrespro-ent-16.service
student$ sudo rm -rf /var/lib/pgpro/ent-16/*

Восстанавливаемый экземпляр обычно запускается от имени пользователя ОС postgres, а каталог PGDATA принадлежит пользователю postgres и группе postgres. Есть два варианта задания прав на файлы каталога PGDATA: полные права только для владельца; дополнительно права на чтение и доступ в каталог для членов группы postgres. Обычно восстановление производится от имени суперпользователя ОС root с дальнейшей установкой владельца и прав на PGDATA. Восстанавливаем кластер от имени root:

student$ sudo -E /opt/pgpro/ent-16/bin/pg_probackup restore \
  -B /var/probackup --instance ent-16 \
  --allow-group-access \
  --archive-host=localhost \
  --archive-user=student

В команде использован параметр –allow-group-access, чтобы разрешить доступ к файлам от имени группы postgres. Процедура восстановления СУБД будет вызывать утилиту pg_probackup с командой archive-get для получения сегментов WAL из архива. При этом: –archive-host задает адрес сервера, откуда нужно получать эти сегменты — он подставляется в параметр –remote-host; –archive-user задает имя пользователя, от которого будет работать команда pg_probackup archive-get — оно подставляется в параметр –remote-user. Вот как выглядит сформированное значение конфигурационного параметра restore_command:

student$ sudo grep '^restore_command' /var/lib/pgpro/ent-16/postgresql.auto.conf
restore_command = '"/opt/pgpro/ent-16/bin/pg_probackup" archive-get -B "/var/probackup"
--instance "ent-16" --wal-file-path=%p --wal-file-name=%f --remote-host=localhost
--remote-user=student'

Устанавливаем владельца файлов и группу:

student$ sudo chown -R postgres:postgres /var/lib/pgpro/ent-16

Запускаем экземпляр.

student$ sudo systemctl start postgrespro-ent-16.service
student$ psql pgpro_probackup_1
=> SELECT * FROM t;
                 col1
--------------------------------------
 Перед копированием в режиме ARCHIVE.
(1 row)

Page 23: Page 23

Кластер восстановлен из самой свежей резервной копии.

Page 24: Итоги

Штатные средства резервного копирования и восстановления не всегда достаточны, pg\_probackup предоставляет дополнительные возможности

  • Утилита pg_probackup поддерживает каталог резервных копий, который может находиться на отдельном сервере
  • Для WAL возможно файловое архивирование и потоковая передача
  • Поддерживается полное и инкрементальное резервное копирование, сжатие, параллельное резервирование и восстановление

Page 25: Практика

  1. Подготовьте каталог резервных копий и зарегистрируйте в нем копируемый экземпляр для работы в удаленном режиме. 2. Настройте экземпляр на работу в режиме архивирования WAL, зарегистрируйте роль backup и создайте базу данных. 3. Выполните полное резервное копирование. 4. Измените какие-либо данные в базе и переключите сегмент WAL. Убедитесь, что сегмент попал в архив. 5. Удалите каталог данных кластера и восстановите его из резервной копии. Проверьте, восстановились ли последние изменения.

Комментарии преподавателя

  1. Создайте базу данных из шаблона templateprobackup.

  2. Убедиться, что сегмент попал в архив, можно разными способами: средствами PostgreSQL, средствами ОС или с помощью pg_probackup.

Page 26: 1. Каталог резервных копий и регистрация экземпляра

Подготавливаем каталог в файловой системе:

student$ sudo mkdir /var/probackup
student$ sudo chown student: /var/probackup

Инициализируем каталог копий:

student$ pg_probackup init \
  -B /var/probackup
INFO: Backup catalog '/var/probackup' successfully initialized

Регистрируем экземпляр:

student$ pg_probackup add-instance \
  -B /var/probackup --instance ent-16 \
  -D /var/lib/pgpro/ent-16 \
  --log-level-console=ERROR \
  --remote-host=localhost \
  --remote-user=postgres

2. Настройка архивирования WAL, роль и база данных

student$ psql

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

=> ALTER SYSTEM SET archive_mode = on;
ALTER SYSTEM
=> ALTER SYSTEM SET archive_command =
'pg_probackup archive-push'
' -B /var/probackup'
' --instance=ent-16'
' --wal-file-path=%p'
' --wal-file-name=%f'
' --remote-host=localhost'
' --remote-user=student';
ALTER SYSTEM

Перезапуск экземпляра.

student$ sudo systemctl restart postgrespro-ent-16.service
student$ psql

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

=> CREATE DATABASE pgpro_probackup_1 OWNER backup TEMPLATE templateprobackup;
CREATE DATABASE
=> \c pgpro_probackup_1
You are now connected to database "pgpro_probackup_1" as user "student".

Запишем в конфигурацию настройку для выполнения резервной копии от имени пользователя backup:

student$ pg_probackup set-config \
  -B /var/probackup --instance ent-16 \
  -d pgpro_probackup_1 \
  -U backup

3. Полная копия

Полное копирование в режиме архивирования WAL:

student$ pg_probackup backup \
  -B /var/probackup --instance ent-16 \
  -b FULL

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

Page 27: Page 27

student$ pg_probackup show \
  -B /var/probackup --instance ent-16
==========================================================================================
====================================================
 Instance  Version  ID      Recovery Time                  Mode  WAL Mode  TLI  Time
Data   WAL  Zalg  Zratio  Start LSN  Stop LSN   Status
==========================================================================================
====================================================
 ent-16    16       TIUR4H  2026-07-28 00:17:11.878560+03  FULL  ARCHIVE   1/0   23s
328MB  16MB  none    1,00  0/C000028  0/D001700  OK

4. Изменение данных и переключение сегмента WAL

Изменяем данные.

=> CREATE TABLE t AS SELECT 'Привет!' hi;
SELECT 1

Переключаем сегмент WAL.

=> SELECT pg_switch_wal();
 pg_switch_wal
---------------
 0/E00FAD4
(1 row)

Увеличим счетчик транзакций, чтобы сегмент оказался в архиве.

=> SELECT pg_current_xact_id();
 pg_current_xact_id
--------------------
                964
(1 row)

Какой последний сегмент WAL был архивирован?

=> SELECT * FROM pg_ls_archive_statusdir() ORDER BY 3,1;
                     name                      | size |      modification
-----------------------------------------------+------+------------------------
 00000001000000000000000C.done                 |    0 | 2026-07-28 00:17:09+03
 00000001000000000000000C.00000028.backup.done |    0 | 2026-07-28 00:17:11+03
 00000001000000000000000D.done                 |    0 | 2026-07-28 00:17:11+03
 00000001000000000000000E.done                 |    0 | 2026-07-28 00:17:28+03
(4 rows)

Проверка в ОС:

student$ ls -R /var/probackup/wal
/var/probackup/wal:
ent-16
/var/probackup/wal/ent-16:
00000001000000000000000B
00000001000000000000000C
00000001000000000000000C.00000028.backup
00000001000000000000000D
00000001000000000000000E

Проверка средствами pg_probackup:

student$ pg_probackup show \
  -B /var/probackup \
  --archive
ARCHIVE INSTANCE 'ent-16'
==========================================================================================
=====================================
 TLI  Parent TLI  Switchpoint  Min Segno                 Max Segno                 N
segments  Size  Zratio  N backups  Status
==========================================================================================
=====================================
 1    0           0/0          00000001000000000000000B  00000001000000000000000E  4

Page 28: 5. Восстановление из резервной копии

     64MB  1,00    1          OK

Останавливаем экземпляр.

student$ sudo systemctl stop postgrespro-ent-16.service

Удаляем содержимое PGDATA:

student$ sudo rm -rf /var/lib/pgpro/ent-16/*

Восстанавливаем с правами root:

student$ sudo -E /opt/pgpro/ent-16/bin/pg_probackup restore \
  -B /var/probackup --instance ent-16 \
  --allow-group-access \
  --archive-host=localhost \
  --archive-user=student

Меняем владельца и группу:

student$ sudo chown -R postgres:postgres /var/lib/pgpro/ent-16

Устанавливаем для группы права на чтение и доступ к каталогам; это требуется для потоковой передачи WAL.

student$ sudo chmod -R g+rX /var/lib/pgpro/ent-16
student$ sudo ls -l /var/lib/pgpro/ent-16
total 148
-rw-r-----  1 postgres postgres   240 июл 28 00:17 backup_label
drwxr-x--- 10 postgres postgres  4096 июл 28 00:17 base
drwxr-x---  2 postgres postgres  4096 июл 28 00:17 conf.d
drwxr-x---  2 postgres postgres  4096 июл 28 00:17 crash_info
-rw-r-----  1 postgres postgres    88 июл 28 00:17 current_logfiles
drwxr-x---  2 postgres postgres  4096 июл 28 00:17 global
drwxr-x---  2 postgres postgres  4096 июл 28 00:17 log
drwxr-x---  2 postgres postgres  4096 июл 28 00:17 pg_commit_ts
drwxr-x---  2 postgres postgres  4096 июл 28 00:17 pg_dynshmem
-rw-r-----  1 postgres postgres  5780 июл 28 00:17 pg_hba.conf
drwxr-x---  2 postgres postgres  4096 июл 28 00:17 pg_hba.conf.d
-rw-r-----  1 postgres postgres  2640 июл 28 00:17 pg_ident.conf
drwxr-x---  4 postgres postgres  4096 июл 28 00:17 pg_logical
drwxr-x---  4 postgres postgres  4096 июл 28 00:17 pg_multixact
drwxr-x---  2 postgres postgres  4096 июл 28 00:17 pg_notify
drwxr-x---  2 postgres postgres  4096 июл 28 00:17 pg_replslot
drwxr-x---  2 postgres postgres  4096 июл 28 00:17 pg_serial
drwxr-x---  2 postgres postgres  4096 июл 28 00:17 pg_snapshots
drwxr-x---  2 postgres postgres  4096 июл 28 00:17 pg_stat
drwxr-x---  2 postgres postgres  4096 июл 28 00:17 pg_stat_tmp
drwxr-x---  2 postgres postgres  4096 июл 28 00:17 pg_subtrans
drwxr-x---  2 postgres postgres  4096 июл 28 00:17 pg_tblspc
drwxr-x---  2 postgres postgres  4096 июл 28 00:17 pg_twophase
-rw-r-----  1 postgres postgres     3 июл 28 00:17 PG_VERSION
drwxr-x---  3 postgres postgres  4096 июл 28 00:17 pg_wal
drwxr-x---  2 postgres postgres  4096 июл 28 00:17 pg_xact
-rw-r-----  1 postgres postgres   654 июл 28 00:17 postgresql.auto.conf
-rw-r-----  1 postgres postgres 35982 июл 28 00:17 postgresql.conf
-rw-r-----  1 postgres postgres     0 июл 28 00:17 recovery.signal

Запускаем экземпляр.

student$ sudo systemctl start postgrespro-ent-16.service
student$ psql pgpro_probackup_1
=> SELECT * FROM t;
   hi
---------
 Привет!
(1 row)

Данные восстановлены, включая записи из архивированных сегментов WAL.

Уборка

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

Page 29: Page 29

=> \c student
You are now connected to database "student" as user "student".
=> DROP DATABASE pgpro_probackup_1 WITH (FORCE);
DROP DATABASE
student$ sudo rm -rf /var/probackup
=> ALTER SYSTEM RESET ALL;
ALTER SYSTEM
student$ sudo systemctl restart postgrespro-ent-16.service

Page 30: Практика PPEM

  1. Создайте локальное хранилище резервных копий для экземпляра ent-16. Назовите его ent-16_local, а каталог данных разместите в /var/lib/pgpro/pg_probackup.
    1. Сделайте автономную резервную копию основного экземпляра в созданное в п. 1 хранилище. Копия должна быть максимально сжата алгоритмом lz4 и включать журнал сообщений сервера. 3. Сделайте еще одну копию экземпляра, но уже без сжатия. Сравните размер полученной копии с полученной в п. 2 и оцените выигрыш от сжатия. 4. Создайте новый экземпляр ent-16-restored из резервной копии п. 3 в каталоге /var/lib/pgpro/ent-16-restored и запустите его.

Комментарии преподавателя

  1. Выбор алгоритма будет доступен после установки уровня сжатия копии.

Page 31: 1. Создание локального хранилища копий

В навигационной панели выберите вкладку «Резервное копирование», в ней — «Хранилища РК» и нажмите «Добавить хранилище». Выберите локальный тип хранилища, заполните поля открывшейся формы и нажмите «Добавить».

2. Автономная резервная копия со сжатием

Выберите вкладку «Резервные копии» и нажмите кнопку «Создать резервную копию». Далее в последовательно открывающихся формах заполните необходимые поля и нажмите «Выполнить РК».

3. Автономная резервная копия без сжатия

Действуйте так же, как в предыдущем пункте задания, но не включайте сжатие. Размеры копий указаны в первом столбце списка.

4. Создание нового экземпляра из резервной копии

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