Резервная копия и тестовый клон базы 1С через BACKUP и RESTORE

Копию базы 1С в клиент-серверном варианте делают командой BACKUP DATABASE ... TO DISK = '...bak' WITH COPY_ONLY, COMPRESSION, CHECKSUM на SQL Server, а разворачивают через RESTORE DATABASE ... WITH MOVE под новым именем. Пользователей выгонять не нужно: SQL Server снимает полную копию на работающей базе, в отличие от выгрузки .dt в Конфигураторе.

Средствами SQL копия получается быстрее и надёжнее .dt: база на 100 ГБ выгружается в .dt часами, а BACKUP с компрессией обычно укладывается в десятки минут. Но есть нюансы, о которых молчат типовые инструкции: файлы в томах на диске, регламентные задания в клоне, осиротевшие логины и цепочка дифференциальных копий.

Что проверить до первой резервной копии

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

Узнайте реальное имя базы на SQL Server

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

Проверьте целостность

DBCC CHECKDB (N'buh_prod') WITH NO_INFOMSGS, ALL_ERRORMSGS;

Пустой результат — ошибок нет. Если CHECKDB что-то нашёл, сначала разберитесь с повреждениями, а копию снимите до любых попыток ремонта.

Посчитайте место

Размер файлов базы покажет запрос:

USE buh_prod;
SELECT name, type_desc, size * 8 / 1024 AS size_mb
FROM sys.database_files;

Сжатая копия базы 1С обычно занимает в 4–8 раз меньше файла данных, но под восстановление клона нужно место на полный размер .mdf и .ldf. Файл журнала в клоне будет такого же размера, как в исходной базе.

Полная копия базы 1С командой BACKUP

Скрипт T-SQL

Откройте SQL Server Management Studio, новое окно запроса, и выполните:

BACKUP DATABASE [buh_prod]
TO DISK = N'D:\Backup\buh_prod_copy.bak'
WITH COPY_ONLY,
     COMPRESSION,
     CHECKSUM,
     INIT,
     STATS = 10;

Что делает каждый параметр:

• 📌 COPY_ONLY — копия вне расписания. Она не сбрасывает базу для дифференциальных копий и не ломает цепочку, которую ведёт ваш регулярный план обслуживания. Для разовых копий «под тест» ставьте его всегда.
• 📦 COMPRESSION — сжатие на лету. Работает в Standard и Enterprise; в Express параметр недоступен.
• ✅ CHECKSUM — SQL Server проверяет контрольные суммы страниц при чтении и пишет их в файл копии.
• 🧹 INIT — перезаписывает файл, если он уже есть, а не дописывает новый набор в конец.
• 📊 STATS = 10 — показывает прогресс каждые 10%.

Через интерфейс SSMS

1. В «Обозревателе объектов» раскройте Базы данных, нажмите правой кнопкой на нужную базу.
2. Выберите Задачи → Создать резервную копию (в английской версии Tasks → Back Up).
3. Тип — «Полная», отметьте «Только архивное копирование» — это и есть COPY_ONLY.
4. В блоке назначения удалите старый путь и добавьте свой файл .bak.
5. На странице параметров носителя включите проверку контрольной суммы, на странице параметров резервного копирования — сжатие.

Проверьте файл сразу

RESTORE VERIFYONLY
FROM DISK = N'D:\Backup\buh_prod_copy.bak'
WITH CHECKSUM;

VERIFYONLY проверяет читаемость файла и контрольные суммы. Гарантию даёт только реальное восстановление, но грубые проблемы команда ловит за минуты.

Как развернуть копию в новую базу для тестов

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

Шаг 1. Узнайте логические имена файлов

RESTORE FILELISTONLY
FROM DISK = N'D:\Backup\buh_prod_copy.bak';

В колонке LogicalName будут имена вроде buh_prod и buh_prod_log. Они нужны для MOVE.

Шаг 2. Восстановите под новым именем

RESTORE DATABASE [buh_test]
FROM DISK = N'D:\Backup\buh_prod_copy.bak'
WITH MOVE N'buh_prod'     TO N'E:\SQLData\buh_test.mdf',
     MOVE N'buh_prod_log' TO N'F:\SQLLog\buh_test_log.ldf',
     RECOVERY,
     STATS = 10;

Шаг 3. Переведите тест в простую модель восстановления

Тестовой базе журнал транзакций для отката на точку во времени не нужен, а расти он будет.

ALTER DATABASE [buh_test] SET RECOVERY SIMPLE;

Шаг 4. Зарегистрируйте базу в кластере 1С

1. В консоли администрирования серверов 1С раскройте кластер, на узле «Информационные базы» выберите создание новой базы.
2. Имя — buh_test, сервер баз данных и тип СУБД — как у рабочей базы.
3. В поле «База данных» укажите buh_test — ту, что восстановили.
4. Снимите флажок «Создать базу данных в случае ее отсутствия»: база уже есть.
5. Включите «Блокировка регламентных заданий». Иначе клон начнёт сам загружать банковские выписки, отправлять почту и запускать обмены от имени рабочей базы.

Затем добавьте базу в список у пользователя (Добавить → Добавление в список существующей информационной базы) и откройте её.

Шаг 5. Ответьте на вопрос о перемещении

Типовые конфигурации на БСП при первом запуске замечают, что адрес базы изменился, и спрашивают: база перемещена или это копия. Для теста выбирайте вариант про копию. Программа отключит синхронизацию данных, обмен с сайтом, работу с внешними ресурсами — и клон не отправит в банк или в ЭДО дубли.

Файлы вне SQL: тома хранения и всё, чего нет в .bak

BACKUP копирует только базу данных. В конфигурациях на БСП присоединённые файлы (сканы договоров, вложения писем, картинки номенклатуры) можно хранить не в базе, а в томах на диске. Тогда в SQL лежит лишь ссылка на файл.

Где проверить: в типовых конфигурациях это Администрирование → Общие настройки, блок о присоединённых файлах. Если включено хранение в томах, там же открывается список томов с путями к папкам.

Чтобы копия была согласованной, копируйте тома в тот же интервал, что и .bak. Иначе в клоне появятся ссылки на файлы, которых нет в папке, и при открытии вложения 1С сообщит, что файл не найден.

💡 Для тестового клона тома часто копировать не обязательно. Но тогда в клоне смените пути томов на пустую тестовую папку, чтобы тест не писал файлы в рабочие тома.

Регулярные копии по расписанию через SQL Agent

Разовая копия — для теста. Для защиты от потери данных нужна схема по расписанию. Типичный набор для рабочей базы 1С в полной модели восстановления:

Создаём задание

1. В SSMS раскройте Агент SQL Server → Задания, создайте новое задание.
2. Шаг типа «Скрипт Transact-SQL», текст:

DECLARE @file NVARCHAR(400) =
    N'D:\Backup\buh_prod_' + FORMAT(GETDATE(), 'yyyyMMdd_HHmm') + N'.bak';

BACKUP DATABASE [buh_prod]
TO DISK = @file
WITH COMPRESSION, CHECKSUM, INIT;

3. На вкладке расписаний задайте ежедневный запуск, например в 02:00.
4. В уведомлениях включите письмо оператору при сбое — для этого заранее настройте Database Mail и оператора.

Если удобнее мышкой, тот же результат даёт мастер планов обслуживания (Управление → Планы обслуживания). В плане сразу добавьте задачу очистки старых файлов, чтобы диск не заполнился через месяц.

Как восстановиться на конкретную минуту

Схема FULL + LOG позволяет вернуть базу на момент до ошибки. Например, в 14:20 кто-то запустил обработку, которая испортила справочник контрагентов. Разворачиваем копию рядом и доводим её до 14:15:

RESTORE DATABASE [buh_restore] FROM DISK = N'D:\Backup\buh_prod_20261007_0200.bak'
WITH MOVE N'buh_prod' TO N'E:\SQLData\buh_restore.mdf',
     MOVE N'buh_prod_log' TO N'F:\SQLLog\buh_restore_log.ldf',
     NORECOVERY;

RESTORE LOG [buh_restore] FROM DISK = N'D:\Backup\buh_prod_log_1400.trn'
WITH NORECOVERY;

RESTORE LOG [buh_restore] FROM DISK = N'D:\Backup\buh_prod_log_1430.trn'
WITH STOPAT = N'2026-10-07T14:15:00', RECOVERY;

Журналы применяются строго по порядку, без пропусков. Если пропал хотя бы один файл .trn, дальше него восстановиться нельзя. Испорченные данные потом переносят из клона в рабочую базу, например выгрузкой и загрузкой нужных объектов, а не перезаписью всей базы.

💡 Раз в месяц разворачивайте свежую копию в тестовую базу и открывайте её в 1С. Копия, которую ни разу не восстанавливали, — это надежда, а не резерв.

Если у вас SQL Server Express

В Express нет SQL Agent. Скрипт сохраняют в файл и запускают через Планировщик заданий Windows:

sqlcmd -S .\SQLEXPRESS -E -i "D:\Scripts\backup_buh.sql" -o "D:\Scripts\backup_buh.log"

-E — вход под учётной записью Windows, от которой выполняется задача планировщика. У неё должны быть права на резервное копирование базы .

Диагностика ошибок и разрастание журнала транзакций

Почему растёт .ldf и как его вернуть в норму

Журнал в полной модели очищается только после BACKUP LOG. Полная копия журнал не освобождает. Отсюда классика: .mdf на 40 ГБ и .ldf на 200 ГБ.

Что сделать:

1. Посмотрите, что держит журнал:

SELECT name, recovery_model_desc, log_reuse_wait_desc
FROM sys.databases
WHERE name = N'buh_prod';

2. Если там LOG_BACKUP — снимите копию журнала:

BACKUP LOG [buh_prod]
TO DISK = N'D:\Backup\buh_prod_log.trn'
WITH COMPRESSION, CHECKSUM;

3. После этого журнал можно ужать до разумного размера:

USE buh_prod;
DBCC SHRINKFILE (N'buh_prod_log', 4096);  -- целевой размер в МБ

Если log_reuse_wait_desc показывает ACTIVE_TRANSACTION, журнал держит долгая транзакция. В базе 1С это часто закрытие месяца или групповое перепроведение, которое ещё идёт. Дождитесь окончания операции, а не завершайте сеанс принудительно.

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