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

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

Типовые сценарии, когда требуется восстановление: внезапное отключение питания сервера, переполнение диска, повреждение файлов базы данных (MDF/LDF), ошибочное удаление данных пользователем, неудачное обновление конфигурации, аппаратный сбой дисковой подсистемы. В большинстве случаев базу удаётся вернуть в рабочее состояние, если есть актуальная резервная копия или хотя бы целые файлы данных.

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

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

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

Проверьте состояние базы в SQL Server Management Studio (SSMS): раскройте список баз и посмотрите статус. Значки «Suspect», «Recovery Pending» или «Offline» указывают на проблему с файлами данных или журналом транзакций. Также проверьте свободное место на дисках, где лежат MDF и LDF, — переполнение диска частая причина остановки базы.

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

Восстановление из резервной копии SQL Server

Штатный и самый надёжный путь — восстановление из бэкапа, созданного средствами СУБД (BACKUP DATABASE). Такие копии обычно имеют расширение .bak. Не путайте их с выгрузкой .dt из конфигуратора: .bak восстанавливается через SQL Server, .dt — через 1С.

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

Если у вас настроена модель полного восстановления (Full recovery model) и сохранились бэкапы журналов транзакций, можно восстановить базу на конкретный момент времени (point-in-time recovery). Это полезно, когда данные испорчены пользователем: например, пометили на удаление документы за месяц в 14:30 — восстанавливаете полную копию, затем журналы до 14:29.

Восстановление через T-SQL

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

ALTER DATABASE [Base1C] SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
RESTORE DATABASE [Base1C]
FROM DISK = N'D:\Backup\Base1C_full.bak'
WITH REPLACE, RECOVERY;
DBCC CHECKDB ([Base1C]) WITH NO_INFOMSGS;

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

Восстановление без бэкапа: присоединение файлов и аварийный режим

Если резервной копии нет, но целы файлы MDF и LDF (например, переустановили SQL Server или переносите базу), используйте присоединение: в SSMS правой кнопкой по «Базы данных» → «Присоединить», укажите MDF-файл. SQL Server подхватит журнал автоматически, если он рядом.

Когда база в статусе Suspect и бэкапа нет, применяют аварийный режим (Emergency Mode). Он переводит базу в состояние «только чтение», позволяя скопировать данные или запустить DBCC CHECKDB с параметром REPAIR_ALLOW_DATA_LOSS. Название параметра говорит само за себя: восстановление идёт с потерей повреждённых данных — удаляются нечитаемые страницы. Использовать его стоит только как последнее средство и только на копии файлов.

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

Восстановление через выгрузку .dt из конфигуратора

Файл .dt — это выгрузка информационной базы средствами 1С (Конфигуратор → Администрирование → Выгрузить информационную базу). Он не зависит от СУБД и восстанавливается одинаково для файловых и SQL-баз. Если у вас есть свежая выгрузка .dt, восстановление сводится к созданию пустой базы и загрузке.

Порядок действий: создайте новую пустую базу данных в SQL Server (или позвольте 1С создать её при добавлении базы), откройте конфигуратор новой базы, выполните «Администрирование → Загрузить информационную базу» и укажите файл .dt. После загрузки выполните обновление конфигурации базы данных, если конфигуратор его запросит.

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

Восстановление связи сервера 1С и SQL-базы

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

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

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

Типичные ошибки и ограничения

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

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

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

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