Загрузка базы 1С из файла .dt и других резервных копий

Базу 1С 8.3 восстанавливают из архивной копии .dt в Конфигураторе: Администрирование → Загрузить информационную базу…, выбрать файл и подтвердить замену данных. Загружать лучше не поверх рабочей базы, а в новую пустую — так у вас остаётся путь назад, если копия окажется битой или не той датой.

Если архивная копия — это zip-архив с файлом 1Cv8.1CD или бэкап SQL Server / PostgreSQL, порядок другой. Ниже разобраны все три варианта, права на СУБД, частые сбои загрузки и способ проверить, что данные вернулись целиком.

Подготовка: что за копия у вас и куда её разворачивать

Сначала выясните, в каком виде хранится архивная копия. От этого зависит инструмент восстановления.

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

Перед загрузкой проверьте четыре вещи:

• 🔢 Версия платформы. Номер платформы, на которой вы загружаете .dt, должен быть не ниже номера той, где копию выгружали. Иначе загрузка прервётся.
• 💾 Место на диске. Файл .dt сжат. Развёрнутая база занимает в несколько раз больше, плюс временные файлы во время загрузки.
• 👥 Пользователи. Загрузка требует монопольного доступа: все сеансы базы-приёмника нужно завершить.
• 📁 Целевая база. Создайте отдельную пустую базу под восстановление и дайте ей понятное имя, например «Бухгалтерия_восст_0510».

Как восстановить файловую базу 1С из архива

Вариант 1. Загрузка файла .dt

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

База объёмом 2–3 ГБ на SSD грузится обычно за несколько минут. Большие базы — дольше. Прогресс внизу окна может долго стоять на месте, процесс при этом идёт. Не закрывайте Конфигуратор принудительно: недогруженная база непригодна к работе, загрузку придётся повторять.

Вариант 2. Распаковка zip-архива

Встроенное резервное копирование файловой базы складывает в архив сам файл 1Cv8.1CD. Восстанавливают его так:

1. Попросите всех пользователей выйти из базы.
2. Переименуйте текущий 1Cv8.1CD в каталоге базы, например в 1Cv8_old.1CD. Не удаляйте его.
3. Распакуйте архив и положите извлечённый 1Cv8.1CD в тот же каталог.
4. Откройте базу в режиме 1С:Предприятие и проверьте данные.

Если в каталоге базы лежит файл 1Cv8.1CL, его можно удалить после переименования старой базы — это файл блокировки, платформа создаст его заново.

💡 Удобнее подложить файл не в рабочий каталог, а в новый, и добавить его в список баз через Добавить… → Добавление в список существующей информационной базы. Так обе базы открываются рядом, и можно сравнить остатки.

Вариант 3. Восстановление из командной строки

Тот же .dt загружается без открытия Конфигуратора. Это удобно, когда восстанавливать приходится регулярно, например обновлять тестовую копию:

"C:\Program Files\1cv8\<версия>\bin\1cv8.exe" DESIGNER /F "D:\Bases\Buh_test" /N "Администратор" /P "пароль" /RestoreIB "D:\Backup\buh.dt" /Out "D:\Backup\restore.log" /DisableStartupDialogs

Результат загрузки пишется в файл, указанный в /Out. Если в базе нет пользователей, параметры /N и /P уберите.

Восстановление клиент-серверной базы 1С на SQL

У серверной базы два пути. Через .dt — универсально, но медленнее на больших объёмах. Через бэкап СУБД — быстрее, но только в ту же СУБД.

Через файл .dt

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

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

Через бэкап Microsoft SQL Server

1. В SQL Server Management Studio щёлкните правой кнопкой по Databases → Restore Database….
2. Выберите источник Device, укажите файл .bak.
3. В поле базы-назначения задайте новое имя, например buh_restore. На странице Files проверьте, что пути файлов данных и журнала не совпадают с рабочей базой.
4. После восстановления зарегистрируйте базу в кластере 1С: создайте информационную базу, указав имя базы данных buh_restore, но флажок «Создать базу данных в случае ее отсутствия» не ставьте.

Через бэкап PostgreSQL

Создайте пустую базу данных и разверните в неё дамп:

createdb -U postgres buh_restore
pg_restore -U postgres -d buh_restore /backup/buh.backup

Если дамп сделан в текстовом формате (.sql), используйте psql -U postgres -d buh_restore -f /backup/buh.sql. Затем так же зарегистрируйте базу в кластере 1С без создания новой базы данных.

Права в СУБД и пользователи восстановленной базы

Права пользователя СУБД

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

Учётная запись sa или postgres подойдёт для разового восстановления. Для постоянной работы лучше завести отдельного пользователя с правами только на свои базы.

При восстановлении .bak на другом сервере есть ловушка. Пользователь базы данных переносится внутри бэкапа, а логин сервера — нет. Пользователь оказывается «осиротевшим», и 1С не может подключиться. Проще всего заново назначить логину роль db_owner в восстановленной базе на странице User Mapping его свойств.

Пользователи 1С

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

Что проверить сразу после загрузки:

• 🔑 Пароли. Пароль администратора 1С — тот, что был на дату копии. Если его недавно меняли, работает старый.
• 🖥️ Аутентификация операционной системы. У пользователей с привязкой к доменной учётной записи проверьте, что на новом сервере тот же домен. Иначе вход по Windows не сработает.
• 🔒 Список пользователей в Конфигураторе. Он открывается через Администрирование → Пользователи. Если пользователей нет, база открывается без пароля — это нормально для небольших файловых баз.

Лицензии в .dt не входят. Они привязаны к компьютеру или серверу, а не к базе.

Сбои при загрузке архивной копии и что с ними делать

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

Проверка целостности после восстановления

Восстановленная база открылась — это ещё не значит, что данные в порядке. Проверьте её по шагам.

Техническая проверка

1. В Конфигураторе запустите Администрирование → Тестирование и исправление….
2. Для первого прогона отметьте только проверку логической и ссылочной целостности. В блоке исправлений выберите режим «не изменять». Так вы увидите проблемы, ничего не меняя.
3. Если ошибки найдены, решайте, исправлять ли их в этой базе или взять другую копию.

Для файловой базы есть ещё утилита chdbfl.exe в каталоге bin платформы. Она проверяет физическую целостность файла 1Cv8.1CD и запускается при закрытой базе.

Проверка данных

• 📅 Дата последних документов. Откройте журнал документов и отсортируйте по дате. Последний документ показывает, на какой момент сделана копия.
• 📊 Остатки. Сформируйте оборотно-сальдовую ведомость за последний закрытый период и сравните с отчётностью или с ведомостью из старой базы.
• 🔁 Обмены. Посмотрите номера сообщений в узлах обмена. Если копия старше последнего обмена, синхронизация с другими базами может задвоить или потерять данные — согласуйте с администратором, как её возобновлять.
• 🧩 Расширения и внешние обработки. Расширения конфигурации сохраняются в .dt вместе с базой. Внешние печатные формы, подключённые файлами, проверьте отдельно.

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

Автоматическое резервное копирование, чтобы было что восстанавливать

Восстановить можно только то, что сохранили. Ручная выгрузка раз в месяц не защищает от потери недели работы.

Файловая база

В БП 3.0 и других конфигурациях на БСП встроенная настройка находится в Администрирование → Обслуживание → Резервное копирование и восстановление. Там задают расписание, каталог и число хранимых копий. Работает она только для файлового варианта.

Второй способ — пакетная выгрузка .dt по расписанию Windows. Пример .bat:

@echo off
set V8="C:\Program Files\1cv8\<версия>\bin\1cv8.exe"
set DT=D:\Backup\buh_%date:~6,4%-%date:~3,2%-%date:~0,2%.dt
%V8% DESIGNER /F "D:\Bases\Buh" /N "Администратор" /P "пароль" /DumpIB %DT% /Out "D:\Backup\dump.log" /DisableStartupDialogs
forfiles /p "D:\Backup" /m *.dt /d -14 /c "cmd /c del @path"

Последняя строка удаляет копии старше 14 дней. Разбор %date% зависит от региональных настроек Windows: проверьте, что имя файла получается правильным, запустив скрипт вручную. Выгрузка требует монопольного доступа, поэтому ставьте задание на ночь.

Серверная база

Для SQL-баз основным средством служат копии самой СУБД:

• 🗄️ MS SQL Server — план обслуживания с полным бэкапом раз в сутки и, при модели восстановления Full, копиями журнала в течение дня.
• 🐘 PostgreSQL — pg_dump по расписанию cron или планировщика Windows.

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

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

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