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

Перегруженный backup proxy на Veeam 12 выглядит как «медленный backup» и как Failed по timeout. На VBR01 найдите, какой proxy берёт Daily-VMs, сколько Max concurrent tasks, какой транспорт (Automatic / Direct storage / Virtual appliance HotAdd / Network NBD). Снизьте параллелизм, разнесите job по proxy, выберите транспорт, который не гоняет диск VM через узкий NBD, если есть HotAdd/Direct. Не ставьте второй такой же job «для скорости».

Windows Server Backup и PBS своих «Veeam proxy» не имеют: узкое место там — узел PVE/PBS или сам сервер WSB. Не ищите proxy в PBS GUI.

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

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

  • в session десяток VM Pending, одна Processing;
  • Bottleneck Proxy, CPU proxy 100%;
  • HotAdd диски копятся на proxy-VM, iowait хоста;
  • NBD: канал 1 Гбит в потолок, прод-LAN страдает.

Отличия:

КартинаСтатья
Target 99%, proxy свободендиск Repo01, долго
Fail VSSjob failed
Окно не вмещает даже при 1 задачеRPO / ёмкость
Restore тоже вечностьRTO

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

  1. Max concurrent tasks слишком большой для CPU/диска proxy.
  2. Один proxy на все job ночи.
  3. Транспорт NBD при доступном HotAdd/Direct.
  4. Proxy — VM на том же перегруженном datastore, что прод.
  5. Proxy не видит LUN (Direct) и молча деградирует в NBD.
  6. Сжатие/шифрование на слабом CPU.
  7. Synthetic/transform идёт через тот же proxy.
  8. Редкий: антивирус на proxy сканирует поток backup.

Диагностика

1. Кто proxy в логе Daily-VMs

В failed/slow session строка used proxy. GUI: Infrastructure → Backup Proxies → Tasks. Совпадает ли имя с ожидаемым PROXY01.

2. Счётчики на proxy

Get-Counter '\Processor(_Total)\% Processor Time','\PhysicalDisk(_Total)\% Disk Time' -SampleInterval 2 -MaxSamples 5
Get-NetAdapterStatistics

CPU 100% при сжатии + 8 задач — снижайте задачи. Диск 100% при HotAdd — proxy бьёт тот же массив, что VM.

3. Транспорт

В логе VM: Network / HotAdd / Direct Storage Access. NBD + 20 VM — прогноз «до утра не уложитесь». Direct требует, чтобы proxy (физический) видел тот же storage, что гипервизор; иначе Direct не взлетит.

4. Связь proxy → Repo01 и proxy → хост

Test-NetConnection backup.contoso.example -Port 445
Test-NetConnection esxi01.contoso.example -Port 443

Подставьте свои гипервизор и порты управления. Нет пути — не «добавить задач».

5. Очередь job

Несколько job на одном proxy с суммарным concurrent выше лимита. Сложите цифры.

Решение

Сценарий A. Слишком много задач

На proxy снизьте Max concurrent tasks до того, что диск/CPU держат (часто 2–4 на слабом, больше на выделенном). В Daily-VMs ограничьте parallel VM. Прогон одной тяжёлой VM для проверки.

Сценарий B. Разнести load

Второй proxy: для другого кластера / другого VLAN до Repo01. Назначьте job явно (Job → Storage → proxy), не оставляйте «все proxy», если один слабый всегда выигрывает гонку и захлёбывается.

Сценарий C. Сменить транспорт

  • HotAdd: proxy как VM с доступом к дискам VM (SCSI). Следите, чтобы proxy не жил на самом узком datastore.
  • Direct: физический proxy с презентацией LUN (осторожно с масками).
  • NBD: запасной путь, не основной на 1 Гбит для десятков дисков.

После смены — один job, сравнение Duration.

Сценарий D. Proxy-VM на том же SSD, что прод

Вынесите proxy на отдельный хост/диски. Иначе backup ускоряет iowait продакшена — вы «оптимизируете» в минус.

Сценарий E. CPU на сжатии

Если канал и диск свободны, а CPU 100% — снизьте уровень сжатия job или дайте proxy больше vCPU. Не выключайте шифрование без ИБ.

Сценарий F. PBS/PVE «как proxy»

Нет. Снижайте concurrent vzdump/PBS job на узле, разносите VM по узлам, не путайте с Veeam proxy.

После изменений дождитесь Idle и запустите контролируемый Daily-VMs (или subset).

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

  • Очередь Pending не растёт часами.
  • Bottleneck не Proxy 99% при здоровом Target/Network.
  • Окно Daily-VMs соблюдено.
  • Прод latency на время backup не хуже базовой линии (смотрите гипервизор).

Сравните две session: Duration, средний MB/s, имя proxy, транспорт.

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

  • Снизили tasks — уперлись в Target: это диск репозитория.
  • HotAdd не выбирается: права proxy-VM, контроллер SCSI, исключённые datastore.
  • Direct не выбирается: zoning/маскинг LUN, Windows не видит диск (и не нужно предъявлять прод-LUN всем Windows без проекта).
  • Timeout остался — сеть к хосту API, не CPU.

Не отключайте firewall между proxy и хостами «чтобы измерить»; откройте порты по схеме 12.

Если после смены транспорта Duration не изменился, вы смотрели не тот proxy: в логе VM должно появиться новое имя и слово HotAdd/Direct/Network. Automatic мог оставить NBD. Зафиксируйте режим в job. Не добавляйте третий proxy «на удачу» в ту же 1 Гбит сеть до Repo01 — получите три очереди в один канал.

На время разбора снизьте Daily-VMs parallel до 1–2, чтобы отделить proxy от datastore VM. Если одна VM всё ещё Source 99% — это диск гостя, не Max tasks.

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

  • Выделенный proxy под кластер, лимиты задокументированы.
  • Алерт: proxy CPU/disk и job duration.
  • После storage vMotion — проверка транспорта в следующей session.
  • Не добавлять 30 VM в Daily-VMs без пересчёта proxy.
  • Synthetic full не в том же пике, что инкременты всех VM.

FAQ

Больше RAM на proxy поможет?

Если упираетесь в кэш сжатия — иногда. Чаще диск и concurrent. Сначала счётчики.

On-host vs off-host proxy?

Off-host снимает CPU с гипервизора прод, но требует правильный транспорт. On-host (гипервизор как proxy) конкурирует с VM за CPU.

Можно ли backup через WAN тем же proxy?

Primary job — нет, если RPO ночной. Backup copy — другой канал и окно.

Windows Server Backup на файловике грузит «proxy»?

Нет proxy. Грузит CPU/диск самого сервера и путь к Repo01.

Нужно ли выключать антивирус на proxy?

On-access на потоке backup вреден. Исключение каталогов Veeam на proxy — документировано, не Defender Off.

Automatic vs ручной транспорт навсегда?

После стабилизации зафиксируйте рабочий режим в job, чтобы ночной «автомат» не уехал в NBD после изменения инвентаря.