Резервная копия базы 1С 8.3 на MS SQL: пошагово

Чтобы сделать копию базы 1С 8.3 на SQL, не выгружайте её в .dt — для серверной базы на MS SQL это долго, рискованно и не годится для регулярного бэкапа. Копию снимают средствами самого SQL Server: командой BACKUP DATABASE или через SSMS, за секунды и без выгона пользователей.

Разберём, как сделать копию базы 1С 8.3 SQL тремя способами — вручную через SSMS, скриптом T-SQL и по расписанию через план обслуживания. Плюс как развернуть эту копию в новую базу для тестирования и подключить её к 1С.

Копия на SQL или выгрузка в .dt — в чём разница

Первый вопрос, который путает новичков: «а почему нельзя просто Администрирование → Выгрузить информационную базу?». Можно, но для серверной базы на MS SQL это неудачный выбор.

Вывод простой: .dt — для переноса структуры и мелких файловых баз, а не для резервного копирования боевой SQL-базы. Для серверной базы основной инструмент — бэкап SQL Server.

Что проверить перед созданием копии

Пять минут подготовки экономят час на разборе, почему бэкап не пишется.

Имя базы в SQL часто отличается от того, что видит бухгалтер в списке баз 1С. Посмотреть точное имя: в окне запуска 1С выделите базу → кнопка Изменить → поле «База данных». Например, в списке она «Бухгалтерия», а в SQL называется buh_prod.

Способ 1. Копия базы 1С через SSMS

Самый наглядный путь — графика SQL Server Management Studio. Ничего писать руками не нужно.

Способ 2. Бэкап базы 1С скриптом T-SQL

Когда SSMS под рукой нет или нужно встроить бэкап в свой скрипт — та же операция одной командой. Откройте New Query и выполните:

BACKUP DATABASE [buh_prod]
TO DISK = N'D:\Backups\buh_prod_full.bak'
WITH FORMAT,          -- перезаписать файл, а не дописать в конец
     COMPRESSION,     -- сжать копию (обычно в 4–8 раз)
     STATS = 10;      -- показывать прогресс каждые 10%

Замените buh_prod на имя своей базы, а путь — на свой каталог. Ключ WITH FORMAT важен: без него SQL Server будет дописывать каждую новую копию в тот же файл, и он распухнет.

Разностную копию (только изменения с момента последней полной) снимают так:

BACKUP DATABASE [buh_prod]
TO DISK = N'D:\Backups\buh_prod_diff.bak'
WITH DIFFERENTIAL, COMPRESSION, STATS = 10;

А копию журнала транзакций (нужна только в модели Full — о ней ниже):

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

Способ 3. Автоматический бэкап через План обслуживания

Ручная копия хороша перед обновлением или тестом. Но постоянный бэкап должен идти сам. Для этого в SQL Server есть Maintenance Plan (план обслуживания). Нужен агент SQL Server (SQL Server Agent) — в редакции Express его нет, там расписание вешают на Планировщик Windows с sqlcmd.

Типовая схема для боевой базы:

• 🗂️ Полная копия — раз в сутки ночью (Back Up Database Task, тип Full);
• 📎 Разностная — каждые несколько часов днём (тип Differential);
• 📜 Копия журнала — каждые 15–60 минут, если модель Full;
• 🧹 Очистка старых — Maintenance Cleanup Task, удалять .bak старше N дней.

Создать: в SSMS Management → Maintenance Plans → New Maintenance Plan, перетащить задачи из панели Toolbox, задать базу, каталог и расписание в свойствах.

Модели восстановления Simple и Full — что выбрать

От модели восстановления зависит, насколько «свежую» точку вы сможете восстановить. Посмотреть текущую: правый клик на базе → Properties → Options → Recovery model.

Как это работает в Simple: журнал транзакций очищается автоматически. Просто и без обслуживания, но восстановитесь только на момент бэкапа — всё, что ввели после, потеряно.

Как это работает в Full: каждое изменение хранится в журнале, пока вы не снимете BACKUP LOG. Это даёт восстановление на точку, но если не делать копию журнала — он раздуется и переполнит диск. Full без регулярного BACKUP LOG — частая причина «внезапно кончилось место».

Полная, разностная и копия журнала

• Полная (Full) — вся база целиком. Основа любой стратегии.
• Разностная (Differential) — только то, что изменилось с последней полной. Меньше и быстрее.
• Журнал транзакций (Log) — все операции с момента прошлой копии журнала. Только для модели Full.

Логика восстановления: сначала разворачивают последнюю полную, поверх — последнюю разностную, затем по цепочке — копии журнала до нужного момента.

Сжатие резервной копии

Ключ COMPRESSION (см. Способ 2) сжимает .bak прямо при создании — база 1С жмётся обычно в 4–8 раз. Бэкап на 20 ГБ базы займёт 3–5 ГБ. Плюс копия пишется быстрее, потому что на диск ложится меньше данных.

Включить сжатие по умолчанию для всего сервера:

EXEC sp_configure 'backup compression default', 1;
RECONFIGURE;

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

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

1. В SSMS: правый клик на Databases → Restore Database….
2. Source → Device → укажите файл .bak.
3. В поле Destination → Database впишите новое имя, например buh_test.
4. Вкладка Files → включите Relocate all files, задайте пути для .mdf и .ldf теста (иначе файлы пойдут поверх боевых).
5. OK.

Скриптом то же самое:

RESTORE DATABASE [buh_test]
FROM DISK = N'D:\Backups\buh_prod_full.bak'
WITH MOVE 'buh_prod'     TO N'D:\SQLData\buh_test.mdf',
     MOVE 'buh_prod_log' TO N'D:\SQLData\buh_test_log.ldf',
     REPLACE, STATS = 10;

Логические имена файлов (buh_prod, buh_prod_log) узнают командой RESTORE FILELISTONLY FROM DISK = N'...\buh_prod_full.bak';.

Как подключить восстановленную копию к 1С

База в SQL появилась, но 1С про неё ещё не знает. Добавляем в список:

1. В окне запуска 1С → Добавить → Добавление существующей.
2. Тип — «На сервере 1С:Предприятия».
3. Кластер серверов — имя вашего сервера 1С:Предприятия.
4. Имя информационной базы в кластере — новое имя (buh_test).
5. Сервер баз данных и имя базы данных — ваш SQL-сервер и buh_test.

Копию для тестирования пометьте, чтобы не спутать с боевой: назовите в списке «⚠ ТЕСТ Бухгалтерия». А при первом запуске тестовой копии ответьте «Нет» на предложение обновиться и снимите галку регламентных заданий — иначе тест начнёт слать отчётность и обмениваться данными от имени организации.

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

Бэкап, который не восстанавливается, — не бэкап. Проверить целостность .bak, не разворачивая её:

RESTORE VERIFYONLY FROM DISK = N'D:\Backups\buh_prod_full.bak';

Ответ The backup set on file 1 is valid означает, что файл читается и контрольные суммы сходятся. Раз в месяц полезно делать и «боевую» проверку — реально разворачивать копию в тестовую базу и запускать 1С. Только так вы точно знаете, что восстановитесь в аварийной ситуации.

Типичные ошибки и что делать

Что чаще всего всплывает на форумах при бэкапе базы 1С на MS SQL:

Если не помогло

Бэкап падает, а причина в сообщении неочевидна — сузьте проблему по шагам:

• 🔎 Посмотрите полный текст ошибки в SQL Server Logs (SSMS → Management → SQL Server Logs) — там причина подробнее, чем в окне.
• 🧪 Попробуйте снять копию другой, маленькой базы на этот же диск. Пишется — проблема в конкретной базе; нет — в правах или диске.
• 💽 Проверьте состояние базы: DBCC CHECKDB('buh_prod') WITH NO_INFOMSGS;. Ошибки целостности мешают и бэкапу.
• 🔐 Убедитесь, что снимаете копию под учёткой с ролью db_backupoperator или sysadmin.
• 🆘 Если база не открывается вовсе (Suspect, Recovery pending) — не экспериментируйте на боевой, снимите сначала копию файлов .mdf/.ldf при остановленной службе SQL и работайте с ними.

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