Как восстановить базу 1С из бэкапа PostgreSQL

Восстановление базы 1С из резервной копии PostgreSQL — типовая задача администратора при сбое сервера, переносе базы на новое оборудование или откате после неудачного обновления конфигурации. Главное, что нужно понимать: бэкап средствами СУБД (pg_dump) и выгрузка из конфигуратора 1С (файл .dt) — это два разных механизма, и процедура восстановления для них отличается.

В этой статье рассматривается именно восстановление из дампа PostgreSQL: как проверить целостность копии, подготовить сервер, выполнить pg_restore или psql, зарегистрировать базу в кластере 1С и убедиться, что данные на месте. Материал ориентирован на типовую связку «сервер 1С:Предприятие + PostgreSQL», включая сборки PostgresPro.

Перед любыми действиями убедитесь, что у вас есть файл дампа, доступ к серверу СУБД с правами суперпользователя (обычно postgres), а пользователи 1С завершили работу. Восстановление в существующую базу уничтожит текущие данные — это необратимая операция.

Какие виды бэкапов бывают и чем они отличаются

Перед восстановлением важно определить, какой именно файл у вас в руках, потому что от этого зависит вся процедура. Чаще всего встречаются три варианта.

Первый — дамп в собственном (custom) формате, созданный командой pg_dump -Fc. Файл обычно имеет расширение .dump или .backup, он сжат и восстанавливается только утилитой pg_restore. Второй — текстовый SQL-скрипт, созданный pg_dump -Fp или pg_dump без параметров формата; такие файлы восстанавливаются через psql. Третий — архив каталога данных кластера (физическая копия pg_basebackup или файловый архив каталога data) — он восстанавливается совсем иначе, путём замены каталога данных сервера.

Отдельно стоит файл .dt — это выгрузка информационной базы средствами 1С. Его нельзя восстановить через pg_restore: .dt загружается через конфигуратор («Администрирование → Загрузить информационную базу»). Если у вас именно .dt, разделы про pg_restore не нужны — создайте пустую базу в кластере 1С и загрузите .dt в неё.

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

Начните с проверки самого файла бэкапа. Для custom-формата выполните pg_restore --list файл.dump — утилита выведет оглавление дампа. Если список объектов читается без ошибок, файл с высокой вероятностью цел. Если команда падает с ошибкой формата — файл повреждён или это не custom-дамп.

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

Убедитесь, что на диске достаточно свободного места. Для восстановления потребуется объём, сопоставимый с размером рабочей базы (дамп обычно сжат и занимает заметно меньше, чем сама база). Также проверьте, что знаете пароль пользователя postgres и имеете доступ к серверу по SSH или локально.

Подготовка сервера и создание пустой базы

Остановите работу пользователей с базой: завершите сеансы в консоли кластера 1С или заблокируйте соединения на уровне СУБД. Если восстановление идёт в базу с тем же именем, активные подключения помешают удалить или пересоздать её.

Подключитесь к серверу PostgreSQL под пользователем postgres и создайте чистую базу. Для 1С важны параметры: владелец — пользователь, под которым сервер 1С подключается к СУБД (обычно postgres), а также корректные настройки локали. Типовая команда выглядит так:

sudo -u postgres createdb -O postgres -E UTF8 --locale=ru_RU.UTF-8 --template=template0 my1cbase

Если база с таким именем уже существует и её нужно заменить, сначала завершите активные сессии, затем удалите старую базу:

sudo -u postgres psql -c "SELECT pg_terminate_backend(pid) FROM pg_stat_activity WHERE datname='my1cbase' AND pid <> pg_backend_pid();"
sudo -u postgres dropdb my1cbase

Восстановление через pg_restore

Основной сценарий — развёртывание custom-дампа в созданную пустую базу. Команда выполняется от пользователя postgres:

sudo -u postgres pg_restore -d my1cbase --no-owner --no-acl -j 4 /backup/my1cbase.dump

Разберём ключи. -d my1cbase — целевая база. --no-owner и --no-acl отключают восстановление владельцев и прав из дампа — это полезно, когда дамп переносится между серверами с разными пользователями; без этих ключей часто сыплются ошибки «role does not exist». -j 4 включает параллельное восстановление в четыре потока, что заметно ускоряет процесс на больших базах (работает только с custom-форматом).

Время восстановления зависит от размера базы и скорости дисков: база в десятки гигабайт может разворачиваться от нескольких минут до часа и дольше. Не прерывайте процесс, пока команда не завершится. Отдельные предупреждения в выводе (например, про существующие расширения) обычно некритичны, но ошибки уровня ERROR нужно разбирать — часто они указывают на нехватку прав или несовпадение версий.

Восстановление текстового SQL-дампа

Если бэкап — текстовый файл .sql, pg_restore не подойдёт. Используйте psql:

sudo -u postgres psql -d my1cbase -f /backup/my1cbase.sql

Параллельности здесь нет, поэтому большие текстовые дампы восстанавливаются дольше. Для сжатого архива .sql.gz можно выполнять развёртывание на лету: gunzip -c файл.sql.gz | sudo -u postgres psql -d my1cbase.

Регистрация базы в кластере 1С

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

Откройте консоль кластера, создайте новую информационную базу и укажите: тип СУБД — PostgreSQL, имя сервера СУБД, имя базы данных (то, что вы создавали через createdb), пользователя и пароль СУБД. Флажок «Создать базу данных в случае её отсутствия» ставить не нужно — база уже существует и заполнена данными.

Проверка результата после восстановления

Первый признак успеха — pg_restore завершился без критических ошибок, а база видна в списке: sudo -u postgres psql -l. Далее запустите конфигуратор 1С и войдите в восстановленную базу. Если вход проходит и открываются справочники и документы — структура на месте.

Обязательно сверьте содержимое: откройте несколько последних документов, которые точно были на момент бэкапа, проверьте итоги по отчётам за закрытый период. Полезно выполнить «Тестирование и исправление» информационной базы в режиме проверки логической целостности — это выявит повреждения, если дамп был снят с уже проблемной базы.

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

Типичные ошибки и как их избежать

Самая частая проблема — ошибки вида «role ... does not exist» при развёртывании дампа с другого сервера. Решается ключами --no-owner --no-acl либо предварительным созданием нужных ролей. Вторая распространённая ошибка — попытка восстановить текстовый дамп через pg_restore или custom-дамп через psql: утилита сообщит о неверном формате, и это признак, что выбран не тот инструмент.

Ещё одна типичная ситуация — восстановление в непустую базу. pg_restore в этом случае выдаёт множество ошибок «already exists», а данные могут задвоиться или остаться в смешанном состоянии. Всегда восстанавливайте в чистую базу, созданную заново. Наконец, не забывайте про блокировку сеансов: попытка удалить базу, к которой подключены пользователи, завершится ошибкой «database is being accessed by other users».

Альтернативные способы: что выбрать в разных ситуациях

Восстановление через pg_restore — не единственный путь. Если нужно перенести базу между разными СУБД (например, с PostgreSQL на MS SQL) или версиями платформы, надёжнее использовать выгрузку .dt через конфигуратор: она не привязана к конкретной СУБД. Минус — .dt медленнее на больших базах и требует монопольного доступа.

Если у вас физическая копия каталога данных или настроена потоковая репликация, восстановление выполняется на уровне всего кластера PostgreSQL, а не отдельной базы — это сценарий для аварийного восстановления сервера целиком. Для разовой задачи «вернуть одну базу 1С» оптимален именно pg_restore в чистую базу.

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