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

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

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

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

Для восстановления потребуется сам файл резервной копии (обычно с расширением .bak, созданный штатным средством BACKUP DATABASE или планом обслуживания SQL Server), доступ к серверу СУБД с правами, достаточными для операции RESTORE (роль sysadmin или dbcreator), и возможность остановить работу пользователей с базой. Также понадобится доступ к консоли администрирования сервера 1С, если база подключается через кластер.

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

Как проверить резервную копию перед восстановлением

Прежде чем затирать данные, убедитесь, что копия читается и содержит нужную базу на нужный момент времени. Для этого используется команда RESTORE HEADERONLY, которая показывает состав файла копии: имя базы, дату создания, тип копии (полная, разностная, журнал).

RESTORE HEADERONLY FROM DISK = N'D:\Backups\trade_base.bak';
RESTORE VERIFYONLY FROM DISK = N'D:\Backups\trade_base.bak';

Команда RESTORE VERIFYONLY дополнительно проверяет целостность файла копии. Это не гарантирует успешного восстановления на сто процентов, но отсекает битые и обрезанные файлы. Если копия хранится на сетевом ресурсе, скопируйте её на локальный диск сервера СУБД — это ускорит восстановление и исключит обрывы по сети.

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

SQL Server не позволит восстановить базу поверх существующей, пока к ней есть активные подключения. Перед восстановлением сообщите пользователям о работах, заблокируйте новые сеансы на сервере 1С (в консоли кластера — свойства информационной базы, параметр «Блокировка начала сеансов») и завершите активные соединения.

Оставшиеся процессы на стороне SQL Server можно завершить принудительно, переведя базу в однопользовательский режим:

ALTER DATABASE [trade_base] SET SINGLE_USER WITH ROLLBACK IMMEDIATE;

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

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

Самый наглядный способ — графический интерфейс SSMS. Подключитесь к экземпляру SQL Server, откройте контекстное меню узла «Базы данных» и выберите «Восстановить базу данных» (Restore Database). Далее укажите источник — устройство с файлом .bak, выберите нужный набор копий из списка и проверьте пути к файлам данных и журнала на вкладке «Файлы».

1. 1
   Подключитесь к экземпляру SQL Server под учётной записью с правами sysadmin
2. 2
   Правый клик по «Базы данных» → «Восстановить базу данных»
3. 3
   Выберите источник «Устройство» и укажите файл .bak
4. 4
   Проверьте целевое имя базы и пути к файлам MDF/LDF
5. 5
   На странице «Параметры» отметьте «Перезаписать существующую базу» (WITH REPLACE), если восстанавливаете поверх
6. 6
   Снимите флажок «Создать резервную копию заключительного фрагмента журнала», если база повреждена и недоступна
7. 7
   Нажмите OK и дождитесь сообщения об успешном восстановлении

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

Восстановление с помощью T-SQL

Скриптовый способ удобен для автоматизации и для случаев, когда SSMS недоступен. Базовая команда восстановления полной копии выглядит так:

RESTORE DATABASE [trade_base]
FROM DISK = N'D:\Backups\trade_base.bak'
WITH REPLACE,
     MOVE N'trade_base'     TO N'D:\SQLData\trade_base.mdf',
     MOVE N'trade_base_log' TO N'D:\SQLData\trade_base_log.ldf',
     RECOVERY,
     STATS = 10;

Параметр MOVE указывает новые пути к логическим файлам базы — узнать их имена можно из вывода RESTORE FILELISTONLY. STATS = 10 выводит прогресс восстановления каждые 10 процентов, что удобно для больших баз. Параметр RECOVERY переводит базу в рабочее состояние; если планируется накат разностных копий или журналов, последняя операция в цепочке должна быть с RECOVERY, все предыдущие — с NORECOVERY.

Подключение восстановленной базы к серверу 1С

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

Обратите внимание на учётную запись, под которой сервер 1С обращается к СУБД. На новом сервере SQL должна существовать соответствующая учётная запись с правами на базу. При восстановлении из копии сопоставление пользователей базы и логинов сервера может нарушиться (проблема «сирот» — orphaned users). Проверить и исправить это можно сопоставлением логина с пользователем базы через ALTER USER.

USE [trade_base];
ALTER USER [usr1c] WITH LOGIN = [srv1c_login];

Проверка результата и типичные ошибки

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

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

Ограничения и когда нужен специалист

Самостоятельное восстановление безопасно, если у вас есть проверенная копия, права администратора SQL Server и возможность остановить работу пользователей. Однако есть ситуации, где ошибка критична: повреждённая рабочая база без свежей копии (здесь сначала нужны попытки ремонта, а не восстановление), цепочки копий журналов с требованием восстановления на конкретный момент времени (point-in-time recovery), подозрение на аппаратную неисправность дисковой подсистемы.

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

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