Как вернуть клиент-серверную базу 1С из дампа pg_dump: pg_restore, кластер, проверка

Чтобы восстановить базу 1С из бэкапа PostgreSQL, создайте на сервере СУБД пустую базу с кодировкой UTF8, загрузите в неё дамп командой pg_restore -d имя_базы файл.dump, а затем пропишите эту базу в свойствах информационной базы в кластере 1С (или зарегистрируйте новую базу, указав на неё). Повреждённую базу при этом не удаляют, а переименовывают: она остаётся запасным вариантом, пока вы не убедитесь, что копия рабочая.

Частое заблуждение — что восстановить бэкап PostgreSQL для базы 1С можно на любом сервере PostgreSQL. Нельзя: база 1С использует собственные типы данных mchar и mvarchar, и они есть только в сборках PostgreSQL для 1С (от фирмы 1С или Postgres Professional). На «ванильном» PostgreSQL загрузка остановится на первой же таблице. Всё, что описано ниже, относится к платформе 8.3 и подходит для Windows и Linux.

1. Подготовка к восстановлению: проверка сервера и дампа

Перед тем как трогать рабочую базу, убедитесь, что восстанавливать есть из чего и есть куда.

Что проверить на сервере СУБД:

• 🐘 Сборка PostgreSQL — та же, что для 1С, с расширениями mchar и fulleq. Проще всего проверить запросом в любой существующей базе 1С: SELECT name FROM pg_available_extensions WHERE name IN ('mchar','fulleq');. Если строк нет — сервер не подходит.
• 🔢 Версия PostgreSQL — номер не ниже той, на которой делали дамп. Дамп с 15-й версии на 14-ю обычно не ляжет.
• 💽 Свободное место — не меньше двойного размера исходной базы. Индексы при загрузке строятся заново, плюс журнал WAL.
• 🔑 Пользователь — роль, под которой сервер 1С подключается к СУБД (часто postgres или отдельная usr1cv8).

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

Проверка целостности. Для custom и directory формата прочитайте оглавление архива:

pg_restore --list /backup/buh_2026-10-06.dump > /tmp/toc.txt

Команда ничего не пишет в базу. Если файл обрезан на этапе оглавления, она сразу выдаст ошибку. Полнее проверка — прогнать весь архив «вхолостую», с выводом в никуда:

pg_restore -f /dev/null /backup/buh_2026-10-06.dump

На Windows вместо /dev/null укажите NUL. Если файл повреждён в середине, pg_restore споткнётся на нём с текстом вроде pg_restore: error: could not read from input file. Такой бэкап не трогайте и берите предыдущий.

2. Остановка работы пользователей и вывод старой базы из строя

Восстанавливать базу, в которой работают люди, нельзя. Сначала закройте к ней доступ.

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

Шаг 1. Заблокируйте вход в информационную базу. В консоли администрирования серверов 1С откройте Информационные базы → ваша база → Свойства. Включите флаг «Блокировка начала сеансов включена» и «Блокировка регламентных заданий включена». Задайте сообщение для пользователей и код разрешения — он пригодится для своего входа позже.

Шаг 2. Завершите текущие сеансы. В той же консоли, в ветке Сеансы базы, выделите все сеансы и удалите их. Фоновые задания тоже попадут в список — их завершение безопасно, если блокировка регламентных заданий уже стоит.

Шаг 3. Разорвите оставшиеся подключения к СУБД. Рабочие процессы 1С держат соединения с базой какое-то время после завершения сеансов. Посмотрите и закройте их из psql:

SELECT pid, usename, application_name, state
FROM pg_stat_activity
WHERE datname = 'buh';

SELECT pg_terminate_backend(pid)
FROM pg_stat_activity
WHERE datname = 'buh' AND pid <> pg_backend_pid();

Если соединения возвращаются, значит, их открывает работающий сервер 1С. Тогда остановите службу сервера 1С. На Windows это служба «Агент сервера 1С:Предприятия 8.3». На Linux имя юнита зависит от версии платформы — найдите его командой systemctl list-units | grep srv1cv8. Остановка службы отключит все базы этого сервера, а не только восстанавливаемую.

Шаг 4. Переименуйте повреждённую базу, а не удаляйте её.

ALTER DATABASE buh RENAME TO buh_broken_20261007;

Переименование мгновенное и обратимое. Если восстановленная копия окажется хуже — вернёте старое имя одной командой. Удалить buh_broken_… можно через неделю-другую, когда база проработает без замечаний.

3. Создание пустой базы данных под восстановление

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

Узнайте параметры исходной базы (это можно сделать и по переименованной):

SELECT datname, pg_encoding_to_char(encoding), datcollate, datctype
FROM pg_database
WHERE datname = 'buh_broken_20261007';

Создайте базу с тем же именем, которое прописано в кластере 1С, и с теми же параметрами. Пример для Linux:

CREATE DATABASE buh
  WITH OWNER = postgres
       ENCODING = 'UTF8'
       LC_COLLATE = 'ru_RU.UTF-8'
       LC_CTYPE = 'ru_RU.UTF-8'
       TEMPLATE = template0;

На Windows локаль обычно называется Russian_Russia.1251. Подставьте ровно то, что вернул запрос выше.

Почему template0. Шаблон template1 по умолчанию может содержать объекты, добавленные администратором, и с ним нельзя задать локаль, отличную от его собственной. template0 чистый, конфликтов при загрузке не будет.

Если восстанавливаете копию рядом с рабочей базой (для проверки или выгрузки данных) — дайте ей другое имя, например buh_copy. Рабочую базу в этом случае не трогайте, шаг 2 пропускается.

4. Восстановление данных через pg_restore

Загрузка в пустую базу — основной шаг. Для дампа в custom-формате:

pg_restore -U postgres -h localhost -d buh \
  --no-owner --no-privileges \
  -j 4 -v \
  /backup/buh_2026-10-06.dump 2> /tmp/restore.log

Что делают параметры:

Для plain SQL-дампа параллельной загрузки нет:

psql -U postgres -d buh -v ON_ERROR_STOP=1 -f /backup/buh_2026-10-06.sql

Флаг ON_ERROR_STOP=1 прерывает загрузку на первой ошибке. Без него psql пройдёт до конца, и вы получите базу с пустыми таблицами, не заметив этого.

Сколько ждать. Время зависит от размера базы и дисков. Ориентировочно база на 50 ГБ на SSD в 4 потока восстанавливается за 30–60 минут, на обычных дисках — в 2–3 раза дольше. Большая часть времени уходит на построение индексов.

После загрузки обновите статистику. Без неё планировщик PostgreSQL первое время строит неудачные планы запросов, и 1С заметно тормозит:

vacuumdb -U postgres -d buh --analyze-in-stages

Как читать лог. Откройте /tmp/restore.log и найдите строки error. В конце pg_restore пишет сводку вида errors ignored on restore: N. Ошибки вида role "usr1cv8" does not exist при --no-owner безвредны. Ошибки на CREATE TABLE или COPY — нет: база неполная.

5. Регистрация восстановленной базы в кластере серверов 1С

Дальше всё зависит от того, как вы назвали восстановленную базу.

Вариант А: имя то же, что было. Если база в PostgreSQL снова называется buh, а информационная база в кластере 1С на неё уже указывала, регистрировать ничего не нужно. Запустите службу сервера 1С, если останавливали её. Затем снимите блокировку начала сеансов — но не раньше, чем проверите базу (раздел 6).

Вариант Б: новое имя или другой сервер. Создайте информационную базу в кластере. В консоли администрирования: Информационные базы → Создать → Информационная база. Заполните поля:

• 🏷 Имя — как база будет называться в кластере (её видит пользователь в строке подключения).
• 🖥 Сервер баз данных — адрес сервера PostgreSQL, например localhost или pg01.
• 🗄 Тип СУБД — PostgreSQL.
• 📛 База данных — ровно имя восстановленной базы в PostgreSQL.
• 👤 Пользователь и пароль сервера БД — роль, под которой 1С подключается к СУБД.
• 📅 Смещение дат — 0. Для PostgreSQL другое значение не используется.
• ☑️ Флаг «Создать базу данных в случае ее отсутствия» — снимите. База уже есть, и при опечатке в имени вы получите ошибку, а не новую пустую базу.
• ☑️ Флаг «Установить блокировку регламентных заданий» — поставьте, если это тестовая копия. Иначе копия начнёт отправлять отчёты, выгружать обмены и рассылать письма от имени рабочей базы.

Ту же регистрацию можно сделать из стартового окна 1С: Добавить → Добавление в список существующей информационной базы, вариант «На сервере 1С:Предприятия». Но там нельзя выставить блокировку регламентных заданий, поэтому для копий надёжнее консоль.

После регистрации добавьте базу в список у пользователей. Строка подключения клиента: Srvr="имя_сервера_1С";Ref="имя_базы_в_кластере";.

6. Обновление конфигурации базы данных и проверка восстановленной базы

Восстановленную базу сначала открывает администратор — с кодом разрешения, при включённой блокировке.

Шаг 1. Конфигуратор. Откройте базу в режиме Конфигуратора. Если бэкап делали посреди обновления, основная конфигурация и конфигурация базы данных могут различаться. Признак — программа при открытии сообщает, что конфигурация базы данных не соответствует основной. Тогда выполните Конфигурация → Обновить конфигурацию базы данных (F7). Если всё совпадает, этот шаг пропускается.

Шаг 2. Тестирование и исправление. Для базы после аварии полезно прогнать Администрирование → Тестирование и исправление в Конфигураторе. Для начала отметьте только «Проверка логической целостности информационной базы» и «Проверка ссылочной целостности» в режиме «Только проверка». Исправлять что-то автоматически стоит, только если проверка нашла ошибки и вы понимаете, что именно будет изменено. Этот режим требует монопольного доступа к базе.

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

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

Шаг 5. Открытие доступа. Снимите блокировку начала сеансов. Блокировку регламентных заданий снимайте только в рабочей базе: в копии она должна остаться.

Что делать с данными после бэкапа. Всё, что внесли между бэкапом и аварией, придётся вводить заново. Если повреждённая база частично читается, выгрузите из неё нужные документы (например, через универсальную выгрузку в XML) и загрузите в восстановленную. Именно поэтому старую базу переименовывали, а не удаляли.

7. Частые ошибки при восстановлении бэкапа PostgreSQL для 1С

• ❌ Удалили рабочую базу до проверки бэкапа. Если дамп окажется битым, возвращать будет нечего. Порядок всегда такой: проверить дамп → переименовать старую базу → восстановить → проверить → только потом удалять.
• ❌ Восстановили поверх существующей базы с --clean. Этот параметр удаляет объекты перед созданием. При ошибке на середине получается гибрид из старых и новых данных. Грузите в пустую базу.
• ❌ Грузили дамп через psql без ON_ERROR_STOP. Ошибки пролетели в консоли, а в базе часть таблиц пустая. 1С откроется, но документы «исчезнут».
• ❌ Забыли про регламентные задания у копии. Копия бухгалтерии отправила в банк платёжки или выгрузила данные в обмен с другой базой. Для любых копий блокировка регламентных заданий — обязательна.
• ❌ Не обновили статистику. Первый день после восстановления база «тормозит», и это списывают на сбой. Достаточно прогнать vacuumdb --analyze-in-stages.
• ❌ Перепутали локаль. База создана с C или en_US.UTF-8 вместо русской локали. Сортировка списков по наименованию в 1С начинает вести себя странно.

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