Как сделать бэкап базы 1С на SQL-сервере

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

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

Ниже разобраны практические сценарии: ручное копирование через Management Studio, команды T-SQL, настройка автоматического плана обслуживания, хранение копий и контроль их работоспособности. Инструкции применимы к MS SQL Server — наиболее распространённой СУБД для 1С; в конце кратко затронуты особенности PostgreSQL.

Почему выгрузка DT не заменяет SQL-бэкап

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

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

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

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

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

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

Ручной бэкап через Management Studio

Разовая копия нужна перед обновлением конфигурации, переносом базы или установкой доработок. Порядок действий в SSMS одинаков для любой базы 1С.

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

Опция «Проверить резервную копию» выполняет лишь базовую проверку читаемости файла — она не гарантирует, что база восстановится без ошибок, но отсекает явно битые копии. Полная уверенность достигается только тестовым восстановлением, о чём ниже.

Бэкап командой T-SQL

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

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

Параметр COMPRESSION сжимает файл копии (в выпусках, где поддерживается), CHECKSUM включает проверку контрольных сумм страниц при записи, INIT перезаписывает файл. Для копии журнала транзакций при полной модели восстановления используется другая команда:

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

Имя файла удобно формировать с датой и временем, чтобы копии не затирали друг друга. Это делается либо динамическим SQL, либо внешним скриптом, который формирует имя и вызывает sqlcmd.

Автоматизация: план обслуживания и агент SQL Server

Разовые бэкапы не спасают — спасает расписание. В выпусках SQL Server Standard и выше используйте агент SQL Server: создайте задание (Job) с шагом типа T-SQL, вставьте команду BACKUP и настройте расписание — например, полная копия ежедневно в 2:00, копии журнала каждые 15–30 минут в рабочее время.

Альтернатива — «План обслуживания» (Maintenance Plan) через графический конструктор в SSMS: узел «Управление» → «Планы обслуживания» → «Мастер планов обслуживания». Он позволяет собрать цепочку: резервное копирование, проверка целостности, очистка старых файлов. Для удаления устаревших копий добавьте задачу «Очистка после обслуживания» с указанием папки, расширения .bak и срока хранения.

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

Хранение копий: куда и сколько

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

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

Проверка восстановления: бэкап, который не поднялся, не существует

Успешное сообщение «BACKUP DATABASE successfully processed» говорит лишь о том, что файл записан. Реальная проверка — восстановление копии на тестовом сервере или в отдельную базу с другим именем. Команда восстановления в тестовую базу выглядит так:

RESTORE DATABASE [MyBase1C_Test]
FROM DISK = N'D:\SQLBackups\MyBase1C_full.bak'
WITH MOVE 'MyBase1C' TO 'D:\SQLData\MyBase1C_Test.mdf',
MOVE 'MyBase1C_log' TO 'D:\SQLData\MyBase1C_Test_log.ldf',
REPLACE, CHECKSUM;

Имена логических файлов для предложения MOVE смотрите в выводе команды RESTORE FILELISTONLY. После восстановления зарегистрируйте тестовую базу в кластере 1С (с признаком «блокировка регламентных заданий», чтобы не пошли фоновые процессы) и убедитесь, что она открывается, а документы за последние дни на месте.

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

Отдельно упомянем PostgreSQL: для баз 1С на этой СУБД резервное копирование выполняется утилитой pg_dump или pg_basebackup с настройкой WAL-архива для восстановления на точку во времени. Логика та же — регулярные копии, отдельное хранилище, проверка восстановления, — отличаются только инструменты.

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