MTB ESB Documentation

Backup и recovery

Retention, резервное копирование, восстановление и проверка целостности.

Backup и recovery

Backup защищает критичное платформенное состояние, но не превращает ESB в архив бизнес-сообщений. Для каждого компонента отдельно определяются live retention, backup scope, RPO, RTO и restore procedure.

Общие правила

  • ESB не является system of record для банковских бизнес-данных;
  • transient payload удаляется по retention policy;
  • metadata/configuration и runtime data имеют разные backup requirements;
  • Dev, Stage и Prod не разделяют backup sets;
  • backup шифруется и имеет ограниченный доступ;
  • restore регулярно проверяется практически.

Матрица компонентов

КомпонентЧто защищаемRecovery focus
WSO2API metadata, applications, subscriptions, users/roles, policiesВосстановить management/runtime configuration
KafkaCluster/topic configuration; payload — только по отдельной policyВосстановить transport, избежать неконтролируемого replay
KestraFlows, execution metadata и stateВосстановить definitions и определить судьбу executions
PostgreSQLСлужебные схемы компонентовFull restore/PITR согласно service profile
AdaptersConfig и минимальное техническое stateВосстановить connectivity и idempotency state
CallbackPending delivery/retry stateНе потерять и не задублировать уведомления

Retention не равен backup

Наличие сообщения в Kafka в пределах retention не заменяет резервное копирование конфигурации. Backup базы также не гарантирует корректный replay внешней бизнес-операции.

Backup controls

  • расписание и успешность jobs;
  • encryption at rest/in transit;
  • access and audit;
  • immutable/offsite copy при необходимости;
  • expiry и cleanup;
  • alert при пропуске backup;
  • документированная совместимость версий.

Restore procedure

  1. Определить incident scope и recovery point.
  2. Остановить conflicting writes/producers.
  3. Подтвердить backup integrity и совместимость версии.
  4. Восстановить в изолированный target или по утверждённой процедуре.
  5. Проверить schema, configuration и secrets references.
  6. Запустить component health checks.
  7. Выполнить функциональную проверку reference flow.
  8. Провести reconciliation pending operations.
  9. Открыть трафик контролируемо.

Restore test

Успешный backup считается доказанным только после restore test. Результат содержит дату, backup ID, target, duration, фактические RPO/RTO, проверки и замечания.

Data cleanup

Cleanup выполняется автоматически и наблюдаемо. Любое увеличение retention требует оценки storage, privacy/security и влияния на recovery.

On this page