Backup не является disaster recovery. Он только один из материалов, из которых восстановление может быть собрано

RPO показывает, сколько данных допустимо потерять.

RTO — сколько времени допустимо восстанавливать.

RPO 24 часа и RTO сутки допускают простую модель.

RPO почти ноль и RTO минуты требуют репликации, автоматизации, резервных environments и другой стоимости.

AMPE выводит технический DR из бизнес-требований, а не наоборот.

Replica помогает при отказе узла.

Но может мгновенно реплицировать ошибочное удаление.

Backup помогает вернуться к прошлому состоянию.

Но восстановление может занять время.

DR site помогает пережить потерю зоны или площадки.

Но сам требует синхронизации и регулярной проверки.

Сильная стратегия использует комбинацию под конкретные failure scenarios.

Когда простой IT-системы имеет критический бизнес-эффект.

Когда RTO/RPO существуют только на бумаге.

Когда backup делается, но restore не тестируется.

Когда зависимые сервисы имеют разные планы восстановления.

Когда multi-region или резервный ЦОД рассматривается без полной карты зависимостей.

Когда нужно защититься не только от hardware failure, но и от ransomware, человеческой ошибки или логического повреждения данных.

Когда аварийное восстановление зависит от нескольких конкретных инженеров.

Приложение поднялось.

Но identity недоступна. Очередь не восстановлена. Секреты не загружены. Внешний канал не переключён.

Функция для пользователя всё равно не работает.

AMPE строит recovery dependency graph от бизнес-сервиса до всех необходимых компонентов.

«База восстановилась» — технический факт.

Сильнее: приложение подключилось; данные согласованы; критическая операция проходит; интеграции работают; время уложилось в RTO.

Только после этого сценарий подтверждён.

Active-active снижает время переключения и может использовать обе площадки.

Но требует более сложной data consistency, routing и operational discipline.

Если бизнес не требует почти мгновенного восстановления, active-passive может быть проще и надёжнее.

AMPE выбирает topology по требованиям и способности команды её эксплуатировать.

Кто объявляет disaster. Какой порядок. Какие проверки. Где credentials. Что делать при неуспешном шаге. Как подтвердить восстановление. Как вернуться в основной режим.

Чем больше шагов можно автоматизировать безопасно, тем меньше зависимость от человеческой памяти.

BIA задаёт критичность.

RTO/RPO задают требования. Failure scenarios определяют topology. Backup и replication защищают данные. IaC и automation восстанавливают среду. Runbooks управляют переключением. Tests подтверждают реальную готовность.

Так DR становится инженерным свойством системы.

Backup получает проверенный recovery path.

RTO/RPO подтверждаются тестом, а не документом.

Зависимости сервиса учитываются в правильном порядке.

План восстановления меньше зависит от отдельных людей.

Topology соответствует реальной цене простоя.

И главное — серьёзный отказ превращается из импровизации в заранее отработанный технический сценарий.