Резервная копия 1С в SQL: как сделать бэкап правильно

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

Резервную копию SQL-базы 1С можно сделать несколькими способами: через графический интерфейс SQL Server Management Studio, командой T-SQL BACKUP DATABASE, автоматическим планом обслуживания или стандартной выгрузкой в файл .dt через конфигуратор. У каждого способа есть свои сценарии применения и ограничения.

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

Какие способы резервного копирования 1С на SQL существуют

Перед настройкой стоит определиться с инструментом. Выбор зависит от размера базы, допустимого простоя и требований к точке восстановления.

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

Как выбрать модель восстановления базы

Модель восстановления определяет, как SQL Server ведёт журнал транзакций и до какого момента можно восстановить данные. Посмотреть и изменить её можно в свойствах базы: правый клик по базе в Management Studio → «Свойства» → «Параметры» → поле «Модель восстановления».

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

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

Как сделать бэкап через SQL Server Management Studio

Это самый наглядный способ, подходящий для разовой копии. Убедитесь, что у вашей учётной записи есть роль sysadmin на сервере или права db_backupoperator на конкретную базу.

1. 1
   Откройте SQL Server Management Studio и подключитесь к экземпляру сервера
2. 2
   В обозревателе объектов разверните «Базы данных», найдите базу 1С
3. 3
   Щёлкните по базе правой кнопкой → «Задачи» → «Создать резервную копию»
4. 4
   Выберите тип копии: «Полная», проверьте путь назначения и при необходимости замените его на отдельный диск
5. 5
   На вкладке «Параметры носителя» включите «Проверить резервную копию после завершения»
6. 6
   Нажмите «ОК» и дождитесь сообщения об успешном завершении
7. 7
   Проверьте, что файл .bak появился по указанному пути и его размер сопоставим с размером базы

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

Как сделать бэкап командой T-SQL

Скрипт удобен для автоматизации через планировщик заданий Windows или агент SQL Server. Стандартная команда полного бэкапа с проверкой выглядит так:

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

Опция COMPRESSION уменьшает размер файла и ускоряет копирование по сети (доступна не во всех редакциях SQL Server — проверьте свою). CHECKSUM заставляет сервер проверять контрольные суммы страниц при записи, что помогает выявить повреждения на этапе бэкапа, а не при восстановлении.

Для разностной копии добавьте WITH DIFFERENTIAL, для бэкапа журнала транзакций при модели Full используется команда BACKUP LOG. Имя файла удобно формировать с датой, чтобы копии не затирали друг друга и было видно хронологию.

Как автоматизировать бэкап планом обслуживания

Разовые копии вручную рано или поздно перестают делаться — автоматизация обязательна. В редакциях SQL Server Standard и выше используйте план обслуживания: «Управление» → «Планы обслуживания» → «Мастер планов обслуживания». Добавьте задачу «Резервное копирование базы данных», укажите базу, тип копии, папку назначения и расписание.

Типовое расписание для рабочей базы 1С: полный бэкап ежедневно ночью, разностные копии каждые 2–4 часа в рабочее время, при модели Full — бэкап журнала транзакций каждые 15–60 минут. Такая схема ограничивает потери данных при сбое и не перегружает сервер.

В бесплатной редакции Express агента SQL Server нет, поэтому автоматизацию делают через sqlcmd со скриптом BACKUP DATABASE и планировщик заданий Windows. Дополнительно настройте удаление старых копий (задача «Очистка после обслуживания» или команда удаления в скрипте), иначе диск под бэкапы заполнится.

Как проверить, что резервная копия рабочая

Наличие файла .bak ещё не гарантирует, что из него можно восстановиться. Проверка делится на два уровня: контроль целостности и тестовое восстановление.

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

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

Когда нужна выгрузка .dt и как её сделать

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

Файл .dt незаменим при переносе базы между разными СУБД (например, с SQL Server на PostgreSQL), при смене версии платформы или при передаче базы стороннему специалисту. Но у него есть ограничения: нет инкрементальных копий, длительное время выполнения и исторически известные случаи проблем с загрузкой очень больших выгрузок.

Типичные ошибки при резервном копировании 1С на SQL

Отдельно отметим мониторинг: настройте уведомления об ошибках заданий бэкапа (операторы и почтовые оповещения в агенте SQL Server или внешний скрипт проверки). Система резервного копирования, о сбоях которой никто не узнаёт, эквивалентна её отсутствию.

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