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

Календарь restore-тестов — расписание учений: какой сервис, какая точка, куда (не прод), кто принимает, сколько заняло vs RTO. Минимум: раз в квартал критичные (AD-объекты/файлы/1С по очереди), раз в год — более тяжёлый сценарий. Успех job в консоли не равен «файл открылся у бухгалтера».

Никогда не проверяйте backup кнопкой restore original поверх живого FILE01. Это не тест, это инцидент.

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

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

  • «бэкапим три года, ни разу не доставали»;
  • места в репозитории мало, старые точки чистят вслепую;
  • RTO в DRP 2 часа, на бумаге ни одного замера;
  • тест «открыли Veeam, нажали Next, испугались, Cancel».

Отличия:

АктивностьНе restore-тест
SureBackup/лаборатория без критерия бизнесапочти, но зафиксируйте приёмку
Чтение лога jobпроверка backup, не restore
Откат CHGдругой процесс
DRP tabletop без кнопки restoreполезно, но не этот календарь

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

  1. Страх сломать прод.
  2. Нет изолированной сети/хоста.
  3. Нет времени в окне.
  4. Регламент backup не говорит, кто обязан тестировать.
  5. Лицензия/место не позволяют вторую VM.
  6. Редко: restore пробовали, провалили, замолчали.

Диагностика

Задайте три вопроса Ивану Петрову:

  1. Дата последнего успешного restore с актом.
  2. Куда лили (имя хоста, не «куда-то»).
  3. Кто с бизнес-стороны открыл файл/1С.

Пустые ответы — календаря нет. Сверьте, что job вообще содержит объект:

Get-ADComputer -Identity 'FILE01' | Select-Object Name, DistinguishedName
# далее сверьте имя VM в консоли backup вручную

Linux:

# пример restic: снимки есть?
sudo restic -r /mnt/repo-linux snapshots | tail
# restore в /tmp/restore-test, не в /var/lib прод

Если снимков нет — сначала регламент backup, тесты не из чего делать.

Решение

Календарь (пример)

МесяцСервисЧто достаёмКудаПриёмка
февФайлы20 случайных файлов + 1 большойRESTORE01 / диск D:owner открыл
май1Сбаза в тестовый SQLизолированный SQLглавбух отчёт
авгLinux gitрепозиторий/tmp/restoreclone успешен
нояADне прод: тестовый контроллер или объекты из backup по вашей штатной схемеlab VLANИван Петров

Чередуйте, не тащите все сервисы в одну ночь.

Правила теста

  1. Цель не в прод-VLAN или с другим IP/именем.
  2. Заявка CHG даже на тест — чтобы не спутали с аварией.
  3. Секундомер: старт restore → критерий успеха. Это ваш фактический RTO куска.
  4. Акт: дата, точка backup, результат, скрин/лог в журнал.
  5. Провал — P2 на backup, не «ну бывает».

Куда восстанавливать в маленькой Contoso

  • Отдельная VM RESTORE01 на том же гипервизоре, сеть lab без маршрута к прод-SQL.
  • Или диск/папка на jump с правами только IT.
  • Файлы: restore в \\FILE01\IT\Restore-Test\2026-09-08\, не в исходный share.
New-Item -ItemType Directory -Force '\\FILE01\IT\Restore-Test\2026-09-08' | Out-Null
# restore job в этот путь штатными средствами вашего продукта

Связь с DRP и rollback

Замер RTO кормит DRP. Умение restore кормит уверенность в rollback «вернём VM». Но календарь тестов — отдельный артефакт.

Как выбрать точку и не отравить прод

Берите точку не «самую свежую любой ценой», а ту, что соответствует RPO сервиса и точно не из окна сомнительного патча. Имя точки и job в акте. Для файлов достаточно 10–20 файлов из разных шаров плюс один большой, чтобы поймать обрезанный backup. Для 1С — тестовый запуск предприятия, не только «mdf лег».

Изоляция: VLAN lab без маршрута к 10.0.10.0/24 или firewall deny. Имя восстановленной VM FILE01-RESTORE, другой MAC/IP. DNS прод не должен начать резолвить тест. После приёмки — выключить VM, удалить по политике ПДн, запись в журнале что удалили.

Если тест сорвался из-за места в репозитории — это находка регламента backup, заведите P2, календарь не вычёркивайте, перенесите слот.

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

  • В календаре есть даты на 12 месяцев.
  • Есть хотя бы один акт за текущий квартал.
  • Owner 1С участвовал или письменно делегировал.
  • Никто не предлагает original overwrite как «быструю проверку».

Мониторинг job остаётся, но в отчёте директору фигурирует дата теста, не только «backup 100% success».

Акт теста кладите рядом с календарём, не в личную почту исполнителя. Через год смены людей календарь без актов — снова «вроде тестировали». Шаблон акта — полстраницы: сервис, точка, куда, минуты, кто принял, дефекты.

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

  • Нет второго хоста: restore файлов в папку всё равно обязателен. Полный DR site — следующий этап.
  • 1С не поднимается без лицензии на тесте: заранее договоритесь с owner о тестовом ключе/сеансе.
  • Репозиторий так медленный, что тест не влезает в окно: это находка, чините backup, не отменяйте календарь.

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

  • Новый P1-сервис сразу получает слот в календаре.
  • Алерт fail job → внеочередной restore после починки.
  • Разбор провалов без наказания за найденный гнилой backup — иначе будут врать.
  • Ссылка на календарь из общего регламента эксплуатации.

FAQ

Достаточно ли встроенной верификации репозитория?

Полезно, не заменяет открытие файла пользователем.

Как часто тестировать DC?

Реже и осторожнее файлов. Tabletop + лабораторный сценарий по документации Microsoft, не ежемесячный restore в прод.

Можно ли считать пилот миграции тестом backup?

Только если явно доставали из backup, не rsync с живого диска.

Кто присутствует?

Исполнитель IT + для 1С/файлов — представитель бизнеса хотя бы на приёмке.

Тест сорвал прод случайно. Что делать?

Это инцидент P1/P2, разбор, ужесточение изоляции. Календарь не отменяйте — исправьте лабораторию.

Нужен ли отдельный бюджет на RESTORE01?

Одна VM и диск дешевле, чем сюрприз в день аварии. Заложите в железо/лицензию честно.