Как настроить автоматический бэкап базы 1С на MS SQL Server

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

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

Ниже разобраны два рабочих способа автоматизации: через план обслуживания (Maintenance Plan) в SQL Server Management Studio и через скрипты T-SQL с агентом SQL Server. Оба подхода надёжны, выбор зависит от редакции SQL Server и привычек администратора.

Подготовка: что проверить перед настройкой

Перед созданием заданий убедитесь, что служба агента SQL Server (SQL Server Agent) запущена и стоит в режиме автоматического запуска. Именно агент выполняет задания по расписанию; если он остановлен, никакие автоматические бэкапы работать не будут. Проверить службу можно через оснастку «Службы» Windows или в SQL Server Configuration Manager.

Второй момент — модель восстановления базы. Для рабочих баз 1С рекомендуется полная модель восстановления (Full), она позволяет делать бэкапы журнала транзакций и восстанавливать базу на произвольный момент времени. Проверить модель можно в свойствах базы в SSMS на вкладке «Параметры» (Options). Если задана простая модель (Simple), восстановление возможно только на момент последнего бэкапа.

Третье — место хранения. Копии нельзя держать на том же физическом диске, где лежат файлы самой базы: при отказе диска вы потеряете и базу, и бэкапы одновременно. Используйте отдельный дисковый массив, сетевую папку на другом сервере или NAS. Учётная запись службы SQL Server должна иметь права на запись в этот каталог — для сетевых путей используйте UNC-формат вида \\server\backup.

Способ 1: план обслуживания в SQL Server Management Studio

План обслуживания — самый простой путь, он создаётся мастером и не требует написания кода. Откройте SSMS, подключитесь к серверу, разверните узел «Управление» (Management), щёлкните правой кнопкой по «Планы обслуживания» (Maintenance Plans) и выберите «Мастер планов обслуживания».

В мастере задайте имя плана, выберите задачу «Резервное копирование базы данных» (Back Up Database), укажите тип «Полная» (Full), отметьте нужные базы 1С и пропишите целевой каталог. На шаге расписания задайте ежедневный запуск в нерабочее время, например в 2:00 ночи. После завершения мастер создаст задание агента SQL Server, которое будет выполняться автоматически.

Для разностных копий создайте второй план с типом «Разностная» (Differential) и расписанием, например, каждые 3–4 часа в рабочее время. Разностный бэкап содержит только изменения с момента последнего полного бэкапа, поэтому выполняется быстро и занимает меньше места.

1. 1
   Запустите агент SQL Server и проверьте автозапуск службы
2. 2
   Откройте мастер планов обслуживания в SSMS
3. 3
   Добавьте задачу полного бэкапа базы 1С с расписанием на ночь
4. 4
   Добавьте второй план с разностными копиями днём
5. 5
   Укажите каталог хранения на отдельном диске или сетевом ресурсе
6. 6
   Запустите задание вручную и убедитесь, что файл бэкапа создан

Способ 2: бэкап скриптом T-SQL через агент SQL Server

Ручной скрипт даёт больше контроля: можно формировать имя файла с датой, включать сжатие и проверку целостности. Этот способ особенно актуален для редакций, где конструктор планов обслуживания недоступен или неудобен.

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

BACKUP DATABASE [TradeBase] TO DISK = N'D:\Backup\TradeBase_FULL_' + FORMAT(GETDATE(), 'yyyyMMdd_HHmm') + '.bak' WITH COMPRESSION, CHECKSUM, INIT;

Чтобы автоматизировать выполнение, создайте новое задание в разделе «Агент SQL Server — Задания» (SQL Server Agent — Jobs). В задании добавьте шаг типа T-SQL с командой BACKUP, на вкладке «Расписания» задайте периодичность. В свойствах задания настройте уведомление оператору по электронной почте или запись в журнал при сбое — без этого вы не узнаете, что бэкапы перестали создаваться.

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

Бэкап журнала транзакций и восстановление на момент времени

Если база работает в полной модели восстановления, добавьте третье задание — бэкап журнала транзакций (BACKUP LOG) каждые 15–60 минут. Это даёт возможность восстановить базу не на момент последнего ночного бэкапа, а на любую минуту, например «на 14:35, за пять минут до ошибочного проведения документов».

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

Ротация копий и контроль свободного места

Бэкапы без очистки рано или поздно заполнят диск. Определите глубину хранения: типичная схема — ежедневные копии за последние 7–14 дней, еженедельные за месяц, ежемесячные за квартал. В планах обслуживания для удаления старых файлов есть задача «Очистка после обслуживания» (Maintenance Cleanup Task), где задаётся расширение файлов и возраст в днях.

При скриптовом подходе очистку делают командой xp_delete_file или отдельным шагом задания на PowerShell/cmd, удаляющим файлы старше заданного срока. После настройки ротации понаблюдайте за диском несколько недель: объём базы растёт, и запас свободного места должен покрывать рост с запасом.

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

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

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

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

Частая ошибка — настроить задание и забыть про уведомления. Задание может месяцами завершаться с ошибкой (кончилось место, изменился пароль учётной записи службы), а обнаружится это только в момент аварии. Настройте операторов и оповещения агента SQL Server либо регулярно просматривайте историю заданий.

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

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