Администрирование · 12 мин
Как правильно восстановить базу 1С PostgreSQL
Как правильно восстановить базу 1С на PostgreSQL: pg_dump и pg_restore, восстановление из DT, типичные ошибки, проверка результата и меры безопасности.
Восстановление базы 1С на PostgreSQL требуется при сбоях сервера, миграции на новое оборудование, откате после неудачного обновления конфигурации или повреждении данных. Главное правило: восстановление всегда начинается с оценки того, какие копии у вас есть и насколько они актуальны. От этого зависит выбор инструмента и объём возможных потерь.
Существует два принципиально разных источника восстановления: штатный дамп PostgreSQL, созданный утилитой pg_dump, и выгрузка информационной базы в файл DT средствами конфигуратора 1С. Это не взаимозаменяемые форматы: дамп PostgreSQL содержит данные на уровне СУБД и восстанавливается быстро, а DT — логический снимок базы 1С, который можно загрузить даже в другую СУБД, но процесс занимает заметно больше времени.
Ниже разобраны оба сценария с конкретными командами, условиями выбора, типичными ошибками и способами проверить, что восстановление прошло корректно.
Определите тип резервной копии и масштаб проблемы
Прежде чем запускать какие-либо команды, ответьте на три вопроса. Первый: какой файл у вас есть — дамп PostgreSQL (обычно файл .backup, .dump или .sql, созданный pg_dump) или выгрузка 1С (.dt)? Второй: жива ли текущая база и нужно ли сохранить её остатки? Третий: совпадает ли версия PostgreSQL, на которой делалась копия, с версией целевого сервера?
Несовпадение версий — частая причина неудач. Дамп, снятый с PostgreSQL 15, обычно загружается на ту же или более новую версию, но обратная совместимость не гарантируется. Если целевой сервер старше, надёжнее установить нужную версию СУБД, чем бороться с ошибками несовместимых системных каталогов.
Восстанавливается через конфигуратор, медленно, но независимо от СУБД
Восстанавливается pg_restore, быстрый способ
Восстанавливается через psql
Остановите сервер, снимите посекторную копию диска и обратитесь к специалистам по восстановлению данных
Подготовьте сервер и остановите работу пользователей
Восстановление выполняется только в монопольном режиме. Завершите сеансы пользователей через консоль кластера 1С: откройте список сеансов информационной базы и удалите их, либо установите блокировку сеансов заранее. Активные соединения с базой данных помешают pg_restore пересоздать таблицы, а в худшем случае приведут к смешению старых и новых данных.
Обязательно сделайте копию текущего состояния базы, даже если она повреждена или содержит ошибочные данные. Команда pg_dump на «умирающей» базе часто выполняется успешно, и этот дамп может стать последним шансом достать данные, если восстановление пойдёт не по плану. Также убедитесь, что на диске достаточно свободного места: потребуется пространство под саму базу, временные файлы и журналы WAL — ориентируйтесь минимум на двойной размер дампа.
Восстановите базу из дампа PostgreSQL
Это основной и самый быстрый сценарий. Сначала создайте пустую информационную базу через консоль кластера 1С: при создании укажите имя базы, пользователя PostgreSQL (обычно тот, что использовался раньше) и обязательно снимите флаг «Создать базу данных при её отсутствии» не требуется — наоборот, пусть кластер создаст пустую БД. Важно: параметры сортировки (locale) новой базы должны совпадать с исходными, обычно это ru_RU.UTF-8, иначе возможны ошибки сравнения строк.
Затем загрузите дамп. Для дампа в custom-формате используется pg_restore, для текстового — psql:
pg_restore -h localhost -U postgres -d my_base --no-owner --no-privileges /backup/my_base.backup
# или для текстового дампа:
psql -h localhost -U postgres -d my_base -f /backup/my_base.sqlКлючи --no-owner и --no-privileges снимают привязку к старым ролям и правам — это избавляет от ошибок, если владелец объектов на новом сервере называется иначе. После загрузки проверьте, что все таблицы принадлежат пользователю, под которым работает сервер 1С, иначе база откроется с ошибками доступа.
- 1Завершите сеансы пользователей и заблокируйте новые подключения
- 2Сделайте резервную копию текущего состояния базы
- 3Создайте пустую информационную базу через консоль кластера 1С с правильной локалью
- 4Загрузите дамп командой pg_restore или psql
- 5Проверьте владельца таблиц и при необходимости выполните REASSIGN OWNED
- 6Запустите конфигуратор и выполните тестирование и исправление в режиме проверки логической целостности
- 7Откройте базу пользователям и сверьте ключевые отчёты с контрольными значениями
Восстановите базу из файла DT
Если дампа PostgreSQL нет, но есть выгрузка .dt, восстановление выполняется штатными средствами 1С. Создайте пустую информационную базу через консоль кластера (или стартовое окно 1С), откройте её в конфигураторе и выберите «Администрирование → Загрузить информационную базу», указав файл DT.
Учтите ограничения этого способа. Загрузка DT большой базы может занимать часы — в разы дольше, чем pg_restore. Файл DT не переносит некоторые настройки уровня СУБД и расширения PostgreSQL. Кроме того, загрузка требует значительного объёма оперативной памяти и дискового пространства на сервере, а прерывание процесса оставляет базу в незагруженном состоянии, и процедуру придётся начинать заново.
После загрузки DT обязательно выполните тестирование и исправление и проверьте версию конфигурации: если DT снимался с другой версии платформы, может потребоваться обновление конфигурации базы данных.
Сравнение способов восстановления
Быстро, точная побайтовая копия на уровне СУБД. Требует совместимой версии PostgreSQL и правильной локали
Независима от СУБД, подходит для переноса между PostgreSQL и MS SQL. Медленная, не переносит специфику СУБД
Подходит для аварийного восстановления всего кластера целиком. Требует идентичной версии PostgreSQL и остановленного сервера при копировании
Проверьте результат восстановления
Успешное завершение pg_restore без ошибок — необходимое, но не достаточное условие. Запустите конфигуратор и выполните «Тестирование и исправление» с включённой проверкой логической целостности данных, но без реструктуризации на первом проходе. Затем откройте базу в режиме предприятия и сверьте контрольные показатели: остатки по складу, взаиморасчёты, оборотно-сальдовую ведомость за последний закрытый период.
Хорошая практика — зафиксировать контрольные суммы заранее: перед аварией или миграцией сформируйте несколько стандартных отчётов и сохраните их. После восстановления сравнение займёт минуты и однозначно покажет, целы ли данные.
Как проверить результат
Процесс завершился, ошибок нет или они касаются только несуществующих ролей
Ошибки вида relation does not exist, duplicate key, обрыв на середине
База открывается, сеансы устанавливаются, журнал регистрации пишется
Ошибки доступа к таблицам, невозможность установить соединение
Остатки и обороты совпадают с сохранёнными значениями
Расхождения сумм, пустые регистры
Проверка логической целостности проходит без критических ошибок
Множественные ошибки ссылочной целостности
Типичные ошибки и как их избежать
Большинство проблем при восстановлении связано не с самими командами, а с нарушением подготовительных условий. Разберём самые частые сценарии.
Отдельно стоит сказать про пароли и роли. Если на новом сервере нет роли, под которой работал старый, создайте её до восстановления с тем же именем и паролем, либо используйте --no-owner и после загрузки выполните REASSIGN OWNED. Проверить владельца можно запросом к pg_tables.
Держите под рукой два независимых типа копий: ежедневный дамп pg_dump и периодическую выгрузку DT. Дамп спасает при сбоях сервера, а DT — при логической порче данных, которую дамп просто скопирует. Хранить копии стоит на отдельном от боевого сервера носителе, иначе отказ диска уничтожит и базу, и резерв.
Что делать, если резервной копии нет
Ситуация без бэкапа — самая тяжёлая. Если служба PostgreSQL ещё запускается, немедленно выполните pg_dump всей базы — это приоритет номер один. Если сервер не стартует, остановите все попытки запуска, скопируйте весь каталог данных PostgreSQL (каталог data со всем содержимым) на другой диск и только потом экспериментируйте на копии.
Иногда базу удаётся поднять, временно изменив параметры конфигурации PostgreSQL (например, отключив проверки целостности), чтобы успеть снять дамп. Такие действия выполняются только на копии данных и требуют опыта администрирования PostgreSQL: неправильные действия превращают частично читаемую базу в нечитаемую. Если данные критичны для бизнеса, на этом этапе разумно привлечь специалистов по восстановлению СУБД.
Как выбрать действие
Что важно запомнить
Восстановление базы 1С на PostgreSQL сводится к трём условиям: монопольный режим, совместимость версий и локали, правильный владелец таблиц после загрузки. Основной инструмент — pg_restore для дампов СУБД и конфигуратор для файлов DT. Результат всегда проверяется тестированием логической целостности и сверкой контрольных отчётов.
Частые вопросы
Можно ли восстановить дамп PostgreSQL в базу с другим именем?
Да. Дамп pg_dump не привязан жёстко к имени базы: создайте пустую базу с нужным именем и укажите её в параметре -d команды pg_restore. Важно лишь, чтобы совпадали локаль и версия СУБД, а после загрузки в консоли кластера 1С был указан правильный путь к новой базе.
Почему pg_restore выдаёт ошибки про роли и как на них реагировать?
Ошибки вида «role does not exist» возникают, когда на новом сервере нет ролей, которые были владельцами объектов на старом. Если вы используете ключи --no-owner и --no-privileges, эти ошибки не появятся вовсе. Иначе создайте недостающие роли до восстановления или после загрузки переназначьте владельца командой REASSIGN OWNED.
Сколько времени занимает восстановление большой базы?
Зависит от объёма данных, скорости дисков и способа. pg_restore с флагом параллельности -j обычно справляется в разы быстрее, чем загрузка DT той же базы. Загрузка DT сотен гигабайт может занять много часов, поэтому для больших баз предпочтителен именно дамп СУБД. Точное время стоит замерить на тестовом восстановлении заранее.
Нужно ли после восстановления обновлять конфигурацию базы данных?
Если дамп восстанавливался на ту же версию платформы 1С, обычно нет — структура базы уже соответствует конфигурации. Обновление потребуется, если копия снималась на другой версии платформы или если вы загружаете DT, снятый до обновления конфигурации. Конфигуратор сам сообщит о необходимости обновления при открытии.
Как проверить резервную копию, не дожидаясь аварии?
Периодически выполняйте тестовое восстановление на отдельный сервер или в копию базы: pg_restore в тестовую БД, запуск конфигуратора, тестирование логической целостности и сверка пары отчётов. Копия, которая ни разу не проверялась восстановлением, не считается надёжной — дамп может оказаться битым или неполным именно в момент, когда он нужен.
Чем отличается логическая копия от физической и какую делать?
Логическая копия (pg_dump) содержит данные в виде набора команд и читается на другом сервере с совместимой версией. Физическая копия — это побайтовый снимок каталога данных, который работает только с той же версией PostgreSQL, но восстанавливается быстрее и захватывает весь кластер целиком. Для баз 1С чаще применяют pg_dump как более гибкий вариант, а физические копии используют в связке с потоковой репликацией в крупных внедрениях.