При работе с базами данных 1С, особенно при переходе с MSSQL на PostgreSQL, одним из критически важных аспектов является обеспечение надежного и гибкого резервного копирования. Пользователи, привыкшие к возможности восстановления базы данных на любой момент времени с помощью резервного копирования журналов транзакций в MSSQL, сталкиваются с вопросом: как достичь аналогичной функциональности в PostgreSQL? На форуме 1С-Предприятия системные администраторы активно обсуждали эту задачу, стремясь понять, как вернуть базу данных в состояние, предшествующее сбою, с минимальной потерей данных. Например, если ежедневный бэкап сделан в час ночи, а база "слетела" в 15:00, возникает потребность восстановить её в состояние 14:59. Мы рассмотрим, как это реализовать в PostgreSQL с помощью механизма непрерывного архивирования WAL-файлов, что позволяет выполнить восстановление на любой момент времени (Point-in-Time Recovery, PITR).
В отличие от MSSQL, где резервное копирование журналов транзакций может выполняться для каждой отдельной базы данных, в PostgreSQL архивирование журналов изменений (WAL-файлов, Write-Ahead Log) реализуется на уровне всего кластера баз данных. Это означает, что все базы, находящиеся в одном кластере PostgreSQL (то есть, использующие одну и ту же директорию data), будут восстанавливаться до одного и того же момента времени. Это важное концептуальное отличие, которое необходимо учитывать при планировании архитектуры и стратегии восстановления.
Суть механизма PITR в PostgreSQL заключается в следующем:
data на определенный момент времени.Мы выясним, как настроить каждый из этих этапов подробно, чтобы обеспечить максимальную надежность и гибкость восстановления вашей базы 1С.
Базовое резервное копирование является отправной точкой для любого восстановления на момент времени. Оно представляет собой полную копию всех файлов кластера PostgreSQL в определенный момент. Без актуального базового бэкапа невозможно применить WAL-файлы для восстановления, так как они содержат только инкрементальные изменения. Чем чаще мы делаем базовые бэкапы, тем меньше WAL-файлов потребуется применить при восстановлении, что ускоряет процесс и снижает риски.
Существуют несколько способов создания базового бэкапа:
pg_basebackup: Это рекомендуемый и наиболее удобный способ, поскольку pg_basebackup может создавать бэкап работающего сервера без его остановки. Утилита автоматически синхронизирует все необходимые файлы и метаданные, включая информацию о точке начала архивирования WAL-файлов. Это позволяет минимизировать простой сервера и обеспечить согласованность данных.data вручную: Этот метод требует полной остановки сервера PostgreSQL, чтобы гарантировать целостность копируемых данных. После остановки сервера вы можете просто скопировать весь каталог data в другое место. Этот метод менее предпочтителен для продуктивных систем, требующих высокой доступности, но может быть использован в тестовых средах или при ограниченных ресурсах.data. Этот метод также позволяет делать бэкапы работающего сервера, но требует специфической настройки файловой системы.Пример использования pg_basebackup:
Для создания базового бэкапа с помощью pg_basebackup, мы можем использовать следующую команду (выполняется на сервере, где установлен PostgreSQL, или с удаленной машины с доступом по SSH/pg_hba.conf, убедившись, что пользователь имеет необходимые права и доступ к базе данных):
pg_basebackup -h localhost -p 5432 -U postgres -D C:\Path\To\BaseBackup -F p -X stream -c fast -v -R
Давайте подробно разберем ключевые параметры этой команды:
-h localhost: Указывает хост, на котором запущен сервер PostgreSQL. Можно заменить на IP-адрес или доменное имя, если сервер удаленный.-p 5432: Определяет порт сервера PostgreSQL. Стандартный порт — 5432.-U postgres: Имя пользователя PostgreSQL, который имеет права на выполнение бэкапа (обычно это суперпользователь postgres). Убедитесь, что для этого пользователя настроена аутентификация в файле pg_hba.conf.-D C:\Path\To\BaseBackup: Задает директорию, куда будет сохранен базовый бэкап. Важно: Эта директория должна быть либо пустой, либо не существовать; pg_basebackup не будет перезаписывать непустую директорию.-F p: Определяет формат вывода как "plain" (обычные файлы). Альтернативный вариант -F t создает тар-архив. Для простоты использования и возможности просмотра файлов, "plain" формат часто предпочтительнее.-X stream: Позволяет передавать WAL-файлы в потоковом режиме во время создания базового бэкапа. Это гарантирует, что у вас будет полный набор WAL-файлов с самого начала бэкапа, что критически важно для дальнейшего PITR. WAL-файлы будут включены в подкаталог pg_wal внутри созданного бэкапа.-c fast: Заставляет PostgreSQL быстро создать контрольную точку (checkpoint) перед началом бэкапа. Это помогает обеспечить консистентность данных и ускоряет процесс бэкапа.-v: Активирует подробный вывод (verbose), который покажет прогресс выполнения операции и любые предупреждения или ошибки.-R: (Новый в PostgreSQL 9.5+) Создает файл standby.signal (ранее recovery.conf) и postgresql.auto.conf в целевой директории бэкапа. Эти файлы содержат настройки, необходимые для быстрого запуска бэкапа как ведомого сервера или для выполнения восстановления. Это очень удобно для автоматизации.Мы рекомендуем настроить выполнение pg_basebackup как часть регулярного регламентного задания, например, раз в сутки в нерабочее время, раз в неделю или с другой необходимой периодичностью, в зависимости от объема изменений в вашей базе 1С и требований к RTO/RPO (Recovery Time Objective/Recovery Point Objective) — времени и точке восстановления.
После того как мы создали базовый бэкап, нам необходимо обеспечить непрерывное архивирование WAL-файлов. Эти файлы содержат все изменения, внесенные в базу данных после последнего базового бэкапа. Архивирование WAL-файлов позволяет нам "докатить" базовый бэкап до любого, даже мельчайшего, момента времени, обеспечивая ту самую гибкость, что и журналы транзакций в MSSQL.
Для настройки архивирования нам потребуется изменить основной конфигурационный файл postgresql.conf, который обычно находится в каталоге данных вашего кластера PostgreSQL (например, C:\Program Files\PostgreSQL\14\data\postgresql.conf или /etc/postgresql/14/main/postgresql.conf для Linux).
Найдите и измените (или добавьте, если отсутствуют) следующие параметры:
wal_level: Этот параметр определяет объем информации, записываемой в WAL-файлы. Для PITR он должен быть установлен в replica (или logical, если вы используете логическую репликацию; но для простого восстановления на момент времени replica вполне достаточно).
wal_level = replica
По умолчанию в некоторых дистрибутивах или старых версиях PostgreSQL может быть установлено minimal, что недостаточно для восстановления. Изменение этого параметра требует полного перезапуска сервера PostgreSQL.
archive_mode: Этот параметр включает режим архивирования WAL-файлов.
archive_mode = on
Как и wal_level, этот параметр требует полного перезапуска сервера PostgreSQL.
archive_command: Это командная строка оболочки, которая выполняется для каждого завершенного WAL-файла. Её задача — скопировать WAL-файл из каталога pg_wal (или pg_xlog в старых версиях до PostgreSQL 10) в ваше архивное хранилище. Эта команда должна быть надежной, устойчивой к ошибкам и не должна перезаписывать уже существующие WAL-файлы в архиве. PostgreSQL ожидает, что команда вернет 0 в случае успеха; любое другое значение будет интерпретироваться как ошибка, и PostgreSQL будет повторять попытку архивации.
На форуме был предложен пример команды для Windows, который мы можем адаптировать:
archive_command = 'copy "%p" "C:\\server\\archivedir\\%f"' # Для Windows
Давайте разберем эту команду подробнее:
%p: Это переменная-заполнитель, которая заменяется полным путем к WAL-файлу, который нужно архивировать. Например: C:\Program Files\PostgreSQL\14\data\pg_wal\000000010000000A000000FF.%f: Это переменная-заполнитель, которая заменяется только именем WAL-файла. Например: 000000010000000A000000FF."C:\\server\\archivedir\\": Это путь к директории, куда будут сохраняться архивированные WAL-файлы. Критически важно: этот каталог должен находиться на отдельном физическом диске или, что еще лучше, на сетевом хранилище, отличном от того, где находится сам кластер PostgreSQL. Это обеспечивает защиту вашего архива от потери данных в случае сбоя основного диска сервера.Если вы используете операционную систему Linux, аналогичная команда с использованием утилиты cp будет выглядеть так:
archive_command = 'cp %p /path/to/wal_archive/%f' # Для Linux
Важно: Убедитесь, что пользователь операционной системы, под которым запущен процесс PostgreSQL (например, postgres в Linux или NETWORK SERVICE/специальный пользователь в Windows), имеет полные права на чтение и запись в указанную директорию архива WAL-файлов. Отсутствие прав приведет к сбоям архивирования и невозможности PITR.
archive_timeout (необязательно, но полезно): Этот параметр определяет, как часто PostgreSQL будет принудительно переключать WAL-файл (даже если он не заполнен) и отправлять его в архив. Это очень полезно для сокращения потенциальной потери данных в случае сбоя, так как гарантирует, что WAL-файлы будут архивироваться чаще, чем по умолчанию (когда они полностью заполнятся).
archive_timeout = 300 # Архивация каждые 5 минут, если нет активности
Это значение измеряется в секундах. Мы рекомендуем устанавливать его в разумных пределах, например, от 60 до 300 секунд (1-5 минут), чтобы обеспечить актуальность архива без создания чрезмерного количества маленьких WAL-файлов, что может негативно сказаться на производительности файловой системы. Для баз 1С с высокой активностью это позволяет минимизировать окно потери данных.
После внесения всех необходимых изменений в postgresql.conf, не забудьте выполнить полный перезапуск сервера PostgreSQL, чтобы эти новые настройки вступили в силу. После перезапуска сервер начнет архивировать WAL-файлы в указанную вами директорию. Вы можете проверить логи сервера на предмет сообщений об успешном архивировании.
Архивирование WAL-файлов является достаточно легковесным процессом, поскольку оно просто копирует уже записанные на диск файлы. Это значительно отличается от создания полного бэкапа всей базы данных каждые 15 минут, что, как верно заметили пользователи форума, может быть очень ресурсоемким и создавать значительную нагрузку для больших баз данных (10-12 ГБ и более), влияя на производительность работы 1С-Предприятия.
Теперь, когда у нас есть актуальный базовый бэкап и непрерывный архив WAL-файлов, мы полностью готовы к восстановлению базы данных на любой необходимый момент времени. Мы рассмотрим пошаговый процесс восстановления, который позволит вам вернуть базу 1С в желаемое состояние.
Важное замечание, подтвержденное на форуме: PITR в PostgreSQL восстанавливает весь кластер, а не отдельную базу данных. Если в вашем кластере PostgreSQL размещено несколько баз 1С (или других приложений), все они будут восстановлены до указанного вами момента времени. Это означает, что если вам нужно восстановить только одну базу из нескольких, вам, возможно, придется использовать другую стратегию (например, восстановление кластера в отдельное место и последующий экспорт/импорт нужной базы), но для комплексного восстановления кластера этот метод наиболее эффективен.
Последовательность действий для восстановления:
data (например, C:\Program Files\PostgreSQL\14\data или /var/lib/postgresql/14/main) в безопасное место, если вы хотите сохранить его для дальнейшего анализа или устранения неполадок. Не просто очищайте его, а перемещайте или удаляйте полностью, чтобы избежать конфликтов.pg_basebackup или вручную) в целевой, пустой каталог данных. Важно: Скопируйте именно содержимое базового бэкапа (то есть, все файлы и подкаталоги, которые были внутри директории, куда pg_basebackup сохранил данные), а не саму директорию бэкапа с вложенной в неё директорией data.
# Пример для Windows, если базовый бэкап находится в C:\Path\To\BaseBackup
# Убедитесь, что целевая директория (C:\Program Files\PostgreSQL\14\data\) пуста.
xcopy C:\Path\To\BaseBackup\* C:\Program Files\PostgreSQL\14\data\ /E /I /H /Y
Параметры /E /I /H /Y обеспечивают копирование всех подкаталогов, обрабатывают целевую директорию как имя, копируют скрытые и системные файлы, и подавляют запрос подтверждения перезаписи.
После копирования в целевой директории data должен находиться полный набор файлов и подкаталогов, как если бы это был свежий кластер PostgreSQL.
recovery.signal и настройте параметры восстановления: В корневом каталоге данных (например, C:\Program Files\PostgreSQL\14\data) необходимо создать пустой файл с именем recovery.signal. Для версий PostgreSQL до 12-й вместо recovery.signal использовался файл recovery.conf, который содержал параметры восстановления. В современных версиях PostgreSQL параметры восстановления указываются либо непосредственно в файле postgresql.conf, либо в файле postgresql.auto.conf (который автоматически применяется). Мы можем использовать postgresql.auto.conf для временной настройки параметров восстановления, которые будут удалены после успешного восстановления, или же временно изменить postgresql.conf.
Предположим, мы добавляем параметры в postgresql.auto.conf (или непосредственно в postgresql.conf):
# В файле postgresql.auto.conf (или временно в postgresql.conf)
restore_command = 'copy "C:\\server\\archivedir\\%f" "%p"' # Команда для получения WAL-файлов из архива
recovery_target_time = '2023-10-26 14:59:00 MSK' # Желаемый момент времени для восстановления
# recovery_target_xid = '12345' # Альтернативно, восстановление по ID транзакции
# recovery_target_name = 'my_recovery_point' # Альтернативно, восстановление по имени точки восстановления
# recovery_target_inclusive = on # Включить или исключить цель восстановления (по умолчанию on)
recovery_target_action = 'pause' # Что делать после достижения цели: pause, shutdown, promote
Давайте подробно рассмотрим эти критически важные параметры:
restore_command: Эта команда используется PostgreSQL для получения необходимых WAL-файлов из вашего архива. Она должна быть обратной к archive_command. %f будет заменяться именем WAL-файла, который требуется (например, 000000010000000A000000FF), а %p — полным путем, куда его нужно скопировать (например, C:\Program Files\PostgreSQL\14\data\pg_wal\000000010000000A000000FF). Убедитесь, что путь к архиву C:\\server\\archivedir\\ (или /path/to/wal_archive/) указан правильно и у пользователя PostgreSQL есть права на чтение из этого архива и запись в pg_wal.recovery_target_time: Это самый распространенный и гибкий способ указания цели восстановления. Вы указываете точную дату и время, до которой нужно восстановить базу. Используйте формат 'YYYY-MM-DD HH:MM:SS [TZ]', где [TZ] – это необязательное указание временной зоны. Например, '2023-10-26 14:59:00 MSK'. PostgreSQL восстановит базу до состояния, непосредственно предшествующего указанному времени.recovery_target_action = 'pause': Этот параметр определяет, что PostgreSQL должен сделать после достижения указанного момента времени.
pause: Сервер приостановит процесс восстановления. Это позволит вам подключиться к базе данных в режиме только для чтения, выполнить проверку данных и убедиться, что восстановление прошло успешно. После проверки вы можете вручную "продвинуть" сервер в обычный режим работы командой SELECT pg_wal_replay_resume(); или остановить его.shutdown: Сервер полностью остановится после достижения цели восстановления. Это безопасный вариант, если вы не планируете дальнейших действий сразу после восстановления.promote: Сервер автоматически перейдет в обычный режим работы как мастер-сервер после достижения цели. Используйте этот вариант с осторожностью и только если вы абсолютно уверены в корректности восстановления, так как это может привести к нежелательным изменениям данных, если восстановление оказалось неверным.pause или shutdown, чтобы иметь возможность проверить целостность данных перед началом активной работы.recovery.signal и автоматически перейдет в режим восстановления. Он начнет применять WAL-файлы из вашего архива, докатывая базовый бэкап до указанного recovery_target_time. Вы увидите подробные сообщения в логах PostgreSQL о процессе восстановления, включая имена применяемых WAL-файлов.recovery_target_action = 'pause') и завершите процесс: Если вы использовали recovery_target_action = 'pause', сервер будет ожидать ваших действий после достижения цели. Вы можете подключиться к базе данных (она будет работать в режиме только для чтения) и проверить её состояние. Если все в порядке, вы можете "продвинуть" сервер, чтобы он начал работать как обычный мастер:
SELECT pg_wal_replay_resume();
После этого сервер PostgreSQL перейдет в обычный режим работы, и файл recovery.signal будет автоматически удален (или переименован) сервером. Если вы использовали postgresql.auto.conf для параметров восстановления, его следует удалить или закомментировать эти параметры после успешного восстановления, чтобы избежать случайного запуска восстановления в будущем. Если вы изменяли postgresql.conf, верните его к исходному состоянию.Для обеспечения максимальной надежности и эффективности вашей системы резервного копирования и восстановления мы предлагаем следующие рекомендации:
archive_command успешно выполняется и что WAL-файлы постоянно попадают в архив. Любой сбой в этом процессе (например, из-за нехватки места на диске архива или проблем с правами доступа) может привести к потере возможности PITR.pg_wal, что может вызвать проблемы с производительностью или даже остановку сервера при заполнении диска.SQL-сервер повис, пришлось перезагружать и удалять все базы из списка баз сервера 1С-Предприятия и заново их добавлять). Убедитесь, что все службы 1С корректно взаимодействуют с восстановленной базой.Таким образом, мы видим, что PostgreSQL предоставляет мощный и гибкий механизм для восстановления на любой момент времени, аналогичный функциональности журналов транзакций в MSSQL. Правильная настройка и регулярное тестирование позволят вам быть уверенными в сохранности данных вашей базы 1С и готовности к любым нештатным ситуациям.