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

RTO — время до рабочего сервиса, не до «мастеру restore нажали». Пересчитайте: объём дисков, скорость чтения \\backup.contoso.example\Repo01, канал offsite, очередь (DC до 1С), Instant Recovery vs full copy, люди в 03:00. Если 8 ТБ по 1 Гбит — уже часы только копирования, без разбора AD. Либо снижайте обещание, либо меняйте архитектуру (IR, реплика для горячих VM, локальная копия, не только облако).

Замерьте на тесте, не на калькуляторе в презентации.

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

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

  • в договоре 2 часа, учении 2 дня;
  • ждут, пока докачается вся ферма, 1С не стартовал, хотя диски уже можно IR;
  • ключ шифрования backup в сейфе, сейф в той же горящей серверной;
  • offsite 50 Мбит, объём 4 ТБ.

Отличия от RPO: часто бэкапите, но достаёте медленно. От «VM не восстанавливается»: техника restore работает, не укладывается время.

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

  1. Никто не делил время: обнаружение + люди + решение + restore + прикладная проверка.
  2. Все VM в одном приоритете.
  3. Единственная копия offsite, канал узкий.
  4. Репозиторий на USB/NAS 100 МБ/с, обещали час для 2 ТБ.
  5. Runbook нет, ищут пароль VBR01.
  6. Зависимости: DNS, DC, DHCP, лицензии, VLAN.
  7. IR не практикуют, всегда full.
  8. Один админ в отпуске.

Диагностика

1. Разложить RTO на этапы

Таблица: минуты на объявление инцидента, доступ к VBR01, выбор точки, restore DC, restore app, smoke test. Сумма vs обещание. Обычно «restore» в голове = только копирование.

2. Скорость носителя

С теста: MB/s FLR/Entire VM. С Repo01 локально vs с облака. Запишите.

Connect-VBRServer -Server 'VBR01.contoso.example'
# время реальных restore смотрите в History restore sessions GUI

3. Порядок VM

Есть ли список: что не поднимать (тестовые), что критично. Нет списка — RTO невыполним организационно.

4. Люди и доступ

Кто в 03:00, MFA, jump-host, где учётка restore. Если только один ноутбук без VPN — RTO бесконечен.

5. Гипервизор-приёмник

Место под restore, CPU. Нет запасного хоста — копировать некуда, RTO врёт.

Посчитайте байты: сумма дисков критичных VM (не всей фермы) / наблюдаемый MB/s restore с Repo01. Добавьте 30–50% на служебные фазы (выбор точки, ожидание людей, DNS). Если выходит 7 часов при обещании 2 — спор с бизнесом сегодня, не в день аварии.

Instant Recovery сокращает копирование, но добавляет риск: IOPS Repo01 делятся между прод-пользователями IR и остальным backup. На учении измерьте latency шары во время IR одной VM. Если шара умирает — IR не ваш рычаг RTO без более быстрого репозитория.

Канал offsite: 50 Мбит × 3600 с ≈ 22 ГБ/час полезных при идеале; 4 ТБ — дни. Для смерти площадки RTO «2 часа из облака» без локальной копии — ложь. Держите local для короткого RTO, offsite для другого сценария.

Решение

Сценарий A. Пересчитать и переподписать

Покажите владельцу: 6 часов технический минимум. Либо бюджет на быстрее (IR, 10 Гбит к repo, локальная копия), либо RTO 8 часов. Молчание = конфликт в аварии.

Сценарий B. Порядок восстановления

Runbook: 1) идентификация точки 2) сеть isolate/DR 3) DC/DNS если нужно 4) файлы/SQL 5) 1С 6) остальное. Параллельте только независимое. См. документирование.

Сценарий C. Instant Recovery для горячих VM

Практика IR в песочнице заранее. В DR: IR → пользователи на IR при приемлемом IOPS → migrate на прод-диск после. Не все VM сразу с одного NAS.

Сценарий D. Узкий offsite

Держите локальную копию для RTO, offsite для уничтожения площадки (другой, честный RTO «сутки+seed»). Не обещайте 2 часа из облака 50 Мбит.

Сценарий E. Мало рук

Вторая обученная смена, пароли в vault, консоль с jump. Учение без «того самого» админа.

Сценарий F. PBS

Restore параллель ограничен IO datastore. Порядок VMID в runbook. Не restore всего кластера в один thin pool до 100%.

WSB BMR сервера 4 ТБ не будет 2 часа без расчёта диска — не ставьте такой RTO.

После изменений — прогон таймера на тесте.

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

  • Учение с секундомером: сервис X жив за ≤ RTO (или новый RTO подписан).
  • Этапы в журнале с минутами.
  • Второй человек повторил без подсказок в чате.
  • Место на приёмнике и канал соответствуют расчёту.

Не засчитывайте «мастер открылся» как конец RTO.

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

  • IR быстрый, приложение греет базу часами — RTO приложения, не backup; включите в runbook.
  • Юридически нужен чистый зал — логистика не влезает; это RTO площадки.
  • Параллельный restore валит Repo01 — меньше потоков, приоритет списка.

Не format целевые диски «для скорости», не перепутав LUN.

Разложите «время людей»: ночной звонок, MFA, поиск jump, открытие vault. На учении замерьте отдельно от копирования. Часто технический restore 40 минут, организационный час — и бумажный RTO 2 часа уже на грани без сбоя канала. Второй человек без «того самого» админа обязателен, иначе отпуск = другой RTO.

Ключ шифрования backup и BitLocker recovery должны переживать смерть серверной VBR01: иначе offsite-байты бесполезны.

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

  • RTO в паспорте вместе с RPO, пересмотр после роста данных.
  • Квартальное учение с таймером.
  • 10 Гбит до репозитория как требование к RTO часа, не «когда-нибудь».
  • Реплика горячих систем + backup (разные цели).

FAQ

Входит ли время «найти человека» в RTO?

Если обещали бизнесу — да. ИТ-только «время копирования» должно быть названо отдельно.

Можно ли RTO 15 минут на ферму?

Нужны горячие реплики/кластер, не restore с NAS. Backup закрывает другой класс отказов.

Restore одной VM 20 минут, ферма 40 VM

Не линейно, если параллелите; линейно, если одна очередь. Считайте очередь.

PBS restore быстрее Veeam?

Зависит от диска и сети, не от бренда. Меряйте.

Нужен ли DR-офис для RTO 4 часа?

Для смерти площадки — да или честный RTO «пока купим железо». Локальный сбой СХД — другой сценарий, другой RTO.

Ускорит ли отключение проверки checksum restore?

Риск тихой порчи. Не как постоянная норма ради SLA.