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

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

Чаще всего под «дампом» в контексте 1С понимают либо файл выгрузки .dt, созданный через конфигуратор, либо дамп СУБД — например, файл, полученный через pg_dump для PostgreSQL или средствами SQL Server. Это принципиально разные форматы, и восстанавливаются они разными инструментами. Файл .dt загружается через конфигуратор, а дамп СУБД — средствами самой СУБД с последующей привязкой базы к серверу 1С.

Ниже разобраны оба сценария с конкретными шагами, проверками результата и типичными ошибками. Материал подходит для платформ 1С:Предприятие 8.3, работающих с файловыми базами и с популярными СУБД: PostgreSQL, MS SQL Server.

Определите тип дампа и тип базы перед началом работы

Первый шаг — понять, с чем вы имеете дело. Откройте папку с резервной копией и посмотрите на расширение файла. Файл с расширением .dt — это выгрузка информационной базы средствами 1С. Файлы .sql, .backup, .bak, .dump — это дампы на уровне СУБД. Если в копии лежит файл 1Cv8.1CD, это не дамп, а сама файловая база целиком — её достаточно скопировать в нужный каталог и подключить через список баз.

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

Подготовка: что сделать до восстановления

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

Завершите все активные сеансы пользователей. Загрузка .dt требует монопольного доступа к базе — при открытых сеансах конфигуратор откажет в операции. В клиент-серверном варианте сеансы завершаются через консоль кластера серверов 1С, там же удобно установить блокировку сеансов на время работ.

Проверьте свободное место на диске. Загрузка .dt и развёртывание дампа СУБД требуют пространства, сопоставимого с размером самой базы, а иногда и большего — с учётом временных файлов и журналов транзакций. Нехватка места в середине процесса — частая причина повреждения базы при восстановлении.

Восстановление файловой базы и загрузка файла .dt через конфигуратор

Если у вас есть файл 1Cv8.1CD, восстановление сводится к копированию: создайте каталог, поместите туда файл, откройте окно запуска 1С, нажмите «Добавить» и укажите путь к каталогу. База готова к работе. Это самый быстрый способ, но он требует, чтобы копия делалась при остановленной работе пользователей — иначе файл мог быть скопирован в несогласованном состоянии.

Для загрузки .dt запустите конфигуратор нужной базы и откройте меню «Администрирование → Загрузить информационную базу». Укажите путь к файлу и подтвердите операцию. Платформа предупредит, что текущие данные будут замещены — соглашайтесь только если страховочная копия уже сделана. После завершения загрузки конфигуратор предложит перезапуститься.

Если база пустая и её ещё нет в списке, сначала создайте новую информационную базу без конфигурации (шаблон «создание информационной базы без конфигурации»), затем войдите в её конфигуратор и загрузите .dt. Это стандартный способ развернуть выгрузку на новом компьютере.

1. 1
   Завершите сеансы пользователей и убедитесь в монопольном доступе
2. 2
   Сделайте копию текущей базы, если в ней есть ценные данные
3. 3
   Откройте конфигуратор целевой базы
4. 4
   Выберите «Администрирование → Загрузить информационную базу» и укажите файл .dt
5. 5
   Дождитесь окончания загрузки и перезапустите конфигуратор
6. 6
   Проверьте версию конфигурации, справочники и несколько документов за последний период

Восстановление дампа PostgreSQL

Для клиент-серверных баз на PostgreSQL дамп обычно создавался утилитой pg_dump в собственном формате или в виде SQL-скрипта. Восстановление выполняется на стороне СУБД, а не через конфигуратор. Сначала создайте пустую базу данных, затем загрузите в неё дамп.

Для дампа в собственном формате используется pg_restore, для SQL-скрипта — psql. Пример команд:

createdb -U postgres mybase
pg_restore -U postgres -d mybase /backups/mybase.backup
# либо для SQL-скрипта:
psql -U postgres -d mybase -f /backups/mybase.sql

После успешного восстановления базу нужно привязать к серверу 1С. Откройте консоль администрирования серверов 1С, создайте новую информационную базу, укажите тип СУБД, имя сервера и имя восстановленной базы данных. Обязательно снимите флаг «Создать базу данных в случае её отсутствия» — иначе платформа может создать пустую базу поверх или выдать ошибку. Пользователь СУБД должен иметь права владельца на восстановленную базу.

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

Восстановление дампа MS SQL Server

Для баз на MS SQL Server дамп — это обычно файл .bak, созданный штатным механизмом BACKUP DATABASE. Восстановление выполняется через SQL Server Management Studio или командой RESTORE DATABASE. В SSMS: правой кнопкой по узлу «Базы данных» → «Восстановить базу данных» → выбрать устройство и указать файл .bak.

Если база с таким именем уже существует и вы восстанавливаете поверх неё, включите опцию перезаписи (WITH REPLACE) и убедитесь, что активных подключений к базе нет — иначе операция завершится ошибкой «база данных используется». При восстановлении на новый сервер проверьте пути к файлам данных и журнала: по умолчанию подставляются пути со старого сервера, их нужно исправить на вкладке «Файлы».

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

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

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

Для серверных баз полезно выполнить тестирование и исправление информационной базы через конфигуратор (пункт «Администрирование → Тестирование и исправление») в режиме проверки логической и ссылочной целостности. Это занимает время, но выявляет скрытые повреждения, которые могли возникнуть ещё при создании дампа.

Типичные ошибки и их последствия

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

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

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