Короткий ответ

Пока не прочитали последнюю session целиком, повторный Start — лотерея: вы добьёте snapshot, диск репозитория и окно. На VBR01 откройте Daily-VMs → History → failed session → первую фатальную строку (не Warning в конце). Классика: нет места на \\backup.contoso.example\Repo01, snapshot гипервизора, VSS writer, права, сеть до proxy. Исправьте причину, затем один контролируемый прогон.

Windows Server Backup: wbadmin get status и журнал Microsoft-Windows-Backup, не «ещё раз Backup Once». PBS: Task log узла, не «Restart all VMs backup».

Детальный разбор Veeam (guest processing, proxy) — Veeam job failed. Здесь — общий алгоритм для WSB, Veeam и PBS.

Симптомы и как отличить

Типичная картина:

  • галка красная, есть время Start и End;
  • часть VM в job Success, одна Failed;
  • WSB: операция завершилась отказом, каталог на target пустой или обрезан;
  • PBS: TASK ERROR в конце, snapshot на datastore не появился или partial.

Отличия:

Что видноНе эта статья
Нет session вообщеНе запускается
Session Running 8 часовСлишком долго
Job Success, restore врётКопии повреждены
Только Veeam guest/proxy нюансыVeeam job failed
Диск репозитория 0 байтРепозиторий заполнен

Возможные причины

  1. Репозиторий или datastore без свободного места; квота SMB/PBS.
  2. Snapshot/VSS: writer failed, CBT, зависший предыдущий снимок.
  3. Сеть: обрыв до backup.contoso.example, timeout proxy, stale NFS.
  4. Права учётки job/службы на share или на API PBS.
  5. Guest processing (SQL freeze) роняет объект, хотя диск скопировался бы без приложения.
  6. Цепочка: synthetic/merge падает; инкремент «успешен» визуально в середине лога.
  7. Антивирус на репозитории лочит файлы цепочки.
  8. Редкий: I/O error диска источника во время чтения.

Диагностика

Не запускайте job параллельно с разбором: второй snapshot на той же VM усугубит.

1. Вытащить текст ошибки, не скрин кнопки

Connect-VBRServer -Server 'VBR01.contoso.example'
$s = Get-VBRBackupSession -Name 'Daily-VMs' | Sort-Object CreationTime -Descending | Select-Object -First 1
$s | Format-List Name, Result, CreationTime, EndTime, FailureMessage
Get-VBRTaskSession -Session $s |
  Where-Object { $_.Status -ne 'Success' } |
  Format-Table Name, Status

Первая VM со Status Failed — якорь. Дальше лог этой VM в GUI (каталог логов Veeam на VBR01).

Windows Server Backup:

Get-WBJob -Previous 1 | Format-List
Get-WinEvent -LogName Microsoft-Windows-Backup -MaxEvents 20 |
  Select-Object TimeCreated, Id, LevelDisplayName, Message
wbadmin get versions -backupTarget:\\backup.contoso.example\Repo01

PBS / PVE:

journalctl -u proxmox-backup -n 80 --no-pager
# Task log конкретной VM смотрите в GUI PVE (Backup) или /var/log/pve/tasks/

2. Место и доступность цели

Get-VBRBackupRepository | Format-Table Name, Type
Test-Path '\\backup.contoso.example\Repo01'

На хосте share:

Get-Volume | Format-Table DriveLetter, FileSystemLabel, SizeRemaining, Size

PBS:

proxmox-backup-manager datastore list
df -hT

Нулевое место → репозиторий заполнен, не Retry.

3. VSS и снимки источника

На проблемной Windows-VM / гипервизоре:

vssadmin list writers
vssadmin list shadows

Writer не Stable — guest processing и WSB будут падать. Не vssadmin delete shadows /all «для очистки», пока не поняли, чей снимок: backup, другой продукт, ручной.

На Proxmox для VM 101:

qm listsnapshot 101
qm config 101

Leftover snapshot после failed backup — частая вторая ошибка при Retry.

4. Сеть в момент сбоя

Время End в session сравните с обрывом линка, reboot backup.contoso.example, failover iSCSI. Одна строка про недоступный сетевой путь важнее десяти Retry.

Решение

Сценарий A. Нет места / quota

Освобождайте retention политикой, не руками самые свежие файлы цепочки. См. заполненный репозиторий. После появления запаса — один прогон Daily-VMs.

Сценарий B. Snapshot / VSS

  1. Доведите writers до Stable (служба VSS, диск, SQL VSS writer).
  2. Удалите зависший снимок гипервизора штатным GUI/qm, не сырой rm диска.
  3. Временно выключите application-aware на одной VM, чтобы доказать класс ошибки — и верните, когда writer жив. Копия без приложения для SQL не замена.

Сценарий C. Права и share

ACL: contoso\svc-veeam Modify на \\backup.contoso.example\Repo01. Для WSB — учётка задачи. Для PBS — токен с правом записи в datastore, не только Audit. После смены пароля службы — перезапуск службы, не reboot всего кластера.

Сценарий D. Сеть / proxy

Если падает на отправке данных — смотрите proxy и канал до репозитория. Снизьте параллелизм job (одну VM), подтвердите Success, верните параллелизм.

Сценарий E. PBS TASK ERROR

Читайте последнюю строку: lock, space, fingerprint, timeout guest-agent. Не убивайте qemu. Fingerprint/квота — не «пересоздать datastore».

Сценарий F. Частичный успех job

Не считайте job зелёным, если одна VM красная. Либо исключите VM осознанно с заявкой, либо чините её. Повтор всего Daily-VMs из-за одной VM может сорвать окно остальных.

После фикса причины:

Start-VBRJob -Job (Get-VBRJob -Name 'Daily-VMs')

Только один Start, дождитесь конца. Параллельный второй — lock.

Как проверить, что проблема устранена

  • Новая session Daily-VMs: Result Success (или Warning без фатального FailureMessage).
  • На Repo01 появилась новая точка с временем после фикса.
  • WSB: wbadmin get versions показывает новую версию; writers Stable.
  • PBS: snapshot виден в datastore, verify по политике не красный сразу после создания.
Get-VBRBackupSession -Name 'Daily-VMs' | Select-Object -First 1 Result, EndTime, FailureMessage
Get-VBRBackup -Name 'Daily-VMs' | Get-VBRRestorePoint | Sort-Object CreationTime -Descending | Select-Object -First 3

Пробный файловый restore одного тестового файла в каталог, не на оригинал — см. файл из backup.

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

  • Та же первая строка после фикса «места»: вы чистили не тот том (каталог Veeam vs share).
  • Ошибка прыгает по разным VM — канал или антивирус на репозитории.
  • Только одна VM, остальные OK — диск этой VM, snapshot, passthrough, agent.
  • Success в GUI, restore не открывает точку — повреждены, не эта статья.

Не отключайте Windows Defender «навсегда». Исключение каталога репозитория — точечно, документировано.

Профилактика

  • Алерт по Result Failed и по Warning-only, если RPO критичен.
  • Запас на репозитории (не 100% filled), мониторинг свободных гигабайт.
  • После патча SQL/Exchange — проверка VSS writers до ночного окна.
  • Не класть антивирус full-scan на Repo01 в то же окно, что Daily-VMs.
  • Хранить экспорт последней ошибки в тикете, не только «перезапустил, помогло».

FAQ

Retry в job — это лечение?

Нет. Retry имеет смысл при обрыве сети. При нехватке места и writer failed Retry повторит ту же смерть.

Можно ли игнорировать Failed одной VM в большом job?

Только если VM выведена из продакшена письменно. Иначе RPO этой VM сорван.

WSB пишет completed with warnings — это ошибка?

Часто пропущен том или VSS. Читайте, какой том не вошёл. Для «полный сервер» Warning = дыра.

Нужно ли пересоздавать job Daily-VMs?

Почти никогда. Пересоздание теряет историю и цепочку. Лечите причину session.

PBS: verify красный, backup зелёный

Данные могли записаться криво. Не удаляйте snapshot до разбора; см. повреждённые копии и verify job.

Стоит ли включать подробные логи навсегда?

Нет. Временно на одно окно, потом вернуть: подробный лог забивает диск VBR01.