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

Резервное копирование SQL-базы 1С — это копирование данных средствами СУБД (Microsoft SQL Server, PostgreSQL), а не выгрузка в dt через конфигуратор. Такой подход работает быстрее на больших базах, не требует завершения сеансов пользователей и позволяет автоматизировать копирование по расписанию. При этом важно понимать: копия средствами SQL и выгрузка в dt решают разные задачи и не заменяют друг друга полностью.

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

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

Выгрузка в файл .dt через конфигуратор (Администрирование → Выгрузить информационную базу) создаёт платформенный архив, который можно загрузить в базу на любой СУБД и даже в файловый вариант. Это удобно для переноса между серверами и перед обновлением конфигурации. Минусы: выгрузка требует монопольного доступа (пользователей придётся выгнать), на больших базах занимает часы, а при сбое процесс начинается заново.

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

Как сделать копию через SQL Server Management Studio

Самый наглядный способ — графический интерфейс SQL Server Management Studio (SSMS). Подключитесь к серверу под учётной записью с правами администратора (sysadmin) или как минимум с ролью db_backupoperator в нужной базе. Затем в обозревателе объектов разверните узел «Базы данных», найдите базу 1С, щёлкните по ней правой кнопкой и выберите «Задачи» → «Создать резервную копию» (Tasks → Back Up).

В открывшемся окне выберите тип копии «Полная» (Full), укажите назначение — «Диск» и задайте путь к файлу, например D:\Backups\base1c_full.bak. Важно: путь указывается относительно сервера, где работает SQL Server, а не вашего компьютера, если вы подключились удалённо. После нажатия OK дождитесь сообщения об успешном завершении и проверьте, что файл появился в указанной папке и имеет правдоподобный размер.

1. 1
   Подключитесь к SQL Server в Management Studio под учётной записью с правами на backup
2. 2
   Найдите базу 1С, правый клик → Задачи → Создать резервную копию
3. 3
   Тип: Полная, назначение: Диск, укажите путь к .bak-файлу на сервере
4. 4
   Нажмите OK и дождитесь сообщения об успешном завершении
5. 5
   Проверьте наличие и размер файла в целевой папке

Резервное копирование командой BACKUP DATABASE

Тот же результат даёт команда T-SQL, которую удобно выполнять через sqlcmd или в окне запроса SSMS. Этот способ нужен для скриптов и автоматизации.

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

Параметр COMPRESSION сжимает файл копии — на типовых базах 1С экономия места обычно значительная, а время создания копии часто сокращается. Параметр CHECKSUM заставляет сервер проверять контрольные суммы страниц при чтении и записи, что помогает выявить повреждения ещё на этапе копирования. Сжатие резервных копий доступно не во всех редакциях SQL Server — в Express-редакции оно появилось начиная с более поздних версий, в старых Express его нет.

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

Как автоматизировать копирование по расписанию

Разовая копия не защищает от потери данных — нужен регулярный процесс. В полных редакциях SQL Server (Standard, Enterprise) для этого есть планы обслуживания: в SSMS откройте «Управление» → «Планы обслуживания» → «Мастер планов обслуживания», добавьте задачу «Резервное копирование базы данных», укажите базу, папку назначения и расписание, например полная копия ежедневно ночью. Задачи плана выполняются службой SQL Server Agent.

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

sqlcmd -S SERVERNAME -Q "BACKUP DATABASE [MyBase1C] TO DISK = N'D:\Backups\MyBase1C_%DATE:~6,4%%DATE:~3,2%%DATE:~0,2%.bak' WITH CHECKSUM"

Дополнительно настройте удаление старых копий, иначе диск рано или поздно заполнится, и новые копии перестанут создаваться. Для этого подойдёт команда forfiles или скрипт PowerShell, удаляющий файлы старше заданного срока, например 14 дней.

Модель восстановления и копии журнала транзакций

У каждой базы SQL Server есть модель восстановления: «Простая» (Simple) или «Полная» (Full). При простой модели журнал транзакций автоматически усекается, и восстановить базу можно только на момент последней полной копии — все изменения после неё будут потеряны. Для большинства баз 1С это приемлемый вариант, если полная копия делается ежедневно.

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

Куда сохранять копии и как их проверять

Копия, лежащая на том же диске или том же сервере, что и сама база, защищает только от случайного удаления данных, но не от отказа оборудования, шифровальщика или пожара. Минимальное правило: переносить копии на другое устройство — сетевое хранилище, второй сервер, внешнее облачное хранилище. Хорошей практикой считается схема «3-2-1»: три копии данных, на двух разных типах носителей, одна — вне основной площадки.

Наличие файла .bak ещё не гарантирует, что из него можно восстановиться. Проверяйте копии: команда RESTORE VERIFYONLY подтверждает читаемость файла, а полноценная проверка — периодическое тестовое восстановление копии в отдельную базу с другим именем на тестовом сервере. Только успешное восстановление доказывает, что резервное копирование работает.

Типичные ошибки и риски

Самая опасная ошибка — отсутствие какого-либо резервного копирования при уверенности, что «админы всё настроили». Вторая по частоте — копии, которые никто никогда не проверял восстановлением: в момент аварии выясняется, что файлы битые или неполные. Третья — копирование файлов .mdf и .ldf на работающем сервере: такие файлы заблокированы, и скопированный вариант, скорее всего, окажется повреждённым.

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

Часто задаваемые вопросы