Настройка Point In Time Recovery в PostgreSQL PRO 16 на Ubuntu 24.04

Point In Time Recovery (PITR) – это метод восстановления базы данных до состояния, в котором она находилась в определенный момент времени. Эта технология особенно полезна в случае ошибок, сбоев или повреждений данных. С помощью PITR можно восстановить базу данных до конкретного времени, минуя нежелательные изменения или ошибки.

Настройка PITR в PostgreSQL

1. Установим БД. Я буду использовать версию для 1C, но в разных редакциях 16 версии суть не меняется.

   wget https://repo.postgrespro.ru/1c/1c-16/keys/pgpro-repo-add.sh
   sh pgpro-repo-add.sh
   apt-get install postgrespro-1c-16
   systemctl status postgrespro-1c-16.service

2. Настройка архивации журналов. На этом этапе требуется архивировать WAL файлы в папку, чтобы с помощью этих же файлов восстановить postgres. mkdir -p /backups/wals/ # Папка для бэкапов WAL файлов nano /var/lib/pgpro/1c-16/data/postgresql.conf # Путь до postgresql.conf. В зависимости от редакции путь может отличаться. Редактируем/раскомментируем следующие строки:

   wal_level = replica
   archive_mode = on
   archive_command = 'gzip < %p > /backups/wals/%f.gz'
   archive_timeout = 60 
   restore_command = 'gunzip < /backups/wals/%f.gz > %p'
   checkpoint_timeout = 5m
   max_wal_size = 1GB
   min_wal_size = 80MB
   max_wal_senders = 3

Разберем каждый параметр более подробно:

wal_level = replica

• minimal: Минимальный объем данных, необходимый для восстановления.
• replica: Дополнительные данные, необходимые для репликации и PITR.
• logical: Максимальный объем данных, включая поддержку логической репликации.

archive_mode = on

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

archive_command = 'gzip < %p > /backups/wals/%f.gz'

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

• %p: Полный путь к исходному файлу WAL.
• %f: Имя файла WAL.

Здесь я использую архивацию WAL файлов для экономии места.

archive_timeout = 60

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

restore_command = 'gunzip < /backups/wals/%f.gz > %p'

checkpoint_timeout = 5m

max_wal_size = 1GB
min_wal_size = 80MB

max_wal_senders = 3

3. Перезапускаем postgres для сохранения изменений. systemctl restart postgrespro-1c-16.service
4. Создаем бэкап postgres.

mkdir -p /backups/base/ # Папка для бэкапов базы
sudo -u postgres pg_basebackup -D /backups/base/$(date +'%Y-%m-%d_%H-%M-%S') -Ft -z -P -X stream

Для чего же мы делаем бэкапы?

PITR работает не по принципу отказа назад, а по принципу записи данных до определенного момента. Если более простыми словами – бэкап является Вашей контрольной точкой, а WAL файлы являются изменениями, которые Вы вносили на протяжении времени. От контрольной точки будет произведена запись Ваших изменений до момента, который Вы указали, то есть до конечной контрольной точки. Лучше всего настроить скрипт и делать бэкапы хотя бы раз в сутки.

Фактически, настройка PITR завершена. Проверьте, чтобы создавались архивы с wal файлами в Вашей папке. Разберем процесс восстановления. Предположим, что Вы внесли какие-то данные, потом уронили базу и тут же поняли, что нужно вернуться минут на 5 назад, чтобы все работало.

1. Останавливаем службу postgres

   systemctl stop postgrespro-1c-16.service

2. Копируем wal файлы, которые могли не успеть перекинуться в папку

   mkdir -p /backups/temp_wal/ 
   cp /var/lib/pgpro/1c-16/data/pg_wal/* /backups/temp_wal/

3. Удаляем все из папки /var/lib/pgpro/1c-16/data и распаковываем самый свежий бэкап из папки /backups/base/ (или в которую вы создавали бэкапы)

   rm -rf /var/lib/pgpro/1c-16/data/*

4. Восстанавливаем базу данных в /var/lib/pgpro/1c-16/data/

   tar xfv /backups/base/date/base.tar.gz -C /var/lib/pgpro/1c-16/data/ - (date - изменить на дату)

5. Восстанавливаем wal файлы, меняем владельца на postgres

   cp /backups/temp_wal/* /var/lib/pgpro/1c-16/data/pg_wal/
   chown postgres:postgres /var/lib/pgpro/1c-16/data/pg_wal/*

6. В /var/lib/pgpro/1c-16/data/postgresql.conf требуется раскомментировать строку recovery_target_time. Мы будем производить восстановление по времени, но есть и другие способы:

   nano /var/lib/pgpro/1c-16/data/postgresql.conf
   recovery_target_time = '2024-07-15 12:00:00' # Указываем время, до которого стоит откатить

7. Требуется создать файл recovery.signal и выдать права на файл пользователю postgres

   touch /var/lib/pgpro/1c-16/data/recovery.signal
   chown postgres:postgres /var/lib/pgpro/1c-16/data/recovery.signal

8. Запустить postgrespro

   systemctl start postgrespro-1c-16.service

9. Дождаться окончания восстановления. Информацию о восстановлении можно увидеть в папке data/logs/
10. Удалить файл recovery.signal

    rm -f /var/lib/pgpro/1c-16/data/recovery.signal

11. Перезапустить postgres

    systemctl restart postgrespro-1c-16.service

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