При администрировании серверов баз данных MS SQL Server, обслуживающих высоконагруженные системы (например, 1С:Предприятие), системные администраторы часто сталкиваются со странным поведением СУБД. В логах SQL Server раз в сутки (или с другой периодичностью) начинают появляться записи о резервном копировании всех баз данных на виртуальное устройство VIRTUAL_DEVICE с длинным GUID, сопровождаемые сообщениями I/O is frozen on database и I/O was resumed on database.
При этом штатные планы обслуживания (Maintenance Plans) настроены корректно, бэкапы выполняются по расписанию в другие часы, а в указанное в логах время никаких регламентных операций в самом SQL Server не запланировано. Проверка баз данных с помощью команды DBCC CHECKDB не выявляет никаких ошибок. В этой статье мы подробно разберем, что означает данное событие, почему оно происходит, какие скрытые угрозы оно несет для сохранности ваших баз данных 1С и как правильно настроить систему для устранения негативных последствий.
Описанная ситуация — это классический сценарий взаимодействия СУБД SQL Server со внешними средствами резервного копирования на уровне операционной системы или гипервизора (Hyper-V, VMware ESXi, Veeam Backup & Replication, Windows Server Backup). Процесс происходит с участием системной службы Windows под названием SQL Server VSS Writer.
Проанализируем этот процесс по шагам, чтобы понять, что происходит "под капотом" операционной системы:
I/O is frozen on database.... В этот момент все транзакции удерживаются в оперативной памяти, а запись на диск блокируется.I/O was resumed on database....Database backed up... pages dumped: ... first LSN: ... last LSN: ... TYPE=VIRTUAL_DEVICE, а также регистрирует это событие в системной таблице msdb.dbo.backupset.Администраторы виртуализации часто говорят, что на эту запись не нужно обращать внимания, так как это "просто информационное сообщение" (This is an informational message only). Однако для администраторов СУБД и системных архитекторов 1С такое поведение системы таит в себе смертельную опасность.
Самая критическая проблема, к которой приводит автоматический VSS-бэкап виртуальной машины, — это разрыв цепочки резервных копий. Рассмотрим подробнее, как это работает в MS SQL Server.
Каждая транзакция в SQL Server имеет свой уникальный последовательный номер — LSN (Log Sequence Number). Когда вы настраиваете стандартную и надежную схему резервного копирования для 1С, она обычно выглядит следующим образом:
Когда внешняя система делает бэкап всей виртуалки через стандартный VSS-запрос, SQL Server воспринимает это как создание нового полноценного Full Backup. Он обновляет значение так называемого Differential Base LSN (базового LSN для разностных копий).
Что происходит в результате разрыва цепочки LSN:
Если во вторник ночью прошел автоматический бэкап виртуальной машины через VSS, а в среду днем у вас произошел сбой дискового массива, вы попытаетесь восстановить базу данных. Вы возьмете свой воскресный полный бэкап и попытаетесь применить к нему разностный бэкап за среду. Однако SQL Server выдаст ошибку, так как цепочка LSN была разорвана вторничным VSS-бэкапом. Разностный бэкап среды привязан к "невидимому" полному бэкапу, который находится внутри образа виртуальной машины в системе резервного копирования гипервизора!
Вам придется либо разворачивать громоздкий образ всей виртуальной машины из бэкапа гипервизора (что может занять долгие часы), либо вы потеряете все изменения, сделанные с момента воскресного бэкапа.
Во время заморозки ввода-вывода (I/O is frozen) СУБД приостанавливает любые операции записи на диск. Если база данных 1С активно используется пользователями в этот момент (например, идет проведение документов, закрытие месяца или групповое перепроведение), то все транзакции "зависают" в очереди.
Если баз данных на сервере много (более 20-30), процесс последовательного прохождения VSS-запроса по всем базам может затянуться на десятки секунд или даже минут. В результате пользователи 1С увидят сообщения о таймауте соединения, критических ошибках СУБД или просто столкнутся с сильным зависанием интерфейса программы.
Для того чтобы точно определить, кто и когда выполняет эти несанкционированные резервные копии, мы можем выполнить диагностический запрос к системной базе данных msdb. Проанализируем историю бэкапов с помощью следующего скрипта:
SELECT b.database_name
, m.physical_device_name
, b.server_name
, b.machine_name
, b.user_name
, ms.software_name
FROM msdb.dbo.backupset b
JOIN msdb.dbo.backupmediafamily m
ON b.media_set_id = m.media_set_id
JOIN msdb.dbo.backupmediaset ms
ON ms.media_set_id = b.media_set_id
ORDER BY b.backup_finish_date DESC;
Если в результатах выполнения запроса в поле physical_device_name вы увидите пути, содержащие фигурные скобки и длинные GUID-идентификаторы (например, {EE987E88-565C-4584-8AD1-9B52BB149BB4}), а в поле software_name указано Microsoft SQL Server или имя стороннего бэкапера, это является прямым доказательством работы службы VSS.
Рассмотрим три основных варианта решения этой проблемы в зависимости от того, как организовано резервное копирование в вашей ИТ-инфраструктуре.
Этот вариант является самым правильным и безопасным, если вам действительно необходимо иметь резервные копии всей виртуальной машины целиком с учетом состояния СУБД. Режим Copy-Only (только копия) указывает SQL Server, что данный бэкап не должен влиять на цепочку LSN и сбрасывать базовый LSN для последующих разностных копий.
Рассмотрим, как настроить этот режим на примере популярных систем:
Если резервное копирование баз данных 1С полностью и надежно настроено внутри самого SQL Server (с помощью планов обслуживания или скриптов на Transact-SQL с выгрузкой бэкапов на выделенное сетевое хранилище), а бэкап виртуальной машины на уровне гипервизора нужен только для восстановления операционной системы и программной среды, службу интеграции SQL с VSS можно отключить.
Разберем этот процесс по шагам:
services.msc и нажмите Enter.Результат: Теперь при создании снапшота виртуальной машины гипервизор не будет обращаться к SQL Server. Резервная копия виртуалки снимется в режиме Crash-Consistent (состояние диска на момент внезапного отключения питания). При этом SQL Server больше не будет замораживать ввод-вывод (исчезнут зависания в 1С), в логах перестанут появляться записи pages dumped с виртуальными GUID, а ваша локальная цепочка LSN-бэкапов будет находиться в полной безопасности.
Если дисковая подсистема вашего сервера разделена на логические диски (например, диск C: — под операционную систему, диск D: — под файлы данных 1С .mdf, диск E: — под логи транзакций .ldf), вы можете настроить систему резервного копирования гипервизора так, чтобы она бэкапила исключительно системный диск C:.
Это исключит файлы баз данных из процесса дискового снапшота, полностью уберет паразитную нагрузку на дисковую подсистему SQL Server и предотвратит нежелательные вызовы VSS-писателя.
Не игнорируйте появление записей pages dumped на устройство VIRTUAL_DEVICE в логах СУБД. Помните следующие правила: