В процессе эксплуатации серверных версий «1С:Предприятие» системные администраторы часто сталкиваются с парадоксальной ситуацией: физический размер базы данных (MDF-файл) составляет, к примеру, 10 Гб, лог транзакций (LDF-файл) — 16 Гб, однако файл резервной копии (BAK-файл) разрастается до 80 Гб и более. Рассмотрим подробно, почему это происходит, проанализируем внутренние механизмы MS SQL Server и разберем по шагам способы решения этой проблемы.
Разберем наиболее распространенную ситуацию. По умолчанию MS SQL Server при создании резервной копии использует механизм дописывания в существующий файл, если не указано иное. Это означает, что если вы настроили ежедневное резервное копирование в один и тот же файл backup.bak, то на второй день внутри этого файла будет лежать два архива, на третий — три, и так далее.
Проанализируем это поведение. SQL Server рассматривает файл резервной копии как «набор носителей» (media set). Если в настройках плана обслуживания или в скрипте T-SQL не указана опция INIT, система применяет опцию NOINIT. В результате размер файла будет расти бесконечно, пока не закончится дисковое пространство, хотя актуальная база может не расти вовсе.
Чтобы проверить содержимое вашего «раздутого» архива, выполним следующую команду в SQL Server Management Studio (SSMS):
RESTORE HEADERONLY
FROM DISK = 'C:\Backup\your_database.bak';
Посмотрим на результат выполнения: если в таблице вы видите десятки строк (колонки Position, BackupStartDate), значит, ваш файл содержит историю бэкапов за длительный период. Выясним, как с этим бороться. Нам необходимо изменить настройки бэкапа, чтобы файл перезаписывался (если нам нужен только последний актуальный архив) или создавался новый файл с уникальным именем (например, с меткой даты).
В скрипте резервного копирования заменим NOINIT на INIT:
BACKUP DATABASE [YourDatabaseName]
TO DISK = 'C:\Backup\your_database.bak'
WITH INIT, STATS = 10;
Проанализируем ситуацию, описанную пользователем: файл базы 10 Гб, а лог транзакций — 16 Гб. Это явный признак того, что для базы установлена Full Recovery Model (Полная модель восстановления), но при этом не выполняется регулярное резервное копирование лога транзакций.
При полной модели восстановления SQL Server не очищает лог (LDF) до тех пор, пока не будет сделан бэкап именно этого лога. Обычный бэкап базы (Full Backup) не обрезает лог транзакций. Если база активно обменивается данными (например, идет синхронизация с УТ 11), количество транзакций колоссально. Эти транзакции накапливаются, и при создании полной резервной копии SQL Server может включать в архив активную часть лога, что увеличивает итоговый размер BAK-файла.
Разберем, что можно сделать:
Выясним еще одну причину: почему размер архива (BAK) может быть равен размеру базы (MDF), хотя данных внутри мало? Если база 1С когда-то была 80 Гб, а потом была «ужата» до 10 Гб (например, после выноса файлов в тома хранения), внутри страниц базы данных может сохраняться высокая фрагментация или специфическая структура, которую SQL Server копирует «как есть».
Современные версии MS SQL Server (начиная с 2008 R2 Standard) поддерживают сжатие бэкапов. Без этой опции SQL Server создает архив, размер которого практически равен размеру занятого пространства в файлах данных. С включенным сжатием размер архива базы 1С обычно уменьшается в 3–10 раз.
Проверим настройки сервера. В SSMS нажмите правой кнопкой на корень сервера — Properties — Database Settings. Убедитесь, что установлена галочка Compress backup. Также это можно указать явно в команде:
BACKUP DATABASE [YourDatabaseName]
TO DISK = 'C:\Backup\your_database.bak'
WITH COMPRESSION, INIT;
Рассмотрим специфику 1С. При интенсивной синхронизации (например, между «Бухгалтерией предприятия» и «Управлением торговлей») в базе постоянно создаются и удаляются записи в таблицах регистрации изменений (объекты ПланыОбмена). Когда записи удаляются, SQL Server помечает их как «Ghost Records» (призрачные записи).
Эти записи физически остаются на страницах данных до тех пор, пока фоновый процесс Ghost Cleanup их не вычистит. Если бэкап запускается сразу после массовой синхронизации, все эти «удаленные», но не вычищенные данные могут попасть в архив. Проанализируем состояние базы: после глобальных изменений или очистки больших объемов данных (как в случае с выносом файлов на 80 Гб) рекомендуется выполнить реорганизацию или перестроение индексов.
Используем следующий подход для оптимизации перед архивацией:
SHRINKDATABASE или SHRINKFILE (однократно после глобального удаления данных), чтобы вернуть свободное место операционной системе.Подведем итог и составим план действий, чтобы привести размер архивов в соответствие с реальным объемом данных:
Backup Compression на уровне сервера или в параметрах задания бэкапа.Simple Recovery Model или настройте частое резервное копирование лога (Transaction Log Backup).backup.bak, настройте сохранение в файлы с именами вида Base_YYYY_MM_DD.bak. Это позволит избежать путаницы и автоматического накопления архивов в одном месте.Соблюдение этих правил позволит вам сократить размер архивов в несколько раз, ускорить процесс резервного копирования и сэкономить место на сервере хранения бэкапов.