Настройка бэкапа 1С 8.3 на SQL Server: пошаговая инструкция

Средства 1С для резервного копирования — выгрузка .dt через Конфигуратор — требуют монопольного доступа и останавливают работу пользователей. На базе 20 ГБ выгрузка занимает 15-30 минут. Для продуктивного сервера с 10+ пользователями это неприемлемо.

Бэкап 1С SQL Server средствами СУБД решает обе проблемы: работает без остановки и завершается за 2-5 минут.

В этой статье: стратегия резервного копирования базы 1С на SQL Server, настройка через Maintenance Plan и T-SQL, автоматизация через SQL Server Agent, проверка и восстановление, хранение копий. Результат — автоматический бэкап с ротацией, проверкой целостности и копированием на удалённое хранилище.

Статья для администраторов, которые уже работают с клиент-серверной архитектурой 1С на SQL Server. Если вы ещё выбираете СУБД — начните с сравнения SQL Server и PostgreSQL для 1С. Общий обзор методов резервного копирования 1С 8.3 — в полном руководстве по бэкапу 1С.

Стратегия резервного копирования базы 1С на SQL Server

SQL Server поддерживает три типа бэкапов. Каждый следующий уровень сокращает объём копируемых данных и уменьшает RPO — максимально допустимую потерю данных при сбое.

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

Дифференциальный бэкап копирует только изменённые страницы данных после последнего полного. При активной работе 50 пользователей за 4 часа изменяется 10-20% базы. Дифференциальный бэкап в 5-10 раз меньше полного — создаётся быстрее и не мешает пользователям.

Лог транзакций — ключ к point-in-time recovery. Позволяет восстановить базу на конкретную секунду. Если в 14:35 кто-то удалил все документы за месяц — восстанавливаете базу на 14:34. Для работы логов транзакций модель восстановления базы должна быть FULL, а не SIMPLE.

Модель восстановления: FULL vs SIMPLE

Модель восстановления определяет, что SQL Server записывает в лог транзакций и как управляет его размером.

Для продуктивных баз 1С используйте FULL. Для тестовых и разработческих — SIMPLE (меньше обслуживания, меньше занимает место). Проверить и переключить модель:

-- Проверить текущую модель восстановления
SELECT name, recovery_model_desc
FROM sys.databases
WHERE name = 'MyBase1C';

-- Переключить на FULL
ALTER DATABASE [MyBase1C] SET RECOVERY FULL;

-- После переключения — сделать полный бэкап (обязательно!)
BACKUP DATABASE [MyBase1C]
TO DISK = N'D:\Backup\MyBase1C_full.bak'
WITH COMPRESSION, INIT;

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

Рекомендуемое расписание

Расписание зависит от числа пользователей и допустимого RPO. Два проверенных варианта:

Для баз 1С с интенсивной работой (ERP, управление торговлей, 50+ пользователей) рекомендуем лог транзакций каждые 15 минут. Для бухгалтерии на 5-10 человек — каждые 30 минут достаточно.

Настройка бэкапа через Maintenance Plan

Maintenance Plan (план обслуживания) — графический способ настройки бэкапов в SQL Server Management Studio (SSMS). Подходит для администраторов, которые предпочитают GUI. Для работы требуется SQL Server Agent — он должен быть запущен и настроен на автозапуск.

Ограничение: Maintenance Plan доступен в SQL Server Standard и Enterprise. В Express Edition планов обслуживания нет — используйте T-SQL + Планировщик задач Windows. Подробнее о различиях редакций — в сравнении редакций SQL Server для 1С.

Создание плана обслуживания

Откройте SSMS, подключитесь к серверу. В Object Explorer раскройте Management → Maintenance Plans. Правый клик → New Maintenance Plan. Назовите план: 1C_Backup_Plan.

В конструкторе плана создайте три подплана (subplans) — по одному на каждый тип бэкапа:

1. Full Backup — расписание: ежедневно в 01:00. Задача: Back Up Database (Full). Базы: выбрать все базы 1С. Папка: D:\Backup\Full\. Включить сжатие (Compress backup). Расширение: .bak
2. Diff Backup — расписание: каждые 4 часа (06:00, 10:00, 14:00, 18:00, 22:00). Задача: Back Up Database (Differential). Те же базы. Папка: D:\Backup\Diff\
3. Log Backup — расписание: каждые 15 минут. Задача: Back Up Database (Transaction Log). Те же базы. Папка: D:\Backup\Log\

Добавление очистки старых файлов

Без очистки бэкапы заполнят диск за неделю. Добавьте задачу Maintenance Cleanup Task в каждый подплан:

• Full: удалять файлы .bak старше 14 дней из D:\Backup\Full\
• Diff: удалять файлы .bak старше 3 дней из D:\Backup\Diff\
• Log: удалять файлы .trn старше 3 дней из D:\Backup\Log\

Соедините задачи стрелками в конструкторе: Back Up Database → Maintenance Cleanup Task. Стрелка «On success» — очистка выполняется только после успешного бэкапа.

Добавление проверки целостности

В подплан Full Backup добавьте задачу Check Database Integrity перед бэкапом. Она запускает DBCC CHECKDB — проверяет структуру базы на повреждения. Если обнаружены ошибки, бэкап не создастся (зачем бэкапить повреждённую базу). Порядок: Check Database Integrity → Back Up Database (Full) → Maintenance Cleanup Task.

DBCC CHECKDB на базе 20 ГБ занимает 5-15 минут. На базах 50+ ГБ может занять час. Учитывайте это при настройке расписания ночного бэкапа.

Настройка бэкапа через T-SQL скрипты

T-SQL даёт полный контроль над процессом бэкапа. Скрипты работают в любой редакции SQL Server, включая Express. Удобно для серверов с несколькими базами 1С и для стандартизации настроек.

Полный бэкап с сжатием

-- Полный бэкап одной базы 1С
DECLARE @db NVARCHAR(128) = N'MyBase1C'
DECLARE @path NVARCHAR(512)
DECLARE @ts NVARCHAR(20) = FORMAT(GETDATE(), 'yyyy-MM-dd_HHmm')

SET @path = N'D:\Backup\Full\' + @db + N'_full_' + @ts + N'.bak'

BACKUP DATABASE @db
TO DISK = @path
WITH COMPRESSION, INIT, CHECKSUM,
     NAME = @db + N'-Full-' + @ts,
     STATS = 10;

-- Проверить целостность бэкапа
RESTORE VERIFYONLY FROM DISK = @path WITH CHECKSUM;

Опция CHECKSUM добавляет контрольную сумму в файл бэкапа. При восстановлении SQL Server проверит, что файл не повреждён. Опция COMPRESSION сжимает бэкап в 3-5 раз — база 20 ГБ превращается в файл 4-7 ГБ.

Дифференциальный бэкап

-- Дифференциальный бэкап
DECLARE @db NVARCHAR(128) = N'MyBase1C'
DECLARE @path NVARCHAR(512)
DECLARE @ts NVARCHAR(20) = FORMAT(GETDATE(), 'yyyy-MM-dd_HHmm')

SET @path = N'D:\Backup\Diff\' + @db + N'_diff_' + @ts + N'.bak'

BACKUP DATABASE @db
TO DISK = @path
WITH DIFFERENTIAL, COMPRESSION, INIT, CHECKSUM,
     NAME = @db + N'-Diff-' + @ts,
     STATS = 10;

Бэкап лога транзакций

-- Бэкап лога транзакций
DECLARE @db NVARCHAR(128) = N'MyBase1C'
DECLARE @path NVARCHAR(512)
DECLARE @ts NVARCHAR(20) = FORMAT(GETDATE(), 'yyyy-MM-dd_HHmm')

SET @path = N'D:\Backup\Log\' + @db + N'_log_' + @ts + N'.trn'

BACKUP LOG @db
TO DISK = @path
WITH COMPRESSION, INIT, CHECKSUM,
     NAME = @db + N'-Log-' + @ts,
     STATS = 10;

Бэкап лога транзакций работает только при модели восстановления FULL. Если модель SIMPLE — SQL Server вернёт ошибку: BACKUP LOG cannot be performed because there is no current database backup. Проверьте модель и при необходимости переключите (см. раздел выше).

Бэкап всех баз 1С одним скриптом

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

-- Полный бэкап всех пользовательских баз
DECLARE @dbname NVARCHAR(128), @path NVARCHAR(512)
DECLARE @ts NVARCHAR(20) = FORMAT(GETDATE(), 'yyyy-MM-dd_HHmm')

DECLARE db_cursor CURSOR FOR
SELECT name FROM sys.databases
WHERE database_id > 4       -- пропустить системные (master, msdb, model, tempdb)
  AND state = 0             -- только онлайн
  AND name NOT LIKE 'ReportServer%'

OPEN db_cursor
FETCH NEXT FROM db_cursor INTO @dbname
WHILE @@FETCH_STATUS = 0
BEGIN
    SET @path = N'D:\Backup\Full\' + @dbname + N'_full_' + @ts + N'.bak'
    BACKUP DATABASE @dbname TO DISK = @path
    WITH COMPRESSION, INIT, CHECKSUM, STATS = 10
    FETCH NEXT FROM db_cursor INTO @dbname
END
CLOSE db_cursor
DEALLOCATE db_cursor

Ротация старых бэкапов (T-SQL)

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

-- Удалить файлы бэкапов старше 14 дней
DECLARE @cutoff DATETIME = DATEADD(DAY, -14, GETDATE())

EXECUTE master.dbo.xp_delete_file
    0,                          -- тип: файлы бэкапов
    N'D:\Backup\Full\',         -- каталог
    N'bak',                     -- расширение
    @cutoff,                    -- удалить старше этой даты
    1                           -- включая подкаталоги

EXECUTE master.dbo.xp_delete_file
    0, N'D:\Backup\Diff\', N'bak', DATEADD(DAY, -3, GETDATE()), 1

EXECUTE master.dbo.xp_delete_file
    0, N'D:\Backup\Log\', N'trn', DATEADD(DAY, -3, GETDATE()), 1

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

Автоматизация через SQL Server Agent

SQL Server Agent — встроенный планировщик задач SQL Server. Запускает T-SQL скрипты по расписанию, отправляет уведомления при ошибках, ведёт журнал выполнения. Доступен в Standard и Enterprise. В Express Edition Agent отсутствует — используйте Планировщик задач Windows (описано ниже).

Создание задания (Job) для полного бэкапа

В SSMS: SQL Server Agent → Jobs → New Job. Три вкладки:

1. General: Name = 1C_Full_Backup, Owner = sa, Category = Database Maintenance
2. Steps: New Step → Type: T-SQL → Database: master → вставьте скрипт полного бэкапа всех баз (из раздела выше) + скрипт ротации
3. Schedules: New Schedule → Frequency: Daily, Time: 01:00:00

Создайте аналогичные задания для дифференциального бэкапа (каждые 4 часа) и лога транзакций (каждые 15 минут). Итого три задания в SQL Server Agent.

Настройка уведомлений

SQL Server Agent умеет отправлять email при сбое задания. Для этого настройте Database Mail:

1. Management → Database Mail → Configure. Создайте профиль и SMTP-аккаунт
2. SQL Server Agent → Properties → Alert System → включите Mail Profile
3. SQL Server Agent → Operators → New Operator. Укажите email администратора
4. В каждом задании → Notifications → Email: On failure → выберите оператора

При сбое бэкапа вы получите email с описанием ошибки и временем события. Без уведомлений вы узнаете о проблеме, когда база уже потеряна — а бэкапы не создавались три недели.

SQL Server Express: бэкап через Планировщик Windows

В Express Edition нет SQL Server Agent. Используйте Планировщик задач Windows + sqlcmd:

:: backup-1c-full.cmd — вызов из Планировщика задач Windows
@echo off
set TIMESTAMP=%date:~6,4%-%date:~3,2%-%date:~0,2%_%time:~0,2%%time:~3,2%
set TIMESTAMP=%TIMESTAMP: =0%

sqlcmd -S localhost\SQLEXPRESS -Q "BACKUP DATABASE [MyBase1C] TO DISK = N'D:\Backup\Full\MyBase1C_full_%TIMESTAMP%.bak' WITH COMPRESSION, INIT, CHECKSUM" -b

if %ERRORLEVEL% NEQ 0 (
    echo BACKUP FAILED at %date% %time% >> D:\Backup\backup-errors.log
    exit /b 1
)

Создайте задачу в Планировщике: Триггер — ежедневно в 01:00. Действие — cmd /c D:\Scripts\backup-1c-full.cmd. Запускайте от учётной записи с правами sysadmin на SQL Server.

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

Бэкап без проверенного восстановления — иллюзия. Файл может быть повреждён, скрипт мог упасть без уведомления, права доступа сменились. Единственный способ убедиться — восстановить бэкап и открыть базу в 1С.

RESTORE VERIFYONLY — быстрая проверка

-- Проверить целостность файла бэкапа (без восстановления)
RESTORE VERIFYONLY
FROM DISK = N'D:\Backup\Full\MyBase1C_full_2026-03-15_0100.bak'
WITH CHECKSUM;

-- Посмотреть содержимое файла бэкапа
RESTORE HEADERONLY
FROM DISK = N'D:\Backup\Full\MyBase1C_full_2026-03-15_0100.bak';

-- Посмотреть логические файлы базы (нужно для MOVE при восстановлении)
RESTORE FILELISTONLY
FROM DISK = N'D:\Backup\Full\MyBase1C_full_2026-03-15_0100.bak';

VERIFYONLY проверяет структуру файла — не повреждён ли заголовок, совпадает ли контрольная сумма. Занимает 1-2 минуты. Но не гарантирует, что данные корректны. Для полной уверенности — тестовое восстановление.

DBCC CHECKDB — проверка целостности базы

-- Проверить целостность текущей базы
DBCC CHECKDB ('MyBase1C') WITH NO_INFOMSGS, ALL_ERRORMSGS;

-- Для больших баз (50+ ГБ) — только физическая проверка (быстрее)
DBCC CHECKDB ('MyBase1C') WITH PHYSICAL_ONLY, NO_INFOMSGS;

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

Восстановление базы 1С из полного бэкапа

-- Восстановление в ту же базу (перезапись)
RESTORE DATABASE [MyBase1C]
FROM DISK = N'D:\Backup\Full\MyBase1C_full_2026-03-15_0100.bak'
WITH REPLACE, RECOVERY, STATS = 10;

-- Восстановление в новую базу (для проверки)
RESTORE DATABASE [MyBase1C_Test]
FROM DISK = N'D:\Backup\Full\MyBase1C_full_2026-03-15_0100.bak'
WITH RECOVERY, STATS = 10,
     MOVE N'MyBase1C' TO N'D:\MSSQL\Data\MyBase1C_Test.mdf',
     MOVE N'MyBase1C_log' TO N'D:\MSSQL\Log\MyBase1C_Test_log.ldf';

Опция MOVE обязательна при восстановлении в новую базу — иначе SQL Server попытается записать файлы поверх рабочей базы. Логические имена файлов (MyBase1C и MyBase1C_log) узнайте через RESTORE FILELISTONLY.

Восстановление с цепочкой бэкапов (point-in-time)

Полная цепочка: полный бэкап → последний дифференциальный → все логи транзакций после него. Каждый шаг (кроме последнего) выполняется с NORECOVERY — база остаётся в режиме восстановления и принимает следующий файл.

-- 1. Полный бэкап (NORECOVERY — ждём дифференциальный)
RESTORE DATABASE [MyBase1C]
FROM DISK = N'D:\Backup\Full\MyBase1C_full_2026-03-15_0100.bak'
WITH NORECOVERY, REPLACE,
     MOVE N'MyBase1C' TO N'D:\MSSQL\Data\MyBase1C.mdf',
     MOVE N'MyBase1C_log' TO N'D:\MSSQL\Log\MyBase1C_log.ldf';

-- 2. Последний дифференциальный (NORECOVERY — ждём логи)
RESTORE DATABASE [MyBase1C]
FROM DISK = N'D:\Backup\Diff\MyBase1C_diff_2026-03-15_1400.bak'
WITH NORECOVERY;

-- 3. Логи транзакций по порядку
RESTORE LOG [MyBase1C]
FROM DISK = N'D:\Backup\Log\MyBase1C_log_2026-03-15_1415.trn'
WITH NORECOVERY;

RESTORE LOG [MyBase1C]
FROM DISK = N'D:\Backup\Log\MyBase1C_log_2026-03-15_1430.trn'
WITH NORECOVERY;

-- 4. Последний лог — с RECOVERY и STOPAT (база становится доступной)
RESTORE LOG [MyBase1C]
FROM DISK = N'D:\Backup\Log\MyBase1C_log_2026-03-15_1445.trn'
WITH RECOVERY, STOPAT = '2026-03-15T14:34:00';

STOPAT останавливает восстановление на указанном моменте. Все транзакции после 14:34 будут отброшены. Это и есть point-in-time recovery — восстановление базы 1С до секунды перед ошибкой.

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

Хранение бэкапов

Локальный бэкап защищает от сбоя СУБД — повреждение файлов данных, ошибка обновления, случайное удаление. Но не защищает от отказа сервера, шифровальщика, пожара. Правило 3-2-1: три копии данных, два типа носителей, одна копия вне основной площадки.

Локальное хранение

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

Размер диска для бэкапов: база 20 ГБ × коэффициент сжатия 3-5x × количество хранимых копий. При хранении 14 полных + дифференциальные + логи — закладывайте 200-300 ГБ. HDD достаточно — скорость записи бэкапов не критична.

Сетевой диск (SMB/UNC)

SQL Server умеет писать бэкап напрямую на сетевую папку:

-- Бэкап напрямую на сетевое хранилище
BACKUP DATABASE [MyBase1C]
TO DISK = N'\\nas\backup\1C\MyBase1C_full.bak'
WITH COMPRESSION, INIT, CHECKSUM;

Для этого учётная запись SQL Server Agent должна иметь права записи на сетевую папку. Проверьте: Services → SQL Server Agent → свойства → учётная запись. Если SQL Server работает от LocalSystem — он не сможет писать на UNC-путь. Переключите на доменную или локальную учётную запись с правами на шару.

Облачное хранилище (S3)

Для копирования бэкапов в облако используйте rclone или aws s3 sync после создания локального бэкапа. Подходит для долгосрочного хранения — ежемесячные копии в Yandex Object Storage или MinIO.

:: Копирование бэкапов в S3 (после основного скрипта)
rclone sync D:\Backup\Full\ yandex-s3:my-bucket/1c-backup/full/ --min-age 1h
rclone sync D:\Backup\Diff\ yandex-s3:my-bucket/1c-backup/diff/ --min-age 1h

Добавьте эту команду в задание SQL Server Agent как второй шаг (тип CmdExec) после T-SQL-шага с бэкапом.

Сколько места нужно

Коэффициент сжатия зависит от типа данных. Базы 1С сжимаются хорошо — табличные данные, текст, числа дают коэффициент 3-5x. Если в базе много вложенных файлов (сканы, фото) — сжатие слабее, 2-3x.

Пошаговая инструкция: настройка бэкапа 1С на SQL Server

Типичные ошибки при бэкапе 1С на SQL Server

Разросшийся лог транзакций

Симптом: файл .ldf базы 1С вырос до десятков гигабайт, диск заполнен. Причина: модель восстановления FULL, но бэкап лога транзакций не настроен. SQL Server не усекает лог, пока вы не сделаете его бэкап.

Решение: сделайте бэкап лога — BACKUP LOG [MyBase1C] TO DISK = N'D:\Backup\Log\emergency.trn'. После этого SQL Server пометит пространство для повторного использования. Если лог уже занял весь диск и бэкап невозможен — переключите на SIMPLE (ALTER DATABASE [MyBase1C] SET RECOVERY SIMPLE), дождитесь checkpoint, затем верните FULL и сделайте полный бэкап.

Бэкап без CHECKSUM

Без опции CHECKSUM SQL Server не записывает контрольную сумму в файл бэкапа. При восстановлении вы не узнаете, повреждён файл или нет. Повреждение может произойти при копировании по сети, записи на неисправный диск, сбое файловой системы.

Решение: всегда добавляйте WITH CHECKSUM к команде BACKUP. И WITH CHECKSUM к RESTORE VERIFYONLY — тогда проверка сверит контрольные суммы страниц.

Бэкап на тот же RAID-массив

Бэкап базы 1С на тот же диск, где лежат файлы СУБД — не бэкап. Отказ контроллера RAID, шифровальщик, физическое повреждение — и вы теряете данные и копии одновременно.

Решение: отдельный физический диск для бэкапов + ежедневное копирование на сетевое хранилище. Правило 3-2-1. Подробнее о выборе дисков — в сравнении SAS, SSD и NVMe для сервера 1С.

Никогда не проверяли восстановление

Бэкапы создаются каждую ночь, файлы копируются на NAS — всё выглядит надёжно. А при аварии выясняется, что скрипт падал последние два месяца и писал пустые файлы. Или что файлы .bak повреждены при передаче по сети.

Решение: раз в месяц — тестовое восстановление. Восстановите последний полный бэкап в тестовую базу, откройте в 1С, проверьте документы за последний день. Занимает 15-30 минут, но исключает неприятный сюрприз при реальном сбое. Автоматизируйте: задание в SQL Server Agent, которое восстанавливает бэкап, запускает DBCC CHECKDB на тестовой базе и удаляет её.

Вопросы и ответы

Итог

Бэкап 1С SQL Server — три обязательных элемента. Первый: три типа бэкапов (полный + дифференциальный + лог транзакций) с моделью восстановления FULL. Второй: автоматизация через SQL Server Agent или Планировщик задач Windows с ротацией и уведомлениями.

Третий: проверка — DBCC CHECKDB еженедельно, тестовое восстановление ежемесячно.

Скорость бэкапа зависит от дисковой подсистемы. На NVMe полный бэкап 20 ГБ занимает 1-2 минуты, на SAS — 10-15 минут. Производительность дисков влияет и на время восстановления — а это время простоя бизнеса. Подробнее о выборе оборудования — в требованиях к серверу для 1С. Оптимизация настроек SQL Server для 1С — в руководстве по оптимизации.

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