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

Долгий backup — это не «перезапустить, вдруг быстрее». Снимите, где стоит время: создание snapshot, чтение диска VM, сеть до \\backup.contoso.example\Repo01, запись на репозиторий, synthetic/transform, индексация каталога. На VBR01 в живой session Daily-VMs смотрите Bottleneck (Source / Proxy / Network / Target) и MB/s по каждой VM. Убивать сессию можно только если доказан deadlock (часами 0 байт и snapshot не снимается) — иначе получите orphan snapshot и ошибку.

WSB: смотрите, идёт ли копирование на target или застрял VSS. PBS: verify+GC в то же окно, что backup, дают «вечность».

Цель — вернуть job в окно и сохранить RPO, не «настроить всё на max parallel». Перегруз proxy — отдельная статья.

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

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

  • Daily-VMs ещё Running в 10:00 при окне до 06:00;
  • пользователи тормозят: snapshot держит диск VM;
  • MB/s в GUI прыгает около нуля, Processed почти не растёт;
  • WSB «in progress» с утра, диск target почти не растёт.

Отличия:

НаблюдениеСкорее
Нет sessionНе запускается
Failed, есть EndОшибка
Быстро, но synthetic full ночьSynthetic Full
Все job медленные, один proxyProxy перегружен
Backup ок, restore вечностьRTO

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

  1. Target: диск Repo01 saturates (RAID rebuild, антивирус, другой job).
  2. Network: 1 Гбит, WAN до репозитория, дуплекс, потери.
  3. Source: тонкий диск, высокий iowait гипервизора, CBT сброшен → почти full.
  4. Snapshot создаётся или снимается часами (VSS freeze, большой redo).
  5. Слишком много параллельных VM на одном proxy/датасторе.
  6. Каталог/индексация guest file system после каждой точки.
  7. Synthetic full / transform в том же job после инкремента.
  8. PBS: GC+verify+backup на одном диске datastore.
  9. Редкий: сжатие/шифрование на слабом CPU proxy при и так узком канале.

Диагностика

Плейсхолдеры: VBR01, Daily-VMs, \\backup.contoso.example\Repo01.

1. Где стоит живая сессия

Connect-VBRServer -Server 'VBR01.contoso.example'
Get-VBRJob -Name 'Daily-VMs' | Select-Object Name, IsRunning
Get-VBRBackupSession -Name 'Daily-VMs' |
  Where-Object { $_.State -eq 'Working' } |
  Format-List Name, CreationTime, Progress

В GUI открывайте каждую Working VM: фаза (snapshot, processing, saving), bottleneck, average speed. Запишите в тикет три цифры: Source%, Proxy%, Network%, Target% (как показывает Veeam).

2. Диск репозитория vs диск VM

На хосте backup.contoso.example (если это Windows-файлсервер):

Get-Counter '\PhysicalDisk(*)\Avg. Disk sec/Write','\PhysicalDisk(*)\Disk Writes/sec' -SampleInterval 2 -MaxSamples 5
Get-Volume | Format-Table DriveLetter, FileSystemLabel, SizeRemaining

Latency записи сотни мс → Target. На гипервизоре в то же время смотрите latency чтения диска той VM.

PBS:

iostat -xz 2 5
proxmox-backup-manager garbage-collection status

Если GC Running и iowait высокий — разнесите окна, не «ускоряйте backup большим parallel».

3. Сеть

Test-NetConnection backup.contoso.example -Port 445
Get-SmbConnection | Where-Object { $_.ServerName -match 'backup' }

С VBR01 и с proxy (если proxy отдельный). iperf между proxy и репозиторием — если политика позволяет; иначе смотрите счётчики интерфейса. 1 Гбит теоретически ~100+ МБ/с полезных; 8 МБ/с при Target bottleneck — диск, не «магия Veeam».

4. Snapshot и CBT

Долгое «Creating snapshot» / «Waiting for snapshot removal»:

  • Hyper-V/VMware: снимок в GUI гипервизора, рост delta.
  • Proxmox: qm listsnapshot 101.
  • Windows VSS: vssadmin list shadows.

Если CBT сброшен, в логе будет почти полный объём. Это один медленный прогон, не вечный баг — но окно сорвётся. Планируйте.

5. Каталог

В job включён guest file system indexing / file-level browse. На больших файловых серверах индексация после данных занимает часы. Смотрите фазу «Indexing» в session. Отключение индекса на одну ночь — диагностический шаг, не постоянный отказ от FLR.

Решение

Сценарий A. Target диск

Уберите с Repo01 антивирусный full-scan, чужой copy job, RAID rebuild в окно. Не кладите репозиторий на тот же массив, что прод-VM. Краткосрочно: снизьте параллелизм Daily-VMs до 1–2 VM, чтобы не добивать массив случайным write storm.

Сценарий B. Network

Перенесите репозиторий ближе (локальный LAN, не филиал 50 Мбит). Или backup copy job отдельно, не primary Daily-VMs через WAN. Режим транспорта proxy: если Network (NBD) и есть возможность hot-add/direct — см. proxy.

Сценарий C. Source / CBT reset

Выясните, почему сброс (VMotion, storage vMotion, crash). Один полный прогон неизбежен. Разнесите тяжёлые VM по ночам. Не сбрасывайте CBT вручную «для чистоты» без причины.

Сценарий D. Snapshot freeze

Guest-agent/VSS завис: лечите writers, не держите snapshot сутками. Если Stop job — дождитесь Remove snapshot. Потом один Start.

Сценарий E. Synthetic/transform в том же окне

Вынесите synthetic full на выходные или на окно без пользователей. Не смешивайте transform с десятком инкрементов в рабочее утро. См. Synthetic Full.

Сценарий F. PBS

Не запускайте verify всех VM и GC в то же время, что backup. Prune+GC — отдельное окно. Снизьте concurrent backups на datastore.

Сценарий G. Нужно прервать

Только если 0 байт часами и доказан lock. Stop-VBRJob, дождаться Stopped, проверить snapshot на гипервизоре. Затем причина, не сразу Start всех job.

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

Дождитесь State не Working. Проверьте leftover snapshot.

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

  • Daily-VMs укладывается в согласованное окно (время End < конец окна).
  • Bottleneck не 99% Target при пустом iostat — значит вы смотрели не тот диск.
  • Snapshot не висит после End.
  • Скорость на типичной VM сравнима с каналом/диском (порядок величины, не «максимум маркетинга»).

Сравните две session: до и после. Сохраните Duration и Processed size.

Get-VBRBackupSession -Name 'Daily-VMs' | Select-Object -First 5 CreationTime, EndTime, Result

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

  • После снижения parallel всё ещё Target 99% — диск репозитория объективно слабый; нужен другой массив/репозиторий, не «ещё настройки job».
  • Source 99% на одной SQL VM — это диск прод, backup его проявляет.
  • Быстро данные, часами indexing — отключите индекс на этом job или вынесите на другой.
  • PBS быстрый backup, долгий verify — verify не равен backup duration; не смешивайте в одной метрике.

Не отключайте шифрование job «для скорости» без решения ИБ: сначала измерьте CPU proxy. Часто упираетесь в диск, не в AES.

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

  • Базовая линия: длительность Daily-VMs в тикете раз в неделю.
  • Алерт: Running дольше N часов (N = окно + запас).
  • Не добавляйте 20 новых VM в тот же job без пересчёта окна — это RPO.
  • Разнести GC/verify/antivirus/backup.
  • Proxy и репозиторий не на одном 4-дисковом RAID1 с ОС.

FAQ

Можно ли ускорить, выключив сжатие?

Иногда, если CPU proxy 100% и канал свободен. Если Target диск 100% — сжатие может даже помогать (меньше записи). Измеряйте.

Почему инкремент стал как full?

Сброс CBT/CTK или первый прогон после добавления диска. Смотрите размер Processed vs обычный.

WSB всегда медленный на полный сервер

Он часто без CBT как у гипервизорного job. Для больших VM гипервизорный backup обычно быстрее файлового WSB.

Стоит ли Incremental forever без synthetic?

Зависит от цепочки и репозитория. Длинная цепочка замедляет transform и restore. Это компромисс, не «всегда быстрее».

Убить session через Task Manager?

Нет. Orphan snapshot и lock. Только штатный Stop и ожидание.

Параллелизм 10 — быстрее?

На одном datastore часто медленнее. Начните с 2–4 и смотрите latency прод-VM в то же время.