Короткий ответ
Штатный backup Hyper-V делает production checkpoint (VSS в госте) и должен быстро слить overlay. Если VM-APP01 «зависает»: VSS timeout, IC VSS выключен (тогда хост уходит в Saved State / standard), очередь снимков, CSV не тянет IO. Не убивайте job Task Manager хоста и не удаляйте .avhdx backup-снимка.
Сначала vssadmin list writers на хосте и в госте, Get-VMCheckpoint, статус backup продукта.
Симптомы и как отличить
Типичная картина:
- на 02:00 VM Saved или без heartbeat 10+ минут;
- в каталоге VM появляется avhdx, после job остаётся;
- job Failed, VM потом Running;
- одновременный backup всех VM на одном CSV.
Отличия:
| Что видно | Куда |
|---|---|
| Снимок не удаляется днём | checkpoint |
| Цепочка сломана | AVHDX |
| IC VSS Disabled | IC |
| Просто медленный диск | нагрузка диска |
Возможные причины
- Writer в госте (SQL, NTDS, Exchange) timeout.
vmicvssDisabled — Hyper-V не может production.- Backup настроили на crash-consistent / Saved.
- Предыдущий checkpoint не слит, новый не стартует.
- CSV redirected / нет места под overlay.
- Слишком много VM в одном окне, VSS freeze растянулся.
- Сторонний агент внутри гостя + хостовый Hyper-V backup одновременно.
Диагностика
Хост:
Get-VM -Name 'VM-APP01' | Format-List State, Status, Heartbeat, CheckpointFileLocation
Get-VMCheckpoint -VMName 'VM-APP01' | Format-Table Name, SnapshotType, CreationTime
Get-VMIntegrationService -VMName 'VM-APP01' | Format-Table Name, Enabled, PrimaryStatusDescription
vssadmin list writers
vssadmin list providers
Get-WinEvent -FilterHashtable @{ LogName = 'Application'; ProviderName = 'VSS'; StartTime = (Get-Date).AddHours(-12) } |
Select-Object -First 25 TimeCreated, Id, MessageГость:
Get-Service vmicvss | Format-List Status, StartType
vssadmin list writersМесто и CSV:
Get-Volume | Format-Table DriveLetter, FileSystemLabel, SizeRemaining
Get-ClusterSharedVolumeState -ErrorAction SilentlyContinue
Get-StorageJob -ErrorAction SilentlyContinueЛог backup-приложения (Veeam/WBAdmin/иное) — точная фаза: create snapshot, copy, merge. Не игнорируйте «waiting for snapshot removal».
Решение
Сценарий A. Production не доступен → Saved
Включите IC VSS, службу vmicvss. В настройках VM Checkpoint: Production, с fallback standard только если осознаёте простой. В backup job включите application-aware / Hyper-V integration, не «suspend VM».
Сценарий B. Writer timeout в госте
Чините SQL VSS, диск гостя, исключение антивируса на data. Увеличьте окно, не параллельте heavy DBCC. Не отключайте writer SQL «чтобы быстрее» — получите неконсистентный backup.
Сценарий C. Залипший recovery snapshot после job
Когда job точно мёртв:
Get-VMCheckpoint -VMName 'VM-APP01'
Remove-VMCheckpoint -VMName 'VM-APP01' -Name '<имя recovery>'
Get-StorageJobЕсли не уходит — статьи checkpoint/AVHDX. Копия цепочки, если собираетесь в Merge-VHD.
Сценарий D. Шторм IO
Разнесите расписание VM, QoS, не полный backup всех гостей на одном Volume1 в одну минуту. Смотрите резервирование — иногда Replica+менее частый backup лучше, чем ежечасный full всех VM.
Сценарий E. Двойной агент
Либо backup через хост Hyper-V, либо агент в госте на те же данные — выберите одно для диска ОС/данных, не оба freeze сразу.
Зафиксируйте длительность freeze: секунды приемлемы, минуты — нет. При корректном production checkpoint гость не обязан быть Frozen весь час копирования VHDX: короткий quiesce, затем копируют overlay. Постоянный Saved на всё окно = метод Saved State.
Не запускайте Windows Server Backup хоста и агент внутри гостя на одни тома в одну минуту. Два VSS freeze, два overlay, очередь на Volume1.
После патча SQL/Exchange в госте прогоните один job вне пика, прежде чем вернуть ночное расписание парка. Writer Failed после обновления СУБД чинится writer'ом приложения, не отключением vmicvss.
Если job «успех», а avhdx остался — это не успех для диска. Следующий backup наложит вторую цепочку. Смотрите Get-VMCheckpoint сразу после job в мониторинге, не раз в месяц.
Как проверить, что проблема устранена
Тестовый job одной VM в окно. VM не уходит в Saved (для production). Heartbeat проседает секунды, не минуты. После job Get-VMCheckpoint без leftover. Writer Stable. Пользователи не фиксируют «зависание». AVHDX нет.
Get-VM -Name 'VM-APP01' | Format-List State, Heartbeat
Get-VMCheckpoint -VMName 'VM-APP01'
vssadmin list writersЕсли не помогло
- Только эта VM: writer приложения или полный диск гостя.
- Все VM: CSV/СХД/лицензия backup proxy.
- Linux: hv-vss-daemon и поддержка FS; иначе file-level/agent.
- После обновления backup-продукта сменился метод снимка — читайте release notes, не Hyper-V «сломался».
- Job Success при оставшемся avhdx считайте инцидентом диска, не зелёным backup. Следующий цикл наложит цепочку.
- Не убивайте vmms.exe «чтобы отпустило VSS»: сорвёте все VM на хосте. Останавливайте job в консоли продукта.
Профилактика
- Мониторинг leftover checkpoints каждые N часов.
- Production checkpoint по умолчанию.
- IC VSS в эталоне.
- Расписание backup vs OLTP.
- Запас места CSV под overlay.
- Регулярный restore test, не только зелёный job.
- Не ставьте стандартный checkpoint «на время backup вручную»: получите дерево плюс job. Либо продукт, либо вы, не оба.
- Окно backup и окно merge checkpoint не должны совпадать на одном Volume1.
FAQ
Standard checkpoint для backup ок?
Быстрее и без VSS гостя, но приложение как после reset + RAM-снимок. Для файловика терпимо, для СУБД — нет как единственная стратегия.
Можно ли исключить VM из VSS хоста?
Да, тогда другой метод защиты. Не оставляйте без копий.
WBAdmin vs Veeam — разная зависалка?
Механика Hyper-V VSS общая. Таймауты и proxy разные. Диагноз всё равно writers и checkpoint.
Зависание только при Full, Incremental ок?
Full дольше держит snapshot/копирует больше. Место и IO. Не «incremental лечит VSS».
Стоит ли выключать VM на время backup?
Гарантированный простой. Иногда честнее для крошечного окна, чем часовой Saved. Обычно нет, если production VSS жив.
Hyper-V Replica вместо backup?
Другой RPO/RTO, нет долгой истории и ransomware-изоляции. Дополнение, не замена. См. статью резервирования.