Как восстановить базу 1С из SQL-бэкапа

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

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

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

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

Первое — убедитесь, что у вас есть целостный файл бэкапа. Если бэкап делался штатными средствами SQL Server, это файл с расширением .bak (полная копия) или набор файлов, если использовалась дифференциальная схема. Проверить целостность можно командой RESTORE VERIFYONLY в SQL Server Management Studio (SSMS) — она не восстанавливает данные, но подтверждает, что файл читается и не повреждён.

Второе — узнайте версию SQL Server, на которой создавался бэкап. Бэкап с более новой версии СУБД нельзя восстановить на более старую: например, копию с SQL Server 2019 не развернуть на SQL Server 2016. Обратная совместимость (со старой на новую) обычно работает без проблем.

Третье — оцените свободное место на диске. Для восстановления нужно место под сам файл бэкапа плюс объём развёрнутой базы данных. Если база в рабочем состоянии занимала 50 ГБ, на целевом сервере должно быть не меньше свободного пространства с запасом на рост и временные файлы.

Подготовка: остановка работы пользователей и резервная копия текущего состояния

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

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

Восстановление через SQL Server Management Studio

Самый наглядный способ — графический интерфейс SSMS. Подключитесь к экземпляру SQL Server под учётной записью с правами администратора (sysadmin) и выполните следующие шаги.

1. 1
   Откройте SSMS и подключитесь к нужному экземпляру SQL Server
2. 2
   Кликните правой кнопкой по узлу «Базы данных» и выберите «Восстановить базу данных»
3. 3
   Выберите источник «Устройство» и укажите путь к файлу .bak
4. 4
   На вкладке «Файлы» проверьте пути размещения файлов данных и журнала
5. 5
   На вкладке «Параметры» при восстановлении поверх существующей базы включите «Перезаписать существующую базу данных (WITH REPLACE)» и «Закрыть существующие соединения»
6. 6
   Нажмите «ОК» и дождитесь завершения операции
7. 7
   Проверьте, что база появилась в списке и находится в состоянии «в сети»

Опция «Закрыть существующие соединения» принудительно разрывает активные подключения к базе — используйте её, только если уверены, что пользователи завершили работу. Опция WITH REPLACE опасна тем, что перезаписывает базу без дополнительных предупреждений, поэтому дважды проверьте имя целевой базы перед запуском.

Если восстанавливаете цепочку «полный бэкап + разностный», сначала восстановите полный с параметром «Оставить базу данных неработоспособной» (WITH NORECOVERY), затем разностный — уже с восстановлением в рабочее состояние (WITH RECOVERY).

Восстановление командой T-SQL

Для автоматизации или работы без графического интерфейса удобнее скрипт T-SQL. Базовая команда выглядит так:

RESTORE DATABASE [MyBase1C]
FROM DISK = N'D:\Backups\MyBase1C_full.bak'
WITH REPLACE, RECOVERY, STATS = 10;

Если файлы данных нужно разместить в других каталогах (например, структура дисков нового сервера отличается), используйте параметр MOVE с указанием логических имён файлов. Узнать логические имена можно командой RESTORE FILELISTONLY FROM DISK = 'путь_к_бэкапу'.

RESTORE FILELISTONLY FROM DISK = N'D:\Backups\MyBase1C_full.bak';

RESTORE DATABASE [MyBase1C]
FROM DISK = N'D:\Backups\MyBase1C_full.bak'
WITH MOVE 'MyBase1C_Data' TO 'E:\SQLData\MyBase1C.mdf',
MOVE 'MyBase1C_Log' TO 'F:\SQLLog\MyBase1C.ldf',
REPLACE, RECOVERY;

Параметр STATS = 10 выводит прогресс восстановления с шагом в 10 процентов — удобно при работе с большими базами, чтобы понимать, что процесс идёт и не завис.

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

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

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

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

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

После восстановления откройте базу в конфигураторе. Успешный вход подтверждает, что связка «сервер 1С — SQL Server» работает. Затем запустите тестирование и исправление базы или хотя бы проверьте ключевые данные: откройте несколько документов за последние даты перед сбоем, сформируйте оборотно-сальтовую ведомость, сверьте итоги с ожидаемыми.

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

Типичные ошибки и их решение

Отдельная проблема — так называемые «осиротевшие» пользователи после переноса базы на другой сервер. Пользователь базы данных существует, но не связан с логином на уровне сервера. Решается созданием логина с тем же именем и выполнением процедуры сопоставления (sp_change_users_login или ALTER USER ... WITH LOGIN).

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