Обеспечение сохранности данных — одна из ключевых задач системного администратора и специалиста 1С. При работе с СУБД PostgreSQL часто возникает дилемма: какой инструмент резервного копирования использовать, чтобы не перегружать сервер, не терять транзакции в случае сбоя и иметь возможность быстро развернуть копию? Особенно остро этот вопрос встает, когда резервную копию необходимо делать несколько раз в день.
В этой статье мы подробно разберем, как организовать надежное архивирование баз данных 1С на PostgreSQL, проанализируем разницу между логическими и физическими бэкапами, рассмотрим сильные и слабые стороны утилиты pg_basebackup и технологии непрерывного архивирования WAL (Point-in-Time Recovery), а также решим проблему резервного копирования нескольких баз в одном кластере.
Прежде чем перейти к конкретным инструментам, разберем базовое различие в подходах к резервному копированию СУБД PostgreSQL:
Утилита pg_basebackup предназначена для создания базовой физической копии работающего кластера PostgreSQL. Она подключается к серверу по протоколу репликации, поэтому для ее работы в файле конфигурации pg_hba.conf должно быть разрешено подключение для репликации, а в postgresql.conf настроен параметр max_wal_senders.
Рассмотрим стандартный пример вызова утилиты:
pg_basebackup -x -h db01.example.com -U backup -D /backup
Проанализируем параметры этой команды:
-h db01.example.com — адрес хоста СУБД.-U backup — имя пользователя, под которым выполняется резервное копирование (у него должны быть права суперпользователя или права на репликацию).-D /backup — директория, куда будет записана копия.-x (или аналогичный современный флаг -X fetch) — указывает утилите забрать все необходимые файлы WAL (журнала предзаписи), созданные во время бэкапа, чтобы копия получилась согласованной и готовой к запуску.Если бэкап выполняется на высоконагруженном сервере, процесс резервного копирования может забрать всю пропускную способность дисков. Чтобы избежать зависания рабочих сессий 1С, оптимизируем команду с помощью утилиты ограничения приоритета ввода-вывода ionice и включим сжатие "на лету" с помощью флага -z:
ionice -c 3 pg_basebackup -X stream -z -Z 5 -h db01.example.com -U backup -D /backup/daily_backup
Здесь параметр ionice -c 3 запускает процесс в классе "idle" (только когда дисковая подсистема простаивает), флаг -X stream обеспечивает непрерывную передачу WAL-файлов параллельно основному копированию, а -z -Z 5 сжимает архив алгоритмом gzip с уровнем сжатия 5.
Минус подхода: Если делать такой бэкап 5 раз в день, это приведет к созданию пяти полных копий всей базы данных ежедневно. Для базы объемом 500 ГБ это потребует 2.5 ТБ дискового пространства в день, что экономически нецелесообразно.
Чтобы решить проблему избыточного использования дисков и минимизировать риск потери данных (минимизировать RPO — Recovery Point Objective), настроим непрерывное архивирование журналов предзаписи (WAL-файлов). Этот метод рекомендован методистами 1С.
Идея заключается в следующем: мы делаем полную физическую копию базы (например, с помощью той же pg_basebackup) всего один раз в неделю (или раз в сутки ночью). А все изменения, которые происходят в базе в течение дня, непрерывно записываются в маленькие файлы транзакций (WAL-сегменты по 16 МБ каждый) и сразу же копируются в защищенное хранилище.
Выясним, как активировать этот режим. Для этого отредактируем конфигурационный файл СУБД postgresql.conf:
# Включаем режим архивирования
wal_level = replica
archive_mode = on
# Задаем команду копирования заполненных WAL-сегментов
archive_command = 'test ! -f /mnt/backup/wal_archive/%f && cp %p /mnt/backup/wal_archive/%f'
Разберем параметры макросов в archive_command:
%p — путь к копируемому WAL-файлу на сервере.%f — только имя этого WAL-файла.Команда test ! -f проверяет, нет ли уже файла с таким именем в архиве, защищая существующие архивы от случайного перезаписывания.
При таком подходе при аварии сервера мы берем последний базовый бэкап и последовательно накатываем на него цепочку WAL-файлов до секунды сбоя. Мы можем восстановиться на любой момент времени в прошлом (метод PITR — Point-in-Time Recovery).
Часто на одном сервере PostgreSQL крутится несколько баз данных 1С (например, рабочая, тестовая, база бухгалтерии и управления торговлей). Системные администраторы часто задаются вопросом: как настроить параметр archive_command отдельно для каждой базы?
Важное правило PostgreSQL: Параметр archive_command настраивается для всего кластера (экземпляра СУБД) целиком, а не для конкретных баз данных. Все изменения во всех базах внутри одного кластера пишутся в общий поток WAL-файлов. Разделить их стандартными средствами на этапе архивирования транзакций невозможно.
Если вам критически важно архивировать базы независимо друг от друга физическими методами, необходимо разносить их по разным кластерам PostgreSQL (запускать разные службы на разных портах). Если же они остаются в одном кластере, но вам нужно гибко управлять логированием или раскладывать файлы по разным каталогам на основе скрипта, пропишем в archive_command запуск внешнего shell-скрипта:
archive_command = '/var/lib/postgresql/scripts/wal_archive.sh %p %f'
А сам скрипт wal_archive.sh реализуем следующим образом:
#!/bin/bash
# Скрипт архивирования WAL с ведением лога
WAL_PATH="$1"
WAL_NAME="$2"
DEST_DIR="/mnt/backup/wal_archive"
if [ ! -d "$DEST_DIR" ]; then
mkdir -p "$DEST_DIR"
fi
cp "$WAL_PATH" "$DEST_DIR/$WAL_NAME"
if [ $? -eq 0 ]; then
echo "$(date '+%Y-%m-%d %H:%M:%S') - Успешно скопирован файл $WAL_NAME" >> /var/log/postgresql/archive.log
exit 0
else
echo "$(date '+%Y-%m-%d %H:%M:%S') - Ошибка копирования файла $WAL_NAME" >> /var/log/postgresql/archive.log
exit 1
fi
В реальной практике крупных внедрений 1С писать самописные bash-скрипты для управления архивами уже не принято. Стандартом индустрии стал профессиональный менеджер резервного копирования pgBackRest.
Рассмотрим, почему для баз 1С выбирают именно его:
archive_command и следит за тем, чтобы все нужные транзакции попали в архив, а старые автоматически удалялись по настроенной политике хранения (Retention policy).Пример простой конфигурации секции архивирования в pgbackrest.conf:
[demo]
pg1-path=/var/lib/postgresql/15/main
[global]
repo1-path=/mnt/backup/pgbackrest
repo1-retention-full=2
process-max=4
log-level-console=info
log-level-file=detail
start-fast=y
compress-type=lz4
Параметр process-max=4 задействует 4 ядра процессора для параллельного сжатия алгоритмом lz4, что минимизирует время создания копии базы 1С.
Базы данных 1С Предприятия характеризуются высокой интенсивностью модификации данных (создание, проведение документов, перезапись регистров). Это приводит к быстрому накоплению "мусора" (устаревших версий строк) в таблицах PostgreSQL.
Перед запуском процесса создания бэкапа (особенно если вы используете логический бэкап) крайне рекомендуется настроить регламентное обслуживание:
ANALYZE для актуализации статистики оптимизатора запросов.VACUUM (или автоматический контроль работы процесса autovacuum) для очистки страниц данных от удаленных строк. Это позволит уменьшить итоговый размер файла бэкапа и ускорит процесс резервного копирования.Главное правило любого системного администратора: бэкап считается существующим только тогда, когда он успешно восстановлен на тестовом сервере.
Рекомендуем автоматизировать этот процесс. Напишем скрипт, который раз в неделю будет выполнять следующие шаги:
v8users).Только при наличии такого контура тестирования бэкапов вы сможете гарантировать бесперебойную работу критически важной для бизнеса системы 1С.