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

RPO — сколько данных готовы потерять при отказе, не «как часто удобно админу». Снимите с владельца сервиса число (15 минут / 4 часа / 24 часа), запишите, сравните с фактическим интервалом Daily-VMs на VBR01. Если факт хуже — учащайте этот сервис (отдельный job, application backup, log shipping), не все VM сразу. Если факт чаще, чем тянет Repo01 — честно снизьте обещание или добавьте ёмкость/канал.

Пропуск слота из-за Disabled job — не запускается. Offsite RPO отдельно — нет offsite.

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

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

  • 1С «вчерашний backup бесполезен», job в 02:00;
  • админ поставил каждые 30 минут, snapshot не снимается, пользователи стоят;
  • в договоре RPO 24 ч, в презентации 15 мин;
  • логи SQL не бэкапятся, full nightly.

Отличия:

МетрикаСмысл
RPOпотеря данных по времени
RTOвремя на восстановление
Окно backupкогда можно снимать без убоя прод
Retentionкак далеко назад точки

RTO не закрывается частотой backup — RTO.

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

  1. Никто не спрашивал бизнес, поставили nightly «как все».
  2. Все VM в одном Daily-VMs с худшим общим знаменателем.
  3. Частоту подняли, proxy/Repo01 не потянули, слоты срываются — фактический RPO хуже nightly.
  4. Путают snapshot каждые 15 мин с backup.
  5. Нет log backup СУБД.
  6. Копирование на offsite раз в неделю при обещании суток.
  7. Job не стартует, RPO тихий.
  8. Редкий: CDP/continuous лицензия есть, не включили для 1–2 VM.

Диагностика

1. Обещание vs факт

Таблица сервисов: 1С, почта, файлы, DC. Колонки: обещанный RPO, job, last successful session timestamp, max дыра за месяц.

Connect-VBRServer -Server 'VBR01.contoso.example'
Get-VBRBackupSession -Name 'Daily-VMs' |
  Select-Object -First 14 CreationTime, Result, EndTime

Дыры (нет Success сутки при RPO 24 ч) — факт провален независимо от расписания «каждый день».

2. Окно и длительность

Если Daily-VMs идёт 8 часов, интервал 4 часа невозможен на этом job. Нужен split или технология без полного snapshot всех дисков.

3. Приложение

SQL/1С: есть ли backup логов / dump в другое окно. Гипервизорный nightly не даёт RPO 15 минут для БД.

4. Offsite

Последняя точка на copy. Часто local OK, offsite нет — скажите бизнесу честно про сценарий пожара.

Сведите цифры в одну таблицу на сервис, не «в среднем по ферме». Файловый сервер с nightly и 1С с потерей 15 минут в одной строке Daily-VMs дают ложный RPO для 1С. Разрежьте job или честно напишите, что 1С закрыт только native dump + этот VM job как оболочка.

Посмотрите календарь Failed за месяц: три ночи подряд красные при расписании «каждый день» — фактический RPO трое суток. Мониторинг должен орать по last success, не по «job существует».

Offsite: если copy раз в неделю, в паспорте два числа. Сценарий «сгорела серверная в понедельник» теряет до недели, даже если local RPO сутки. Не прячьте это в презентации «у нас 3-2-1».

Решение

Сценарий A. Нужно чаще для 1–2 систем

Вынесите VM из общего Daily-VMs в Hourly-1C (имя своё) с интервалом, который тянет snapshot. Остальное оставьте nightly. На Repo01 пересчитайте место. Не hourly весь зоопарк.

Сценарий B. Нужны минуты для СУБД

Не Veeam VM job каждые 5 минут как единственный ответ. Log backup native (SQL), затем VM job реже. Veeam application-aware / plugin — по документации 12, если используете. CDP — только если лицензия, железо и сеть посчитаны.

Сценарий C. Обещали лишнее

Письменно снизить RPO до ночного, если бизнес не платит за канал и СХД. Лучше честный 24 ч, чем фантазия 15 мин.

Сценарий D. Факт хуже расписания

Чините пропуски: окно, Failed, место, долго. Частота 4 ч при Success раз в 2 дня бесполезна.

Сценарий E. PBS

Job чаще на конкретные VMID, не все. prune держит глубину. Не verify+backup каждую четверть часа на одном диске.

Сценарий F. WSB

Для сервера файлов WSB несколько раз в день возможен, если VSS и диск target тянут. Для фермы VM — не масштабируется как RPO-движок.

Зафиксируйте в runbook: RPO local/offsite, job names, исключение «данные на ноутбуках не входят».

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

  • Подпись владельца: RPO принят.
  • За месяц max gap ≤ RPO (мониторинг last success).
  • Отдельные job для жёстких RPO не валят общее окно (Duration nightly стабилен).
  • Offsite gap отдельно зелёный или явно «не покрывает этот RPO».

Алерт: нет Success дольше RPO+запас.

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

  • Hourly job, snapshot leftover — верните интервал, чините VSS/datastore.
  • Бизнес не подписывает: эскалация риска, backup не «угадывает».
  • Место на Repo01 кончилось от частоты — ёмкость или меньше точек, не молчаливый Failed.

Не отключайте immutability, чтобы чаще overwrite одни и те же файлы.

Частота без глубины бесполезна против ransomware: hourly при keep 2 часа не даёт точки «до атаки в выходные». В паспорте пишите оба числа: интервал и retention. Для 1С согласуйте, что VM-job nightly плюс log backup днём — это составной RPO, не «магия Daily-VMs каждые 15 минут».

Если hourly snapshot не снимается и висит redo — верните интервал, пока не починен datastore. Сорванный слот хуже честного nightly.

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

  • RPO в паспорте сервиса при вводе VM в Daily-VMs.
  • Раз в год пересмотр: данные выросли, окно нет.
  • Мониторинг missed RPO, не только Failed.
  • Не смешивать учебные VM и 1С в одной политике частоты.

FAQ

Реплика каждые 5 минут закрывает RPO?

Закрывает потерю при смерти VM, не порчу данных (удалили таблицу — реплика удалила). Backup с задержкой всё ещё нужен.

Можно ли RPO 0?

Кластер/синхронная реплика, не классический backup. Цена и отказ другой.

Почему offsite RPO хуже?

Канал и стоимость. Это нормально, если записано.

Daily-VMs в полдень и в ночь — два full?

Настройте инкременты, не два Active Full. Иначе убьёте окно.

Кто задаёт RPO — ИТ или бизнес?

Бизнес задаёт потерю, ИТ — стоимость и факт. Итерация.

PBS hourly и prune keep 1

RPO часовой при глубине час — для ransomware бессмысленно. Частота ≠ глубина retention.