Разворачиваем копию базы 1С из pg_dump, .bak или .dt

Чтобы восстановить базу 1С из дампа, нужно сначала развернуть дамп средствами самой СУБД (pg_restore или psql для PostgreSQL, RESTORE DATABASE для MS SQL Server), а затем зарегистрировать получившуюся базу данных в кластере серверов 1С. Если же «дамп» — это файл .dt, СУБД не нужна вовсе: его загружают в Конфигураторе.

Выбор способа зависит от того, что лежит в архиве. Дамп СУБД разворачивается быстрее и сохраняет базу один в один, но требует совместимой версии сервера. Файл .dt переносится между любыми СУБД и даже в файловый вариант, зато на больших базах загружается часами.

Что за дамп у вас на руках и что подготовить заранее

Первым делом определите формат файла. От этого зависит весь дальнейший порядок действий.

Проверить формат PostgreSQL-дампа на Linux можно одной командой: head -c 5 файл выведет PGDMP для архивного формата. Текстовый дамп открывается в любом редакторе и начинается с комментариев и команд SET.

Перед восстановлением соберите:

• 🖥️ Версию исходной СУБД. Дамп PostgreSQL разворачивают на сервере той же или более новой основной версии. Резервную копию MS SQL нельзя восстановить на сервере старше по выпуску, чем исходный: копию с SQL Server 2019 не примет SQL Server 2016.
• 🧩 Сборку PostgreSQL для 1С. Базы 1С используют собственные типы данных и расширения (mchar, fulleq и другие). Ванильный PostgreSQL без них дамп не примет. Нужна та же линейка сборки, что стояла на исходном сервере: Postgres Pro для 1С или PostgreSQL с патчами для 1С.
• 💾 Свободное место. Закладывайте не меньше двукратного объёма исходной базы: дамп, сама база, журналы транзакций и временные файлы при построении индексов.
• 🔑 Учётные данные. Пользователь СУБД, от имени которого будет работать сервер 1С, и пароль администратора кластера 1С, если он задан.
• 📌 Версию платформы 1С. На новом сервере должна стоять платформа с номером не ниже той, на которой работала база.

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

Шаг 1. Создайте пустую базу данных

Создайте базу на основе шаблона template0 с кодировкой UTF8 и русской локалью:

sudo -u postgres createdb -T template0 -E UTF8 --locale=ru_RU.UTF-8 buh_copy

На Windows имя локали другое — Russian_Russia.1251. Смотрите, какая локаль у исходного кластера PostgreSQL, и повторяйте её: от этого зависит порядок сортировки строк в отчётах и списках.

Шаг 2. Разверните архивный дамп

Для архивного формата (-Fc или каталог) команда выглядит так:

sudo -u postgres pg_restore -d buh_copy -j 4 --no-owner --role=usr1cv8 /backup/buh.backup

Что делают ключи:

1. -d buh_copy — база, в которую восстанавливаем.
2. -j 4 — четыре параллельных потока. Ставьте по числу ядер, свободных от другой нагрузки. Параллельное восстановление работает только с архивным и каталожным форматами.
3. --no-owner — не переносить владельца объектов из исходной базы.
4. --role=usr1cv8 — сделать владельцем пользователя, под которым подключается сервер 1С. Подставьте своё имя роли.

Посмотреть содержимое архива, не восстанавливая его, можно через pg_restore -l /backup/buh.backup. Это быстрый способ убедиться, что файл не битый и в нём есть таблицы.

Шаг 3. Если дамп текстовый

Текстовый .sql разворачивают через psql. Параллельности здесь нет, поэтому большая база восстанавливается заметно дольше:

sudo -u postgres psql -d buh_copy -f /backup/buh.sql

Если файл сжат в .gz, распаковывать на диск не обязательно: gunzip -c buh.sql.gz | sudo -u postgres psql -d buh_copy.

Особенности восстановления из резервной копии MS SQL Server

Резервная копия .bak содержит не SQL-команды, а образ файлов базы. Поэтому сначала выясните логические имена файлов внутри копии:

RESTORE FILELISTONLY FROM DISK = N'D:\Backup\buh.bak';

Запрос вернёт две строки: файл данных и файл журнала. Их логические имена (LogicalName) понадобятся в команде восстановления.

Восстановление в новую базу

RESTORE DATABASE [buh_copy]
FROM DISK = N'D:\Backup\buh.bak'
WITH MOVE N'buh'     TO N'E:\SQLData\buh_copy.mdf',
     MOVE N'buh_log' TO N'F:\SQLLog\buh_copy_log.ldf',
     STATS = 10;

Ключ MOVE нужен, чтобы файлы копии не легли поверх файлов исходной базы, если она живёт на том же сервере. STATS = 10 выводит прогресс каждые 10%.

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

Права пользователя 1С

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

ALTER AUTHORIZATION ON DATABASE::[buh_copy] TO [usr1cv8];

Если в базе остался пользователь со старым SID, свяжите его с логином: ALTER USER [usr1cv8] WITH LOGIN = [usr1cv8];.

Проверьте и сопоставление (collation) сервера. Для баз 1С обычно используют Cyrillic_General_CI_AS. Если сервер настроен иначе, база восстановится, но временные таблицы будут создаваться в сопоставлении tempdb, и часть запросов 1С может завершаться ошибкой конфликта сопоставлений.

Когда «дамп» — это файл .dt

В обиходе дампом часто называют выгрузку информационной базы средствами 1С. Её загружают так:

1. Создайте пустую базу: файловую или серверную через консоль кластера (см. следующий раздел, там флажок создания базы данных как раз нужно включить).
2. Откройте её в Конфигураторе.
3. Выберите Администрирование → Загрузить информационную базу... и укажите файл .dt.
4. Подтвердите замену данных и дождитесь сообщения об успешной загрузке.

Загрузка требует монопольного доступа к базе. Если вы загружаете .dt в уже существующую базу, все пользователи в ней должны завершить работу, а её текущие данные будут полностью заменены.

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

Развёрнутая в СУБД база для 1С пока не существует. Её нужно описать в кластере.

1. Откройте «Администрирование серверов 1С Предприятия» (консоль кластера).
2. Разверните сервер, кластер и узел «Информационные базы».
3. В контекстном меню узла выберите Создать → Информационная база.
4. Заполните поля:
   • Имя — под этим именем база будет видна пользователям, например buh_copy;
   • Сервер баз данных — адрес сервера СУБД (для MS SQL с именованным экземпляром — сервер\экземпляр);
   • Тип СУБД — PostgreSQL или MS SQL Server;
   • База данных — точное имя базы, которую вы восстановили;
   • Пользователь сервера БД и пароль;
   • Смещение дат — такое же, как у исходной базы. Для MS SQL базы 1С обычно создают со смещением 2000, для PostgreSQL — 0.
5. Снимите флажок «Создать базу данных в случае ее отсутствия». Если в имени базы опечатка, с включённым флажком 1С молча создаст пустую базу, и вы потратите время на поиск «пропавших» данных.
6. Включите флажок «Установить блокировку регламентных заданий».
7. Нажмите «ОК».

То же самое можно сделать из командной строки утилитой rac через команду rac infobase create. Набор параметров зависит от версии платформы, поэтому сверяйтесь с rac help infobase.

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

Первый запуск копии

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

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

Ошибки при восстановлении дампа: на что смотреть в логах

Выше собраны частые сообщения с готовыми решениями. Если вашего случая там нет, ищите причину так.

• 📄 PostgreSQL. pg_restore по умолчанию продолжает работу после ошибок и в конце выводит их число. Пролистайте вывод до первой ошибки: остальные обычно её следствие. Ключ --exit-on-error остановит восстановление сразу.
• 📄 Журнал сервера PostgreSQL лежит в каталоге log внутри каталога данных. Там видны нехватка места, обрывы соединения и проблемы с памятью.
• 📄 MS SQL. Сообщения RESTORE выводятся в окне запроса, подробности — в журнале ошибок SQL Server.
• 📄 1С. Если база восстановилась, но не открывается, включите технологический журнал или посмотрите журнал событий Windows на сервере 1С.

Отдельная ситуация — дамп оборвался при создании. Признак: pg_restore сообщает о неожиданном конце файла, а в MS SQL RESTORE VERIFYONLY завершается ошибкой. Такую копию не починить, нужна предыдущая.

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

Когда дамп СУБД упорно не встаёт на новый сервер из-за версий или сборок, обходной путь один: поднять временный сервер с той же СУБД и версией, что была на исходном, развернуть дамп там, подключить к кластеру 1С и выгрузить .dt. Файл .dt уже загружается в любую СУБД.

После восстановления запустите в Конфигураторе Администрирование → Тестирование и исправление с режимом «Только тестирование». Если тест покажет ошибки логической целостности, исправляйте их на копии, а не в рабочей базе.

Скорость работы после восстановления

Свежеразвёрнутая база часто работает медленнее исходной, хотя данные те же. Причина — статистика планировщика: после восстановления она отсутствует или устарела, и СУБД выбирает неудачные планы запросов.

Для PostgreSQL соберите статистику по всей базе:

sudo -u postgres vacuumdb --analyze-in-stages -d buh_copy

Режим --analyze-in-stages сначала собирает грубую статистику, чтобы базой можно было пользоваться почти сразу, а потом уточняет её.

Для MS SQL обновите статистику и при необходимости перестройте индексы:

USE [buh_copy];
EXEC sp_updatestats;

Ещё несколько настроек, которые стоит проверить на новом сервере:

• ⚙️ Модель восстановления MS SQL. Для тестовой копии ставьте SIMPLE, иначе журнал транзакций будет расти без ограничений.
• ⚙️ Параметры памяти PostgreSQL. После переезда postgresql.conf остаётся новым. Перенесите со старого сервера shared_buffers, effective_cache_size, work_mem, иначе база будет работать на значениях по умолчанию.
• ⚙️ Регламентное обслуживание. Для MS SQL настройте план обслуживания со статистикой и индексами, для PostgreSQL проверьте, что включён autovacuum.
• ⚙️ Кэш клиента. Если пользователи раньше работали с одноимённой базой на другом сервере, при странных ошибках интерфейса запустите клиент с ключом /ClearCache.

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