Как загрузить 1С из резервной копии

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

Главное правило перед началом: никогда не восстанавливайте копию «поверх» рабочей базы без предварительной выгрузки текущего состояния. Если в процессе что-то пойдёт не так, вы рискуете потерять и старые, и новые данные. Сначала создайте страховочную копию текущей базы, затем приступайте к восстановлению.

Ниже разобраны оба сценария — для файлового и клиент-серверного варианта работы, а также проверка результата и типичные ошибки, из-за которых восстановление завершается неудачей.

Определите формат резервной копии

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

Если копия делалась средствами СУБД, вы увидите файлы резервных копий SQL Server (.bak) или архивы, созданные pg_dump для PostgreSQL. Такие копии восстанавливаются только на ту же СУБД и желательно на ту же или более новую версию сервера. Наконец, копия файловой базы может быть просто копией каталога с файлом 1Cv8.1CD — её достаточно вернуть на место и прописать в списке баз.

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

До начала загрузки завершите работу всех пользователей в базе. В файловом варианте открытые сеансы заблокируют файл, в клиент-серверном — восстановление базы на SQL-сервере требует монопольного доступа. Проверьте активные сеансы в консоли кластера или через «Администрирование → Активные пользователи» в клиенте 1С.

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

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

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

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

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

Для автоматизации можно использовать пакетный режим конфигуратора с параметром RestoreIB, что удобно для скриптов обслуживания.

"C:\Program Files\1cv8\8.3.22.1750\bin\1cv8.exe" DESIGNER /F"D:\Bases\Trade" /RestoreIB "D:\Backup\trade_copy.dt"

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

Восстановление копии средствами СУБД

MS SQL Server

Откройте SQL Server Management Studio, подключитесь к серверу и в контекстном меню узла «Базы данных» выберите «Восстановить базу данных». Укажите источник — устройство с файлом .bak, задайте имя целевой базы. Если восстанавливаете поверх существующей базы, на вкладке параметров включите опцию перезаписи и переведите базу в однопользовательский режим или завершите активные подключения.

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

PostgreSQL

Для PostgreSQL создайте пустую базу данных в pgAdmin, затем восстановите в неё копию командой pg_restore (для архивов в собственном формате) или psql (для текстовых выгрузок). Учтите, что база для 1С должна создаваться с правильными параметрами локали и кодировки — проще всего создать её через консоль кластера 1С, а затем загрузить в неё данные из копии.

Восстановление файловой базы из копии каталога

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

Не восстанавливайте файловую базу, пока кто-то работает в исходном каталоге, и не храните восстановленную копию в том же сетевом каталоге с прежним именем — пользователи могут по ошибке продолжить работу в старой версии. Разнесите базы по разным папкам и дайте им понятные названия в списке, например с пометкой «восстановлено» и датой.

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

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

Для глубокой проверки запустите в конфигураторе «Администрирование → Тестирование и исправление» в режиме проверки логической целостности. На клиент-серверных базах полезно выполнить реиндексацию и проверку целостности средствами СУБД. Если база восстановлена для отчётности, дополнительно сформируйте регламентированные отчёты за последний закрытый период и сравните с ранее сданными.

Типичные ошибки при восстановлении

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

Отдельный класс проблем — несовпадение версий: попытка загрузить .dt, выгруженный на новой платформе, в старую, или восстановить .bak с нового SQL Server на старый. Наконец, после восстановления SQL-копии нередко забывают выдать права учётной записи сервера 1С на новую базу, из-за чего клиенты не могут подключиться.

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