Как организовать восстановление отдельных баз PostgreSQL на нужный момент времени (PITR) при использовании pg_probackup

В работе системного администратора 1С часто возникает ситуация, когда в одном кластере PostgreSQL находятся несколько высоконагруженных баз (например, ERP и Документооборот). Использование утилиты pg_probackup позволяет создавать надежные физические бэкапы всего кластера, однако стандартный механизм восстановления подразумевает развертывание всего кластера целиком. Рассмотрим, как решить задачу восстановления только одной конкретной базы на определенную точку во времени (Point-in-Time Recovery — PITR), не затрагивая остальные работающие базы.

Проблема общего журнала транзакций (WAL)

Для начала проанализируем ситуацию: в PostgreSQL понятие «кластер» (экземпляр) означает запущенный процесс СУБД, который управляет набором баз данных. Все базы внутри одного кластера используют общий журнал транзакций (WAL). Именно поэтому физическое восстановление на момент времени (PITR) технически сложно выполнить для одной базы внутри «живого» кластера — журналы содержат перемешанные записи всех транзакций всех баз.

Способ 1. Частичное восстановление с использованием параметров pg_probackup

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

pg_probackup restore -B /path/to/backup_dir \
--instance my_instance \
--db-include=my_target_db \
--recovery-target-time='2023-10-27 17:20:00' \
-D /path/to/new_data_directory

При выполнении этой команды мы должны учитывать несколько важных моментов:

1. Новый каталог данных: Восстановление невозможно выполнить в ту же папку, где работает текущий сервер. Мы указываем пустой каталог через флаг -D.
2. Фильтрация WAL: Параметр --db-include заставляет утилиту копировать только файлы выбранной базы и необходимые системные таблицы. Однако процесс PITR все равно потребует проигрывания журналов транзакций, чтобы довести базу до нужного состояния.
3. Запуск временного инстанса: После восстановления в новый каталог, нам необходимо запустить второй экземпляр PostgreSQL на другом порту (например, 5433), сделать pg_dump нужной базы и загрузить её в основной кластер.

Способ 2. Архитектура «Один кластер — одна база» (Multi-instance)

Выясним, является ли правильным запуск нескольких экземпляров PostgreSQL на одном сервере. На практике для крупных внедрений 1С (ERP, Управление холдингом) это часто считается лучшей практикой. Разделив базы по разным кластерам, мы получаем полную изоляцию ресурсов и журналов транзакций.

Разберем по шагам, как настроить второй инстанс в Linux (Debian):

1. Создаем новый каталог данных для второй службы: mkdir /var/lib/postgresql/12/erp_cluster.
2. Инициализируем базу: sudo -u postgres pg_ctlinitdb -D /var/lib/postgresql/12/erp_cluster.
3. В файле postgresql.conf нового кластера меняем порт: port = 5433.
4. Настраиваем shared_buffers и другие параметры памяти под конкретную задачу базы.
5. В консоли администрирования 1С при создании/подключении базы указываем порт 5433.

Преимущества такого подхода:

• Каждая база имеет свой поток WAL.
• pg_probackup настраивается для каждого инстанса отдельно.
• Восстановление одной базы на момент времени (PITR) происходит штатно, не затрагивая работу других баз на портах 5432, 5434 и т.д.

Способ 3. Восстановление через промежуточный сервер

Если разделение на разные инстансы сейчас невозможно, проанализируем сценарий «аварийного восстановления» через промежуточный сервер или временную директорию. Этот метод позволяет не перегружать основной сервер в процессе восстановления.

Рассмотрим алгоритм действий:

1. Выполняем полное или частичное (через --db-include) восстановление бэкапа на свободное место на диске.
2. Используем механизм Delta Restore (если он поддерживается вашей версией), чтобы ускорить процесс за счет копирования только изменившихся блоков.
3. Запускаем временный сервер PostgreSQL.
4. Выгружаем базу в логический бэкап: pg_dump -p 5433 -d target_db -F c -f /tmp/target_db_pitr.backup
5. Удаляем поврежденную базу в основном кластере и восстанавливаем её из дампа: pg_restore -p 5432 -d target_db /tmp/target_db_pitr.backup

Сравнение инструментов: pg_probackup vs pgBackRest

Посмотрим на ситуацию шире. Если требования к восстановлению отдельных баз критичны, стоит рассмотреть утилиту pgBackRest. Она считается «золотым стандартом» для работы с большими объемами данных в PostgreSQL.

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

Рекомендации по настройке стратегии бэкапа

Проанализировав все варианты, сформируем оптимальную стратегию для системного администратора 1С:

1. Комбинируйте методы: Используйте pg_probackup для ежедневных полных копий и хранения WAL (для PITR). Параллельно делайте pg_dump наиболее важных баз раз в сутки (например, в обед), чтобы иметь возможность быстро «откатить» мелкие ошибки пользователей без запуска процедуры физического восстановления.

2. Изолируйте ERP: Для критически важных баз ERP, где простой стоит очень дорого, выделите отдельный инстанс PostgreSQL. Это упростит жизнь при необходимости восстановления «на 15 минут назад».

3. Проверяйте бэкапы: Регулярно проводите тестовое восстановление. Помните, что наличие файлов бэкапа не гарантирует успешность восстановления, пока вы не проверили это на практике.

Для автоматизации создания бэкапов через pg_dump в Linux можно использовать простой скрипт в cron:

#!/bin/bash
DATE=$(date +%Y-%m-%d_%H-%M)
PGPASSWORD="ваш_пароль" pg_dump -U postgres -h localhost -p 5432 -F c my_database > /backup/1c/my_db_$DATE.backup

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