Как проверить восстановление базы 1С на PostgreSQL

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

Что доказывает тестовое восстановление

Файл с названием «backup» доказывает только то, что какой-то процесс создал файл. Он не доказывает, что архив читается, что в нём есть нужная база, что рядом сохранены роли и настройки подключения и что у команды есть доступ к копии. Восстановление проверяет цепочку целиком: носитель читается, формат распознаётся, PostgreSQL принимает данные, а приложение подключается к получившейся базе. Поэтому в регламенте я разделяю «задание завершилось» и «восстановление прошло проверку». Это разные результаты, и смешивать их удобно ровно до первого сбоя.

Для клиент-серверной 1С на PostgreSQL копию нужно проверять именно в той форме, в которой её будут поднимать при аварии. Если рабочий процесс создаёт логический дамп, отрабатываем восстановление из дампа. Если настроено физическое резервирование с архивированием WAL, проверяем базовую копию вместе с нужными журналами. Копия файловой базы 1С и дамп PostgreSQL — разные объекты с разными способами восстановления. Универсального теста, который волшебно подтвердит любой тип копии, нет. Жаль: один зелёный индикатор был бы дешевле, чем администратор. В моих проектах я прошу назначить владельца проверки и человека на замену: иначе процедура есть в файле, но в отпуске некому её выполнить. Ещё до старта фиксируем критерий успеха и кто подтверждает результат со стороны бизнеса. Эти договорённости не ускоряют команду pg_restore, зато убирают спор после него: «вроде всё восстановилось» не становится актом приёмки.

• Доступность и читаемость копии.
• Успешный запуск восстановления.
• Подключение 1С и проверка рабочих сценариев.

Условный разбор: 23 рабочих места и одна копия

Разберу условную ситуацию из статьи: дистрибьютор художественных материалов «Пигмент-Опт», 23 рабочих места и серверная база 1С на PostgreSQL. Представим, что ночное обновление или ошибка администратора оставили базу недоступной. В этот момент мало знать, что вчера запускалось задание копирования. Нужно понять, какая именно копия доступна, чем она создана, какие вспомогательные данные понадобятся и кто способен пройти восстановление без импровизации на рабочем сервере.

В первоначальном тексте причиной аварии назывался текстовый дамп, якобы несовместимый с восстановлением через PostgreSQL. Это неверная формулировка: plain SQL-дамп восстанавливают через psql, а архивные форматы — через pg_restore. Выбор custom-формата удобен, когда нужен архив для pg_restore, но это не обязательный формат для каждой базы и не «бинарное условие спасения». В условном разборе я убираю выдуманные часы поиска, пароль и недельную потерю: без журнала работ такие цифры создают ложную точность, а не полезный опыт. Условный пример нужен не для того, чтобы приписать кому-то аварию, а чтобы пройти сценарий без давления реального простоя. Мы заранее выясняем, где лежит копия, кто имеет право её читать и есть ли независимая от рабочего сервера копия. Подробный разбор того, что именно сохраняет база, можно связать с материалом о выгрузке и загрузке базы 1С. Сверка до инцидента обходится дешевле, чем выяснение формата посреди него.

Как выбрать способ резервирования

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

Флаг -Fc создаёт custom-архив, который читают pg_restore; формат сжат по умолчанию, а состав объектов можно выбирать при восстановлении. Это полезный вариант, но он сам по себе не спасает от потери файла, не копирует весь кластер целиком и не проверяет прикладную работу 1С. Физическая стратегия с базовой копией и WAL решает другой класс задач: при наличии непрерывной цепочки журналов PostgreSQL можно восстановить состояние на выбранный момент после базовой копии. Это отдельная схема со своими настройками и дисциплиной хранения. Я выбираю метод по целям восстановления, а не по моде на название утилиты. Сравнивать нужно не абстрактную скорость, а время полного цикла: подготовить среду, передать архив, восстановить и подтвердить доступность. Учтите также кластерные объекты: pg_dump экспортирует одну базу, поэтому роли и другие общие объекты кластера требуют отдельного внимания при планировании переноса. Список состава копии полезнее обещания «копируем всё». Перед выбором физической схемы проверьте, кто будет следить за архивом журналов и что произойдёт, если WAL перестанет сохраняться.

• Логическая копия: одна база, формат SQL или архив.
• Физическая копия и WAL: восстановление к моменту времени.
• Проверка нужна для обоих вариантов.

Как восстановить дамп на тестовом стенде

Сначала готовлю отдельный тестовый экземпляр или изолированную виртуальную машину. Проверяю версию PostgreSQL, наличие свободного места, доступ к файлу копии и реквизиты подключения. Рабочий сервер для эксперимента не подходит: можно занять ресурсы, перепутать базу назначения или затронуть пользователей. На стенде создаю пустую базу с нужным владельцем и параметрами локальной установки. Имена test_db, postgres и backup.dump в примере — условные; их заменяют на реальные значения своей среды. Права администратора не следует угадывать: роль должна иметь ровно те разрешения, которые нужны для подготовленного восстановления.

Для custom-архива схема команды выглядит так: pg_restore -U <роль> -d <имя_базы> <файл_дампа>. До запуска я сверяю аргументы с версией утилиты и проверяю, что указана именно тестовая база. -d задаёт базу назначения, а имя архива передаётся последним аргументом. Для обычного текстового SQL-дампа нужен другой путь — передать скрипт клиенту psql; pg_restore не предназначен для plain-формата. Не вставляйте пример без проверки окружения: угловые скобки здесь обозначают места для подстановки, это не готовая команда для копирования. После восстановления отдельно сверьте владельцев объектов и необходимые разрешения: архив может включать сведения о правах, и результат зависит от параметров запуска и ролей целевой среды. Не подставляйте суперпользователя автоматически только потому, что он фигурирует в примере из интернета. В изолированном стенде нет ценных пользователей, но всё равно полезно ограничить доступ к копии: в ней могут оказаться персональные и финансовые данные.

• Подготовить изолированную среду.
• Определить тип файла и штатную утилиту.
• Восстановить в заранее созданную тестовую базу.
• Записать ошибки и длительность.

Что проверять после восстановления

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

Режим «Тестирование и исправление» не заменяет резервное копирование и не должен автоматически запускаться на единственной копии. Это отдельная операция обслуживания, и перед изменением данных нужен сохранённый исходник. Для практической проверки я фиксирую контрольные суммы или заранее выбранные бизнес-показатели только если их можно корректно сравнить: например, остатки на согласованную дату и число документов в конкретном периоде. Открылась база — ещё не значит, что все данные верны; совпало несколько показателей — тоже не математическая гарантия. Это разумный набор проверок, который снижает риск и показывает границы проверки. Для повторяемости добавьте к проверке контрольный сценарий с ожидаемым результатом и сохраните обезличенный лог. Проверьте вход под тестовой учётной записью с обычными правами, а не только административный доступ: именно так обнаруживаются недостающие роли. Если база использует внешние файлы, драйверы или расширения, запишите зависимости отдельно. Такой список делает пробный запуск похожим на реальную процедуру, а не на демонстрацию одного удачного соединения.

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

Окно, точка восстановления и журнал проверки

pg_dump делает логический снимок базы на момент начала выгрузки; активная работа пользователей сама по себе не превращает его в несогласованную копию. Это подтверждает документация PostgreSQL. Окно всё равно планируют: длительный экспорт создаёт нагрузку, а обновление 1С или регламентная обработка может мешать сопоставлению результатов. Поэтому я согласую расписание с владельцем системы, учитываю фоновые задания и заранее определяю допустимый объём потери данных. Если нужна точка восстановления во времени, одного файла pg_dump недостаточно — для PITR необходима физическая базовая копия и цепочка WAL за нужный период.

В журнале тестов я записываю дату, источник копии, способ резервирования, версии клиентских утилит и сервера, длительность восстановления, результат подключения 1С и пройденные проверки. Отдельно отмечаю, какие роли, расширения, настройки и внешние файлы понадобились. Это позволяет увидеть, что копия стала старой, стенд не соответствует рабочей системе или процедура зависит от человека, который помнит пароль наизусть. Частоту теста выбирают под допустимый простой и скорость изменения данных; я не называю «раз в месяц» универсальным требованием PostgreSQL или 1С. Регламент должен отвечать на простой вопрос: успеем ли мы вернуть систему в приемлемый срок? Если время восстановления превышает допустимый простой, это не повод скрывать результат в отчёте. Уменьшайте интервал между базовыми копиями, пересматривайте способ хранения и проверяйте пропускную способность стенда — по одному изменению за раз. В каталог связанных тем я добавил материал о восстановлении базы 1С после сбоя: там полезно отдельно разобрать прикладные действия после запуска СУБД. Регламент считается рабочим, когда его может повторить другой специалист.

Частые вопросы