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

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

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

Ниже разобраны оба подхода, настройка автоматического копирования по расписанию, проверка восстановления и ограничения, о которых важно знать до начала работы.

Как устроено хранение базы 1С на SQL Server

При создании информационной базы в клиент-серверном режиме 1С формирует на SQL Server базу данных с таблицами, индексами и служебными объектами. Физически это минимум два файла: основной файл данных (.mdf) и журнал транзакций (.ldf). Журнал фиксирует все изменения и позволяет восстановить базу на конкретный момент времени при соответствующей модели восстановления.

Ключевой параметр — модель восстановления (recovery model). В простой (Simple) модели журнал автоматически усекается, и восстановить базу можно только на момент последнего бэкапа. В полной (Full) модели журнал растёт до тех пор, пока не выполнено резервное копирование журнала, зато появляется возможность восстановления на произвольную точку во времени. Для рабочих баз 1С с важными данными обычно выбирают полную модель с регулярными бэкапами журнала; для тестовых баз достаточно простой.

Резервное копирование через SQL Server Management Studio

Самый наглядный способ сделать разовую копию — графический интерфейс SSMS. Подключитесь к серверу под учётной записью с правами на резервное копирование (роль sysadmin или db_backupoperator в конкретной базе), раскройте список баз, щёлкните правой кнопкой по нужной базе и выберите «Задачи» → «Создать резервную копию» (Tasks → Back Up).

В окне настройки укажите тип копии «Полная» (Full), проверьте имя базы и задайте путь к файлу .bak. Файл лучше сохранять на отдельный диск или сетевой ресурс — копия на том же диске, что и сама база, не защищает от отказа носителя. На вкладке параметров можно включить проверку копии после завершения (Verify backup) и сжатие, если оно не включено по умолчанию на сервере.

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

Копирование скриптом T-SQL

Для регулярных операций удобнее скрипт. Простейшая команда полного бэкапа выглядит так:

BACKUP DATABASE [MyBase1C]
TO DISK = N'D:\Backups\MyBase1C_full.bak'
WITH COMPRESSION, CHECKSUM, INIT;

Параметр COMPRESSION уменьшает размер файла и ускоряет операцию, CHECKSUM включает проверку контрольных сумм страниц при чтении, INIT перезаписывает файл. Если нужен журнал версий, вместо INIT используйте добавление копий в один файл с указанием имени набора, но на практике проще формировать имя файла с датой.

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

BACKUP LOG [MyBase1C]
TO DISK = N'D:\Backups\MyBase1C_log.trn'
WITH COMPRESSION;

Копии журнала делают чаще полного бэкапа (например, каждые 15–60 минут) — именно они определяют, насколько близко к моменту сбоя удастся восстановить данные.

BACKUP DATABASE [MyBase1C] TO DISK = N'D:\Backups\MyBase1C_full.bak' WITH COMPRESSION, CHECKSUM, INIT;

Настройка автоматического копирования по расписанию

Разовый бэкап не решает задачу защиты данных — копирование должно выполняться регулярно и без участия человека. В редакциях SQL Server Standard и выше для этого есть агент SQL Server и планы обслуживания (Maintenance Plans). В мастере планов обслуживания создаётся задача резервного копирования, выбираются базы, тип копии, расписание и срок хранения файлов с автоочисткой старых копий.

Если агент недоступен (редакция Express), скрипт T-SQL запускают через планировщик заданий Windows с помощью утилиты sqlcmd:

sqlcmd -S SERVER\INSTANCE -Q "BACKUP DATABASE [MyBase1C] TO DISK=N'D:\Backups\MyBase1C_%date%.bak' WITH COMPRESSION, INIT"

Типовой график для рабочей базы: полная копия ежедневно в нерабочее время, разностные копии (DIFFERENTIAL) в течение дня при большом объёме изменений, копии журнала — каждые 15–60 минут для баз в полной модели. Глубина хранения зависит от свободного места и требований к архиву, но минимум несколько последних полных копий держать стоит.

1. 1
   Выберите модель восстановления базы (Full для рабочих баз, Simple для тестовых)
2. 2
   Создайте скрипт BACKUP DATABASE с именем файла, включающим дату
3. 3
   Настройте задание в агенте SQL Server или планировщике Windows
4. 4
   Добавьте копирование журнала транзакций для модели Full
5. 5
   Настройте удаление устаревших файлов и копирование на внешнее хранилище
6. 6
   Проверьте выполнение задания и наличие файлов на следующий день

Выгрузка в .dt через конфигуратор как дополнительная мера

Выгрузка информационной базы выполняется в конфигураторе: меню «Администрирование» → «Выгрузить информационную базу». Результат — один файл с расширением .dt, содержащий данные и конфигурацию. Этот файл не привязан к SQL Server и загружается в любую базу с совместимой версией платформы, включая файловый вариант.

У способа есть жёсткие ограничения. Выгрузка требует монопольного режима — все пользователи должны выйти из базы. На больших базах процесс занимает заметное время и создаёт нагрузку на сервер. Кроме того, в .dt не попадают некоторые внешние данные (например, файлы, хранящиеся в томах вне базы, если используется такой режим).

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

Проверка копий и восстановление

Бэкап, который ни разу не восстанавливали, нельзя считать надёжным. Минимальная проверка без восстановления — команда RESTORE VERIFYONLY, которая читает файл и контролирует его целостность:

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

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

При восстановлении рабочей базы после сбоя сначала, если сервер ещё жив, делается копия «хвоста» журнала (tail-log backup), затем последовательно восстанавливаются последняя полная копия, последняя разностная (если есть) и все копии журнала по порядку. Вмешательство в рабочую базу без отдельной копии её текущего состояния недопустимо.

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

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

Ещё одна группа ошибок связана с правами: служба SQL Server работает под своей учётной записью, и именно ей нужны права записи в каталог бэкапов и на сетевой ресурс. Для сетевых путей используйте UNC-имена (\\server\share), а не подключённые диски — буквы дисков не видны из контекста службы.

Наконец, не стоит полагаться на антивирусное копирование, снапшоты дисков или файловые архиваторы как на единственную защиту. Без согласования с SQL Server такие копии могут оказаться несогласованными. Допустимый вариант — решения с поддержкой VSS, явно заявляющие согласованное копирование SQL Server, но и их нужно проверять тестовым восстановлением.

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