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

Проверка восстановления — это календарная процедура: файл из FLR, VM в песочнице, verify цепочки Daily-VMs на \\backup.contoso.example\Repo01, не «смотрим, что job зелёный». На VBR01 включите Health check / SureBackup где уместно, плюс ручной тест по графику (ежемесячно критичное, ежеквартально полный сценарий). PBS: verify job. WSB: restore файла в тестовый каталог.

Без теста вы узнаете о дыре в RTO в день аварии. Как делать безопасно — тест без риска. Как писать — runbook.

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

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

  • в мониторинге только Failed job;
  • при учении «достать файл за 15 минут» никто не знает консоль;
  • SureBackup лицензия есть, lab нет;
  • offsite лента last-read unknown.

Отличия:

ДелаетеЭто ещё не проверка restore
Ping репозиториядоступность, не чтение цепочки
Verify checksumхорошо, но не «ОС встала»
Реплика VM живане backup-тест

Повреждения, пойманные verify, — копии повреждены.

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

  1. Нет владельца процедуры, «и так работает».
  2. Страх сломать прод.
  3. Нет isolated сети / лишнего CPU.
  4. Не измеряли время — RTO бумажный.
  5. Репозиторий busy ночью, днём «некогда».
  6. Политика запрещает копии данных на стенд (персональные данные) — нет обезличенного сценария.
  7. WSB без расписания проверки.
  8. PBS verify выключили, потому что грузил диск.

Диагностика

1. Когда последний раз реально восстанавливали

Тикеты, журнал. Если «не помним» — теста нет. Зафиксируйте дату last restore, что именно, куда.

2. Автоматика на VBR01

Connect-VBRServer -Server 'VBR01.contoso.example'
Get-VBRJob | Select-Object Name, JobType, IsScheduleEnabled, LastResult

Ищите SureBackup / backup verification. Пусто — только backup.

3. PBS

В GUI: Verify jobs, last status. Нет — дыра.

4. Соответствие RTO

Если бизнес ждёт 2 часа, а никто не проходил процедуру — RTO не подтверждён. Это отдельная статья, но диагностика начинается здесь: нет замера.

5. Кого нет в журнале

Если FLR делали «для пользователя» в тикете поддержки — это не календарный тест: нет процедуры, нет isolated, часто original path. Отметьте отдельно. Календарный тест обязан иметь: выбранную точку Daily-VMs, путь назначения RestoreTest, имя исполнителя, минуты, скрин дерева FLR или boot VM.

Windows Server Backup: в журнале должна быть версия wbadmin get versions и путь, куда положили файл, не «вроде восстанавливали в 2024». PBS: номер snapshot и VMID теста, не «verify когда-то зелёный».

Сверьте, что тест читает тот репозиторий, с которого планируете спасаться при пожаре: если offsite никогда не открывали, local Success не доказывает DR.

Решение

Сценарий A. Минимальный ритм (начать с понедельника)

  1. Еженедельно: FLR одного случайного файла из Daily-VMs в \\fs01.contoso.example\restore-inbox\test\ (или локальный каталог на VBR01). Удалить тестовый файл после фиксации скрина.
  2. Еженедельно: Health check последней точки или verify PBS snapshot одной VM.
  3. Журнал: дата, точка, результат, минуты.

Это уже закрывает «совсем нет проверки».

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

Лаборатория: isolated virtual lab в Veeam, DC не нужен для файла. Для приложения — песочница. Расписание SureBackup после Daily-VMs, не параллельно тяжёлому окну, если Repo01 слабый.

Сценарий C. PBS

Verify job по расписанию вне backup. Раз в месяц: restore VM в свободный VMID, сеть down, boot, скрин, удалить тестовую VM.

Сценарий D. WSB

Календарь: restore одного файла с Repo01 в C:\RestoreTest. Раз в квартал — файл с другого тома.

Сценарий E. Персональные данные

Стенд с маскированием или VM, где нет ПДн (шаблон, служебная). Не отменяйте тесты «из-за 152-ФЗ» без юридического сценария: проверка целостности IT-системы обязательна, способ выбирайте совместно.

Сценарий F. Лента/offsite

Раз в квартал доставить/прочитать одну кассету или restore из object. Иначе offsite — декорация.

Не включайте все VM в SureBackup в первую ночь — убейте Repo01 IOPS. Начните с 1–2.

Журнал ведите там, где его найдут в аварии: не только в голове и не только на VBR01. Минимум — тикет с тегом restore-test и дата next. Если verify Failed, это не «шум мониторинга»: эскалируйте как повреждённые копии, не выключайте job verify.

Для приложений с лицензионным ключом на железо заложите в тест не «активация Windows», а «служба слушает порт». Иначе квартальный boot-тест зелёный, а RTO врёт на часы активации.

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

  • В календаре (wiki/тикет) есть будущие даты тестов и прошедшие с результатом.
  • Last FLR < 7–31 день (как договорились).
  • Last VM boot test < квартал для критичных.
  • Алерт, если SureBackup/verify Failed — как P2/P1, не игнор.

Сверьте, что тесты идут с тех же репозиториев, с которых будете спасаться (включая copy/offsite хотя бы иногда).

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

  • FLR ок, VM не грузится — расширьте тест, не радуйтесь только файлу.
  • Verify грузит диск, job backup красный — разнесите окна, не выключайте verify навсегда.
  • «Нет времени» — уменьшите scope, не отменяйте ритм.
  • Тесты только с primary, offsite никогда — дыра DR.

Не объявляйте DR готовым по зелёному Daily-VMs.

Календарь должен переживать отпуск «того, кто помнит»: steward плюс зам. Если verify Failed три раза подряд — не выключайте его, разберите как повреждение. Тикет restore-test без скрина точки и пути назначения не засчитывайте: иначе через год снова «вроде проверяли».

Для WSB заведите ту же ритмичность, что для Veeam: иначе гибридная ферма живёт иллюзией, что Daily-VMs закрыл и физический сервер с отдельной политикой.

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

  • Владелец: роль «backup steward», не «кто свободен».
  • В SLA: не только RPO, но частота restore-теста.
  • Автоматический verify + человеческий boot-тест.
  • После смены репозитория/прокси — внеочередной тест.

FAQ

SureBackup платный/тяжёлый — чем заменить?

FLR + ручной restore VM в isolate + PBS verify. SureBackup удобен, не единственный путь.

Портит ли тест цепочку?

Чтение не должно. Запись в original — да. Поэтому только side path.

Сколько держать тестовую VM?

Часы, не недели. Имя *-restore-test-*, сеть isolated, потом delete теста.

Нужен ли тест каждой VM?

Критических — чаще. Остальных — выборка. Ротация, чтобы за год покрыть важные.

WSB Automatic backup = проверено?

Нет.

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

Владелец сервиса, не только админ backup. Иначе «ОС встала» ≠ «бизнес работает».