Как восстановить базу данных 1С на SQL Server

Клиент-серверная база 1С физически хранится в СУБД — чаще всего Microsoft SQL Server. Поэтому восстановление такой базы выполняется средствами самого SQL Server: либо из резервной копии .bak, либо подключением файлов данных .mdf и журнала .ldf. Конфигуратор 1С в этой процедуре участвует только на финальном этапе — для проверки, что база открывается и работает корректно.

Главный риск при восстановлении — перезаписать рабочую базу устаревшей копией или потерять данные, накопленные после создания бэкапа. Поэтому перед любыми действиями нужно зафиксировать текущее состояние: сделать резервную копию существующей (пусть и повреждённой) базы и скопировать файлы .mdf/.ldf, если они доступны. Это «страховочный» слой, к которому можно вернуться при неудаче.

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

Определите, из чего будете восстанавливать базу

Порядок действий зависит от того, какие исходные данные у вас есть. Возможны три типичные ситуации: есть актуальный файл резервной копии .bak, есть только файлы базы .mdf и .ldf (например, скопированные с вышедшего из строя сервера), есть только выгрузка .dt, сделанная через конфигуратор. Каждый вариант требует своего подхода.

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

Подготовка: что сделать до восстановления

Первое действие — завершить все сеансы пользователей с базой. Открытые соединения блокируют операцию RESTORE, и восстановление завершится ошибкой «database is in use». Сеансы завершают через консоль кластера серверов 1С, через оснастку служб (остановка агента сервера 1С) или установкой базы в однопользовательский режим.

Второе обязательное действие — сохранить текущее состояние. Если база ещё доступна, сделайте полную резервную копию средствами SSMS. Если база недоступна, но файлы .mdf и .ldf читаются, скопируйте их на другой диск. Пока существует эта копия, любую ошибку при восстановлении можно откатить.

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

Восстановление из файла резервной копии .bak

Стандартный способ — графический мастер в SQL Server Management Studio. Откройте SSMS, подключитесь к экземпляру сервера, щёлкните правой кнопкой по узлу «Базы данных» и выберите «Восстановить базу данных». Укажите источник «Устройство» и путь к файлу .bak. Если восстанавливаете поверх существующей базы, на вкладке «Параметры» отметьте «Перезаписать существующую базу данных (WITH REPLACE)» — без этого флага операция будет отклонена.

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

Тот же результат даёт команда T-SQL, которая удобнее для автоматизации и повторяемых операций:

RESTORE DATABASE [TradeBase]
FROM DISK = N'D:\Backups\TradeBase_full.bak'
WITH REPLACE,
MOVE N'TradeBase' TO N'D:\SQLData\TradeBase.mdf',
MOVE N'TradeBase_log' TO N'D:\SQLData\TradeBase_log.ldf';

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

1. 1
   Завершите сеансы пользователей и сделайте копию текущего состояния базы
2. 2
   Откройте SSMS и проверьте свободное место на целевом диске
3. 3
   Выполните RESTORE FILELISTONLY, чтобы узнать логические имена файлов
4. 4
   Запустите RESTORE DATABASE с параметрами REPLACE и MOVE
5. 5
   Дождитесь сообщения об успешном завершении и проверьте статус базы
6. 6
   Откройте базу в 1С и выполните контрольную проверку данных

Восстановление присоединением файлов .mdf и .ldf

Если бэкапа нет, но сохранились файлы базы данных — например, их скопировали с отказавшего сервера, — базу можно присоединить к новому экземпляру SQL Server. В SSMS щёлкните правой кнопкой по узлу «Базы данных», выберите «Присоединить», добавьте файл .mdf. Файл журнала .ldf подтянется автоматически, если лежит рядом; если журнал потерян, его можно удалить из списка — SQL Server создаст новый пустой журнал, но это допустимо только если база была корректно закрыта перед копированием.

Критическое условие: файлы .mdf/.ldf должны быть скопированы при остановленной службе SQL Server или после отсоединения базы. Файлы, скопированные «на горячую» с работающего сервера, почти гарантированно несогласованны, и присоединить их не удастся. Если копия снята теневым копированием (VSS) — шансы выше, но проверка целостности обязательна.

После присоединения проверьте, что база перешла в статус ONLINE, и сразу выполните проверку целостности:

DBCC CHECKDB (N'TradeBase') WITH NO_INFOMSGS;

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

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

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

После подключения запустите конфигуратор и выполните тестирование и исправление информационной базы в режиме проверки логической целостности. Это выявит рассогласования на уровне 1С, которые не видны средствами SQL Server. Также полезно сверить ключевые показатели — остатки по складу, взаиморасчёты, обороты за последний закрытый период — с данными, известными пользователям.

Что делать, если база повреждена и бэкапа нет

Ситуация, когда база в статусе Suspect, а резервной копии нет, — самая тяжёлая. Первый шаг — перевести базу в аварийный режим: ALTER DATABASE [Имя] SET EMERGENCY. В этом режиме база доступна только для чтения, и можно попытаться выгрузить данные скриптами или средствами экспорта.

Далее выполняется DBCC CHECKDB с параметром REPAIR_ALLOW_DATA_LOSS после перевода базы в однопользовательский режим. Название параметра честно отражает суть: восстановление идёт с потерей данных — повреждённые страницы и цепочки записей удаляются. Для базы 1С это почти всегда означает потерю части документов или регистров, поэтому такой ремонт — крайняя мера, после которой обязательна полная сверка данных.

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

Профилактика: как не оказаться без бэкапа

Настройте регулярное резервное копирование средствами SQL Server: полные копии ежедневно, разностные или копии журнала транзакций — несколько раз в день. Для баз в полной модели восстановления (Full) копии журнала позволяют восстановить состояние на произвольный момент времени, а не только на момент последнего бэкапа.

Храните копии минимум на двух независимых носителях, один из которых физически отделён от сервера. И периодически выполняйте контрольное восстановление на тестовом сервере: бэкап, который ни разу не проверяли восстановлением, нельзя считать надёжным.

Часто задаваемые вопросы