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

Безопасный restore-тест: другой объект + глухая сеть. Veeam: Entire VM / Instant Recovery в isolated network, имя FS01-restore-test. PBS: новый VMID, unique MAC, net отключён или dummy bridge. FLR — только в каталог RestoreTest, не в UNC продакшена. WSB — recover file в другой путь, не original folder.

Как встроить в календарь — нет проверки. Если VM уже «не восстанавливается» технически — сначала VM.

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

Типичная картина «рискованного теста»:

  • подняли restore рядом, DHCP выдал тот же IP;
  • DC restore в прод-LAN — два DC;
  • FLR сразу в \\fs01\share;
  • PBS restore 101 поверх 101.

Правильный тест выглядит скучно: VM без uplink, скрин boot, файл в C:\RestoreTest, тикет закрыт, тестовая VM удалена.

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

  1. Нет выделенного VLAN/vSwitch.
  2. Мастер по умолчанию original.
  3. DHCP в песочнице всё же слинкован с прод.
  4. AD/SQL сами регистрируются, едва появился линк.
  5. Нет свободного VMID/места — тестируют overwrite.
  6. SureBackup не настроен, «руками как получится».
  7. Политика «нельзя копировать данные» без стенда-обезлички.
  8. Редкий: backup-сеть и прод-сеть один broadcast.

Диагностика

Чеклист до кнопки Restore:

  1. Есть портгруппа bk-isolate без uplink / VLAN, который не маршрутизируется в прод.
  2. DHCP там свой или нет DHCP.
  3. Место на datastore теста.
  4. Имя/VMID свободны.
  5. Учётка restore не требует original.
  6. Антивирус на тесте не пушит в прод-карантин странно (обычно ок).
Connect-VBRServer -Server 'VBR01.contoso.example'
Get-VBRBackup -Name 'Daily-VMs' | Get-VBRRestorePoint |
  Sort-Object CreationTime -Descending | Select-Object -First 1

Точка выбрана заранее, не «последняя какая есть» в панике учений.

PBS:

qm list
pvesm status

Свободный VMID (например 210–219 зарезервировать под тесты).

Зафиксируйте в тикете учений: имя портгруппы, VMID, что оригинал 101/FS01 не выключали. Если DHCP isolate всё же раздал адрес из прод-пула — тест провален независимо от зелёного boot: вы уже в зоне split brain. Смените DHCP или уберите NIC до разбора.

Не используйте прод-DNS для тестовой VM: даже с «другим IP» она может зарегистрировать A-запись и перетянуть пользователей. Для Windows-теста достаточно консоли гипервизора и локального администратора.

Место: заранее держите 1–2 «дыры» VMID и 100+ ГБ на datastore тестов. Иначе команда в пятницу полезет в original «ну некуда».

Решение

Сценарий A. Файл (самый дешёвый)

  1. FLR точки Daily-VMs.
  2. Копировать файл в C:\RestoreTest\ на VBR01 или \\fs01\restore-inbox\.
  3. Открыть, скрин, удалить тестовую копию.
  4. Не трогать оригинал.

WSB: то же, другой путь назначения.

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

  1. Restore → Entire VM → Restore to new location.
  2. Name: FS01-restore-test.
  3. Network: bk-isolate или Disconnect.
  4. Power on.
  5. Консоль гипервизора (не RDP через прод).
  6. Проверка: диск, служба, без join/replicate.
  7. Power off, удалить тестовую VM с дисками теста, не backup.

Instant Recovery: isolated network обязателен. После теста — Stop IR, не migrate в прод.

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

Restore в VMID 210, unique MAC, удалить net или dummy.

# после restore: сеть выкл до проверки
qm set 210 --net0 virtio,bridge=vmbr-isolate
# или удалить net: qm set 210 --delete net0
qm start 210

Когда проверка кончена: qm stop 210 и удаление 210, не 101.

Сценарий D. SureBackup

Virtual lab с isolated network, application group из 1–2 VM. Не класть туда прод-DC с линком. Расписание после backup.

Сценарий E. DC / SQL / 1С

Только глухая сеть. Не давайте restore-DC увидеть прод-DC. Для SQL — не подключайте к прод-listener. Цель теста backup: ОС и файлы базы монтируются. Полный прикладной DR — отдельное учение с заказчиком.

Сценарий F. Offsite

Иногда restore с copy-repo в ту же песочницу. Доказывает, что вторая копия читается, не только local Repo01.

После любого сценария: запись в журнал (точка, длительность, кто, результат). Это кормит RTO.

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

  • Два учения подряд без duplicate IP/имени в прод.
  • Оригинал FS01/101 не изменялся (дата диска, uptime).
  • Тестовые объекты удалены, место вернулось.
  • В runbook есть скрин настроек мастера (new location, isolate).

С прод-DC: нет новых computer account FS01-restore-test в AD (если NIC был down — и не должно быть).

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

  • Нет изолированного switch — сделайте его, это час работы, не год проекта.
  • Места нет — тест FLR до появления места, не original VM.
  • Политика ПДн — обезличенная VM в job или файловый тест служебного файла.
  • SureBackup падает на сети lab — чините lab, не включайте prod network в lab.

Не используйте «временно прод-VLAN, но выключим NIC руками потом» — забывают.

Для AD/SQL держите отдельный чеклист: тестовая VM не должна видеть прод-DC даже через DNS forwarder isolate-сети. Если isolate-VLAN всё же имеет default route в 10.0.10.0/24, это не песочница. Проверьте traceroute с тестовой VM до DC до объявления «тест безопасен». Файловый тест (FLR) не заменяет этот шаг для контроллера и СУБД.

После удаления тестовой VM проверьте, что на Repo01 не осталось Instant Recovery сессии и что Daily-VMs не в Failed из-за lock IR. Иначе учение само ломает ночной RPO.

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

  • Портгруппа isolate как стандарт кластера.
  • Диапазон VMID под тесты.
  • Шаблон тикета restore-теста.
  • Запрет original в чек-листе второй парой глаз на квартальном DR.

FAQ

Можно ли тест на копии диска через клон гипервизора, не Veeam?

Это тест гипервизора, не цепочки Repo01. Для проверки backup нужен restore из backup.

IR в isolate грузит Repo01 днём

Короткий тест, не оставляйте IR на неделю. Окно как у verify.

Windows активируется / меняет SID

Нормально для песочницы. Не вводите в прод-домен.

Нужен ли отдельный VBR для тестов?

Нет. Нужна изоляция гостя. VBR01 читает repo — ок.

FLR «случайного» файла с ПДн на ноутбук админа

Копируйте на сервер restore-inbox с ACL, не на домашнюю папку. Политика данных.

PBS snapshot verify вместо boot?

Хорошо как слой 1. Boot — слой 2. Делайте оба по разному графику.