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

Восстанавливайте VM рядом, не «на место»: другой inventory name, другой VMID на PBS/PVE, сеть без маршрута в прод (isolated / dummy vSwitch), NIC disconnected или отдельный VLAN. На VBR01 мастер Entire VM / Instant Recovery для точки Daily-VMs — Destination не Original location. Оригинал, если он ещё дышит, не выключайте «чтобы имя освободить», пока не сравнили.

BMR железа — отдельная статья. Файл внутри — FLR.

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

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

  • мастер ругается, что VM с таким именем уже есть;
  • Instant Recovery стартовал, прод «поехал» (тот же IP);
  • PBS: restore 101 поверх 101, диск оригинала уничтожен;
  • restore падает на записи в datastore гипервизора (нет места), не в репозитории.

Отличия:

СимптомСтатья
Мастер не стартуетRestore не запускается
Чтение точки CRCПовреждены
Нужен физический серверBMR
Долго, но штатноRTO

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

  1. Оператор выбрал original location.
  2. Конфликт имени в vCenter/Hyper-V/PVE.
  3. Нет места на целевом datastore гипервизора (это не Repo01).
  4. Точка повреждена / не та VM в job.
  5. Instant Recovery без isolated network.
  6. PBS restore в существующий VMID.
  7. Лицензия гипервизора/хост не принимает VM.
  8. UEFI/Secure Boot/диск контроллер не совпал, VM не грузится после успешного copy — это уже гостевая загрузка, не «restore не пишется».

Диагностика

1. Что выбрано в мастере

Скрин Destination: host, datastore, name, network. Должно быть: имя FS01-restored, сеть No-Uplink / isolated, Restore disk не на тот же LUN, где оригинал, если оригинал жив.

2. Точка и целостность

Connect-VBRServer -Server 'VBR01.contoso.example'
Get-VBRBackup -Name 'Daily-VMs' | Get-VBRRestorePoint |
  Where-Object { $_.Name -match 'FS01' } |
  Sort-Object CreationTime -Descending | Select-Object -First 5

При сомнении — verify точки. Не original restore «на пробу».

3. Место на гипервизоре

Целевой том VM ≠ \\backup.contoso.example\Repo01. Проверьте free space хоста, куда кладёте диски. Instant Recovery ест IOPS репозитория: смотрите нагрузку Repo01.

PBS:

pvesm status
qm list

Не занимайте VMID 101, если 101 жив.

4. Сеть песочницы

Есть ли vSwitch без uplink, VLAN, который не ходит в 10.0.10.0/24 прода. Без этого «тест» станет инцидентом.

Решение

Сценарий A. Veeam Entire VM в изоляцию

  1. Restore → Entire VM → точка.
  2. Restore to new location / different name.
  3. VM name: FS01-restore-20260908.
  4. Network: disconnected или isolated port group.
  5. Power on после проверки NIC disconnected, если изолированной сети нет.
  6. Снимите скрин, что IP не раздан в прод-DHCP.

После проверки гостя — либо migrate на прод-storage по runbook, либо отдайте файлы и удалите тестовую VM, не оригинал.

Сценарий B. Instant Recovery

IR в isolated network. Не Production network. Storage vMotion/migration на прод-диск — только когда ОС встала и владелец подтвердил. Пока IR с Repo01, не гоняйте тяжёлый Daily-VMs на ту же шару без нужды.

Сценарий C. PBS / Proxmox

# новый VMID, не 101
qmrestore /mnt/pve/backup/dump/vzdump-qemu-101-*.vma.zst 210 --unique 1
# для PBS: Restore в GUI на VM 210, unique MAC

--unique / unique MAC обязательны. Сеть в конфиге 210 — bridge без продакшена или net0 закомментировать до первой загрузки.

Сценарий D. Конфликт имени

Не delete original. New name. В AD не вводите restored VM в домен, пока NIC в изоляции: иначе computer account. Для теста часто достаточно локального входа.

Сценарий E. Restore пишется, VM не грузится

Диски на месте — это загрузчик, Secure Boot, контроллер SCSI. Лечите как гостевую ОС на копии, не откатывайте оригинал. Сравнение с точкой старше.

Сценарий F. Нужно заменить прод (оригинал мёртв)

Тогда overwrite осмыслен, но:

  1. Докажите, что оригинал не вернётся (диск мёртв, удалили осознанно).
  2. Снимок/копия оригинала, если ещё есть байты.
  3. Restore original location после записи в тикет.
  4. Сеть: один IP, не два.

Пока оригинал «может быть жив» — только side-by-side.

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

  • В инвентаре две VM: оригинал (если был) и *-restore-*.
  • У restore нет линка в прод-LAN (ping с DC не должен идти на новый MAC в прод-подсети).
  • Гость грузится, сервисы слушают на изолированном IP.
  • Контрольный файл/БД на месте относительно выбранной точки.

Для PBS: qm status 210 running, 101 не исчез.

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

  • Ошибка на чтении репозитория — целостность точки, другой timestamp.
  • Нет места на гипервизоре — чистите не Repo01, а VM-datastore, или другой хост.
  • IR ок, migrate падает — права/место на целевом storage.
  • Windows на restore требует reactivation / другой NIC — ожидаемо в песочнице.

Не отключайте immutability «чтобы быстрее клонировать точку».

После успешного side-by-side не оставляйте тестовую VM на прод-datastore «на всякий»: она жрёт место и риск включения NIC. Удалите тест после smoke, точку на Repo01 не трогайте. Если IR оставили на ночь — утром Daily-VMs и пользователи шары будут делить IOPS репозитория.

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

  • Runbook: имя шаблона *-restore-YYYYMMDD, VLAN isolate, DHCP isolate.
  • Учение раз в квартал — тест без риска.
  • Запрет original overwrite без двух человек (оператор + владелец).
  • Место на гипервизоре под restore заранее, иначе RTO врёт.

FAQ

Можно Instant Recovery сразу в прод-сеть, если оригинал выключен?

Только если runbook так предписывает для DR и IP/имя согласованы. Для «проверить backup» — нет.

PBS restore без unique MAC

Конфликт в bridge. Всегда unique, пока обе VM могут оказаться online.

Нужно ли снимать snapshot оригинала перед restore рядом?

Не обязательно для side-by-side. Обязательно подумать, не пишет ли оригинал в те же LUN, куда вы кладёте диски restore.

Restore DC из backup в изоляции

Да, и только в изоляции. Два DC с одним invocationID в одном LAN — катастрофа. Не restore DC «на место» без процедуры AD.

WSB умеет Entire VM?

WSB — образ машины/томов, не гипервизорный job. Для VM смотрите Veeam/PBS. WSB на госте восстанавливает ОС как BMR/файлы.

После IR забыли migrate — что будет?

Репозиторий станет продакшеном по IOPS. Срок IR ограничен здравым смыслом и вендором; мигрируйте или выключайте тест.