Восстановление базы 1С из pg_probackup после сбоя PostgreSQL

Сервер 1С не запускается, копия лежит в каталоге pg_probackup, но восстановление останавливается на проверке совместимости. Не продолжайте работу с исходным PGDATA. Сохраните его, каталог резервных копий и архив WAL, а затем разворачивайте PostgreSQL отдельно.

Цель — выбрать пригодную цепочку копий, вернуть кластер к нужной точке и войти в базу через 1С. Старый каталог данных не меняйте, пока восстановленный экземпляр не пройдёт прикладную проверку.

Сохраните исходные данные до диагностики

После аварии скопируйте текущий PGDATA на другой накопитель либо сделайте снимок тома средствами гипервизора или хранилища. Если кластер ещё запускается, сначала ограничьте доступ пользователей: новые транзакции затруднят выбор точки восстановления.

Отдельно сохраните каталог pg_probackup. В нём находятся файлы копий, метаданные экземпляра и архив WAL. Потеря части этого каталога может разорвать цепочку, хотя полная копия останется на месте.

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

План зависит от того, что случилось перед остановкой:

Аварийная остановка требует проверки запуска. Потеря файлов требует резервной копии. Ошибочное изменение данных требует возврата к выбранному моменту.

PostgreSQL записывает изменения в WAL — журнал предзаписи. По официальной документации PostgreSQL, после сбоя сервер воспроизводит записи после последней контрольной точки и приводит файлы к согласованному состоянию. Та же механика используется при восстановлении на момент времени, или PITR.

Проверьте совместимость целевого сервера

pg_probackup восстанавливает кластер только в совместимое окружение. По документации Postgres Professional, на исходном и целевом серверах должны совпадать основная версия PostgreSQL, block_size и wal_block_size.

Основная версия — это первая часть номера выпуска. Копию PostgreSQL 15 нельзя разворачивать как кластер PostgreSQL 16. Установка свежего пакета на новый сервер не заменяет миграцию между основными версиями.

Проверьте параметры исходной системы по сохранённой конфигурации и метаданным копии. На целевом сервере используйте тот же выпуск СУБД и совместимую сборку pg_probackup.

Текущая документация Postgres Pro указывает поддержку PostgreSQL 11 и новее. Репозиторий pg_probackup перечисляет совместимые выпуски 13–18. Для аварийного восстановления ориентируйтесь на матрицу совместимости той версии утилиты, которой создана копия.

Если версии не совпадают, не пытайтесь исправить метаданные вручную. Подготовьте отдельный сервер с нужной основной версией. Обновлять PostgreSQL следует после восстановления и проверки базы 1С.

Найдите пригодную цепочку копий

Каталог pg_probackup может хранить копии нескольких экземпляров PostgreSQL. Сначала выберите нужный экземпляр, затем найдите полную копию и связанные с ней инкрементальные.

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

Не выбирайте архив только по дате каталога. Метаданные pg_probackup показывают статус копии, её тип, идентификатор и связь с предыдущей копией. Если выпало одно звено, более поздняя инкрементальная копия не собирается в исправный кластер.

Перед восстановлением запустите штатную валидацию. По документации Postgres Professional, validate проверяет согласованность копии без развёртывания данных. Команда checkdb решает другую задачу: она проверяет экземпляр PostgreSQL.

Практический порядок такой:

1. Получите список копий нужного экземпляра.
2. Найдите последнюю полную копию со статусом, допускающим восстановление.
3. Проверьте зависимые инкрементальные копии.
4. Запустите валидацию выбранной цепочки.
5. Сверьте наличие WAL до нужной точки.

Параметры каталога, экземпляра и выбранной копии подставляйте из вашей конфигурации:

pg_probackup show -B /backup/pg_probackup --instance 1c-prod

pg_probackup validate \
 -B /backup/pg_probackup \
 --instance 1c-prod \
 -i BACKUP_ID

BACKUP_ID здесь обозначает идентификатор из вывода pg_probackup show. Не копируйте его из примера: другой идентификатор выберет другую цепочку.

Если нужно заново проверить схему резервирования, используйте материал о том, как сочетать физические копии, логический дамп и архив WAL. Такая проверка полезна после аварии, но не должна задерживать текущее восстановление.

Выберите точку возврата

Последняя копия отвечает на вопрос «из чего восстанавливать». Архив WAL определяет, до какого момента можно довести кластер.

При аварийной остановке без ошибочных действий обычно нужен последний доступный момент. pg_probackup поддерживает цель --recovery-target=latest: утилита применит доступные записи WAL после копии.

Если пользователь удалил документы, провёл неверное изменение или запустил неудачную обработку, последнее состояние не подходит. Выберите время перед операцией через --recovery-target-time.

pg_probackup также принимает идентификатор транзакции, LSN и имя заранее созданной точки восстановления. Эти варианты полезны, когда время события неизвестно или часы на системах расходились.

Копия задаёт начало маршрута, а непрерывный WAL — его достижимый конец. Пропущенный сегмент отрезает все более поздние точки.

Официальная документация PostgreSQL требует непрерывную последовательность WAL как минимум от начала базовой копии. Если одного сегмента нет, взять следующий и продолжить нельзя: сервер не сможет воспроизвести пропущенные изменения.

Время цели выбирайте с запасом перед ошибочной операцией. После запуска проверьте данные в 1С и при необходимости повторите восстановление в новом каталоге с другой точкой. Не сдвигайте время на уже восстановленном экземпляре.

Подробный порядок работы с целевым временем, recovery.signal и restore_command описан в инструкции по развёртыванию отдельного кластера до заданного момента.

Разверните PostgreSQL в отдельный каталог

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

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

Команда восстановления зависит от выбранной цели. Общая форма для возврата к последнему доступному состоянию выглядит так:

pg_probackup restore \
 -B /backup/pg_probackup \
 --instance 1c-prod \
 -D /srv/postgresql/1c-recovery \
 -i BACKUP_ID \
 --recovery-target=latest

Для возврата перед ошибочной операцией укажите время:

pg_probackup restore \
 -B /backup/pg_probackup \
 --instance 1c-prod \
 -D /srv/postgresql/1c-recovery \
 -i BACKUP_ID \
 --recovery-target-time="YYYY-MM-DD HH:MM:SS+TZ"

Укажите часовой пояс явно. Иначе время из журнала 1С, системного журнала и PostgreSQL можно сопоставить неверно.

Документация Postgres Professional допускает параллельное восстановление. Число процессов выбирайте по дисковой подсистеме и доступным ресурсам целевого сервера. Для аварийного возврата важнее повторяемый результат, чем минимальное время одной попытки.

У pg_probackup есть инкрементальное восстановление: утилита может повторно использовать исправные неизменённые страницы из PGDATA. На исходном каталоге эту возможность не применяйте. Работайте только с отдельной копией, которую можно удалить и создать заново.

Проверьте PostgreSQL и вход через 1С

Успешное завершение restore ещё не возвращает систему пользователям. Сначала PostgreSQL должен закончить recovery, открыть базы и записать понятный журнал запуска.

Проверьте журнал целевого экземпляра. Ищите ошибки чтения WAL, отсутствующие файлы, сообщения о повреждённых страницах и остановку до целевой точки. Сам факт запуска процесса ничего не говорит о пригодности базы.

Затем подключитесь к серверу средствами PostgreSQL и проверьте список баз. Не меняйте прикладные данные на этом этапе.

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

Для ошибочного удаления сравните несколько контрольных объектов до и после целевого времени. Для аварийной остановки проверьте последние документы, фоновые задания и обмены. Если журналы чисты, а пользователь не входит, продолжайте диагностику на уровне кластера 1С.

Ориентируйтесь не на код возврата команды, а на прикладной результат. Этот же принцип разобран в материале о проверке 1С после автоматического перезапуска.

Что делать, если восстановление остановилось

Ошибка совместимости версии означает, что целевой сервер собран неверно. Установите ту же основную версию PostgreSQL и снова проверьте block_size и wal_block_size. Перенос на новый выпуск оставьте до возврата базы.

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

При разрыве WAL определите последнюю непрерывную точку. Восстановиться позже неё средствами этой цепочки нельзя. Ищите недостающий сегмент в отдельном архиве, на резервном сервере или в сохранённом pg_wal.

Если 1С показывает общее сообщение «Ошибка СУБД», зафиксируйте время и найдите исходную запись PostgreSQL. Порядок разбора приведён в материале о диагностике ошибки СУБД в 1С.

Другие сценарии собраны в схеме действий при авариях базы и сервера. Она поможет отделить повреждение PostgreSQL от сбоя кластера 1С, сети или хранилища.

Если не помогло

Остановитесь, если исправной полной цепочки нет, WAL разорван или PostgreSQL сообщает о повреждении страниц. Дальнейшие попытки не должны менять исходный PGDATA, архив WAL и конфигурацию дискового массива.

Для разбора такого состояния можно передать сохранённые данные на аварийную диагностику 1С и PostgreSQL. До анализа нельзя обещать конкретную точку возврата: она зависит от состояния копий и доступной последовательности WAL.

Чтобы не повторилось

Рабочая схема состоит из полной копии, инкрементальных копий и непрерывного архива WAL. pg_probackup поддерживает режимы DELTA, PAGE и PTRACK, а также хранение по сроку или числу копий. Для отдельной копии можно задать TTL.

Политика хранения не доказывает, что база восстановится. Проверка заканчивается только после развёртывания отдельного кластера и входа тестового пользователя через 1С.

Перед допуском восстановленной базы проверьте пять пунктов:

• выбранная копия прошла validate;
• PostgreSQL завершил recovery до требуемой точки;
• сервер запустился без ошибок чтения данных и WAL;
• тестовый пользователь вошёл в базу через клиент 1С;
• контрольные данные соответствуют выбранному моменту.

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