Восстановление базы 1С: файловая, SQL и через командную строку

Восстановить базу 1С — значит вернуть её из резервной копии. Для файловой базы это загрузка файла .dt через Конфигуратор (Администрирование → Загрузить информационную базу) либо возврат папки с файлом 1Cv8.1CD на место. Для клиент-серверной базы — восстановление SQL-базы из файла .bak средствами СУБД. Любой из способов затирает текущие данные целиком, поэтому сначала выведите из базы всех пользователей.

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

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

Что подготовить перед восстановлением

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

Главное требование — монопольный (исключительный) доступ. Пока в базе работает хоть один пользователь, загрузить .dt не получится: платформа выдаст отказ. Нужно убедиться, что все вышли, а фоновые и регламентные задания не выполняются.

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

Восстановление файловой базы из файла .dt

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

Способ 1. Просто вернуть папку. Если ваша резервная копия — это сохранённая папка базы целиком, восстановление сводится к замене. Закройте 1С у всех, кто работает с базой, удалите (или переименуйте) текущую папку и скопируйте на её место папку из бэкапа. Путь к базе в окне запуска при этом менять не нужно — он указывает на каталог. Это самый быстрый способ, потому что ничего не распаковывается.

Способ 2. Загрузить .dt через Конфигуратор. Если копия — это выгрузка 1Cv8.dt, действуйте так:

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

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

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

В клиент-серверном варианте данные хранятся не в файле 1Cv8.1CD, а в базе СУБД (чаще всего Microsoft SQL Server или PostgreSQL). Здесь два принципиально разных маршрута.

Маршрут А — восстановить базу СУБД из .bak. Это штатный бэкап SQL-сервера, он возвращает базу данных целиком и быстро. В SQL Server Management Studio: раскройте узел Databases, правой кнопкой по нужной базе → Tasks → Restore → Database, в качестве источника укажите файл .bak и запустите.

Чтобы восстановление прошло, к базе не должно быть подключений. Остановите службу сервера 1С или переведите базу SQL в однопользовательский режим на время восстановления.

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

Для PostgreSQL логика та же, меняются инструменты: копию восстанавливают средствами СУБД (через pgAdmin или консольными утилитами PostgreSQL), а не через SQL Server Management Studio. Если же у вас на руках .dt, разворачивать можно не думая о типе СУБД — путь через Конфигуратор одинаков для MS SQL и PostgreSQL.

Маршрут Б — загрузить .dt в серверную базу . Файл .dt загружается в клиент-серверную базу точно так же, как в файловую: Конфигуратор → Администрирование → Загрузить информационную базу. Этот путь медленнее, зато не зависит от типа и версии СУБД: выгрузка .dt переносится между MS SQL и PostgreSQL без переделок. Монопольный доступ к базе нужен так же, как и в файловом варианте.

Восстановление из командной строки без Конфигуратора

Когда восстановить нужно по расписанию, на сервере без графического интерфейса или сразу для нескольких баз, помогает запуск платформы в пакетном режиме. Файл .dt загружает утилита 1cv8 в режиме Конфигуратора (DESIGNER) ключом /RestoreIB.

Для файловой базы:

"C:\Program Files\1cv8\8.3.xx.xxxx\bin\1cv8.exe" DESIGNER ^
  /F"D:\Bases\MyBase" /N"Администратор" /P"пароль" ^
  /RestoreIB "D:\Backup\base.dt"

Для серверной базы вместо /F указывают адрес базы на кластере:

"C:\Program Files\1cv8\8.3.xx.xxxx\bin\1cv8.exe" DESIGNER ^
  /S"srv-1c\MyBase" /N"Администратор" /P"пароль" ^
  /RestoreIB "D:\Backup\base.dt"

Разберём ключи:

• DESIGNER — запуск в режиме Конфигуратора (именно он умеет грузить .dt).
• /F — путь к каталогу файловой базы; /S — адрес серверной базы вида сервер\имя.
• /N и /P — имя и пароль пользователя с правами администратора.
• /RestoreIB — загрузить указанный файл .dt (симметричный ключ выгрузки — /DumpIB).

Для восстановления через командную строку базе тоже нужен монопольный доступ. Если в ней кто-то работает, пакетный запуск завершится с ошибкой и ненулевым кодом возврата — его удобно ловить в bat-файле или планировщике.

Пакетный запуск удобно связать в цепочку: сначала тем же 1cv8 ключом /DumpIB снять свежую выгрузку текущего состояния (страховка), а уже следом выполнять /RestoreIB. Весь ход операции платформа пишет в служебный лог — путь к нему задаётся ключом /Out, и при неожиданном сбое именно этот файл подскажет, на каком шаге всё остановилось.

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

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

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

Ошибки при восстановлении и как их устранить

Чаще всего восстановление спотыкается не на самой загрузке, а на доступе к базе и несовпадении версий.

Отдельно про повреждённые базы: если из копии восстановилась база с ошибками (нечитаемые документы, обрывы при открытии), в Конфигураторе есть Администрирование → Тестирование и исправление информационной базы. Эта операция тоже требует монопольного доступа и может идти долго — запускайте её не на рабочем времени.

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

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

Файловая база. Копию делают тремя способами:

• встроенным механизмом в разделе Администрирование → Обслуживание — там настраивается резервное копирование по расписанию (пункт может называться немного иначе в зависимости от конфигурации);
• пакетной выгрузкой .dt из командной строки ключом /DumpIB в планировщике Windows;
• простым копированием папки базы скриптом — но только когда в базе никто не работает , иначе копия получится в несогласованном состоянии.

Клиент-серверная база . Здесь надёжнее штатные средства СУБД. В MS SQL Server настраивают план обслуживания (Maintenance Plan): полная копия раз в сутки, разностные в течение дня и при необходимости резервные копии журнала транзакций. Это позволяет откатиться не только на сутки назад, но и на нужный момент.

Несколько правил, которые экономят нервы в день аварии:

1. Храните копии не на том же диске и не на том же сервере, где живёт база. Сбой диска уносит и базу, и копию рядом с ней.
2. Держите несколько поколений копий (например, за последние 7 дней), а не одну «последнюю».
3. Хотя бы раз в квартал разворачивайте копию в тестовую базу и проверяйте, что она открывается и данные целы. Непроверенная копия — это не копия.
4. Записывайте, на каком релизе платформы и конфигурации сделана выгрузка, — пригодится при восстановлении.