Как настроить бэкап 1С 8.3 на SQL Server

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

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

Материал ориентирован на Microsoft SQL Server как наиболее распространённую СУБД для 1С 8.3, но логика расписаний и проверок применима и к PostgreSQL с поправкой на синтаксис pg_dump/pg_basebackup.

Чем бэкап SQL-базы отличается от выгрузки в .dt

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

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

Сравнение способов копирования

BACKUP DATABASE в SQL Server

Основной способ: быстро, без остановки работы, восстановление на момент времени. Требует прав на СУБД и настройки расписания.

Выгрузка в .dt

Подходит для переноса базы между серверами, переезда на другую СУБД или архивной копии раз в месяц. Требует монопольного доступа и долго работает на больших базах.

Копирование файлов .mdf/.ldf

Допустимо только при остановленной службе SQL Server или отсоединённой базе. На работающем сервере даёт повреждённую копию — не используйте как бэкап.

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

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

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

Простая модель (Simple) автоматически усекает журнал и подходит для тестовых баз и баз, где допустима потеря данных за период с последнего полного или разностного бэкапа. Разностные копии (differential) работают в обеих моделях и позволяют делать промежуточные бэкапы днём без копий журнала.

Настройка бэкапа через план обслуживания

Самый простой способ для администратора без опыта T-SQL — мастер планов обслуживания в SSMS. Он доступен в редакциях SQL Server Standard и выше (в Express агента SQL Server нет, об этом ниже).

1. Откройте SSMS, подключитесь к серверу, разверните «Управление» → «Планы обслуживания» и запустите мастер.
2. Добавьте задачу «Резервное копирование базы данных», выберите тип «Полная» и нужные базы 1С.
3. Укажите папку назначения — желательно на другом физическом диске или сетевом ресурсе.
4. Настройте расписание: полная копия — ежедневно ночью вне рабочей нагрузки.
5. Создайте второй план с типом «Резервное копирование журнала транзакций» и расписанием каждые 1–4 часа в рабочее время.
6. Добавьте задачу «Очистка после обслуживания», удаляющую файлы бэкапов старше заданного срока (например, 14 дней), чтобы диск не переполнялся.

После создания планов проверьте, что служба агента SQL Server запущена и стоит в режиме автозапуска: именно агент выполняет задания по расписанию. Если агент остановлен, планы существуют, но ни один бэкап не выполняется — это одна из самых частых причин «тихого» отсутствия копий.

1. 1
   Переведите базу в модель восстановления Full
2. 2
   Создайте задание полного бэкапа на ночь
3. 3
   Создайте задание бэкапа журнала транзакций каждые 1–4 часа днём
4. 4
   Настройте удаление файлов старше 14 дней
5. 5
   Убедитесь, что агент SQL Server запущен
6. 6
   Через день проверьте наличие файлов и выполните тестовое восстановление

Бэкап скриптом T-SQL и через агент SQL Server

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

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

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

Скрипт добавляется в задание агента: «Агент SQL Server» → «Задания» → «Создать задание» → шаг типа T-SQL → расписание. Учётная запись, от имени которой работает служба SQL Server, должна иметь права записи в целевую папку — для сетевых ресурсов это частая причина ошибок доступа.

Что делать на SQL Server Express и PostgreSQL

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

sqlcmd -S SERVER\SQLEXPRESS -Q "BACKUP DATABASE [MyBase1C] TO DISK='D:\Backup\base.bak' WITH INIT"

Для PostgreSQL, который всё чаще используют с 1С 8.3, штатный инструмент — pg_dump для логической копии или pg_basebackup с архивированием WAL для физической. Задание создаётся через cron (Linux) или Планировщик заданий (Windows). Учитывайте, что pg_dump создаёт нагрузку и на больших базах выполняется долго, поэтому для рабочих баз предпочтительнее физическое копирование с WAL.

Куда складывать копии и как организовать хранение

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

Ориентируйтесь на правило «3-2-1»: минимум три копии данных, на двух разных носителях, одна — вне основной площадки. Для 1С это обычно означает: локальный бэкап SQL Server, копия на NAS или файловом сервере и выгрузка в облачное хранилище с помощью robocopy, rclone или штатных средств хранилища.

Настройте ротацию: храните дневные копии 1–2 недели, а раз в месяц делайте «вечную» архивную копию (например, выгрузку .dt плюс полный бэкап) перед массовыми операциями — закрытием периода, обновлением конфигурации, свёрткой базы.

Проверка восстановления и контроль выполнения

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

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

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

Контрольные точки

Как проверить результат

Файлы бэкапов в папке назначения

Норма

Свежие файлы с ожидаемым размером появляются по расписанию

Тревожный признак

Файлов нет, размер аномально мал или дата устарела

Журнал задания агента SQL Server

Норма

Статус «Выполнено успешно»

Тревожный признак

Ошибки доступа, нехватки места или таймауты

Тестовое восстановление

Норма

База восстанавливается и открывается в 1С

Тревожный признак

Ошибки RESTORE, база не открывается, данных меньше ожидаемого

Свободное место на диске бэкапов

Норма

Запас места на несколько циклов копирования

Тревожный признак

Диск заполнен более чем на 85–90%

Типичные ошибки и их последствия

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

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

Можно ли делать бэкап базы 1С, пока пользователи работают?

Да, BACKUP DATABASE и BACKUP LOG в SQL Server выполняются без блокировки работы пользователей. Небольшое снижение производительности возможно, поэтому полную копию обычно ставят на ночь. А вот выгрузка в .dt через конфигуратор требует монопольного доступа и завершения всех сеансов.

Как часто нужно делать бэкап журнала транзакций?

Интервал определяется допустимой потерей данных: если потеря часа работы критична, ставьте копии журнала каждые 15–30 минут, если допустимо восстановление на середину дня — достаточно раз в 2–4 часа. Чем чаще копии, тем меньше потери при сбое, но больше файлов и нагрузка на диск.

Чем сжать файлы бэкапов, если редакция SQL Server не поддерживает COMPRESSION?

Используйте внешнее сжатие: после создания бэкапа архивируйте файл через 7-Zip или аналог в задании планировщика. Бэкапы баз 1С обычно сжимаются в несколько раз. Учтите, что на архивацию уходит время и временное дисковое пространство.

Нужен ли бэкап, если база работает на отказоустойчивом кластере или в Always On?

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

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

Восстановите последнюю полную копию с опцией NORECOVERY, затем последовательно примените копии журнала транзакций, а для последней укажите STOPAT с нужной датой и временем и опцию RECOVERY. После восстановления зарегистрируйте базу в консоли кластера 1С или добавьте её в список баз с новым именем.

Достаточно ли одной выгрузки .dt раз в неделю для небольшой базы?

Это рискованная схема: при сбое вы потеряете до недели работы, а сама выгрузка может быть повреждена, если её никто не проверял загрузкой. Даже для небольшой базы настройте ежедневный бэкап средствами СУБД или, для файлового варианта, автоматическое копирование файла 1Cv8.1CD по расписанию с проверкой целостности.