Резервное копирование и восстановление¶
Требования применяются к инфраструктурной реализации backup и восстановления
production-целей с невоспроизводимым persistent state. Уровни обязательности
определены в корневом README.md.
INF-BCK-001. Цели восстановления¶
Уровень: MUST
Применяется к: каждой production-цели с capability persistent-data
Инфраструктурная конфигурация должна получать Recovery Point Objective (RPO),
Recovery Time Objective (RTO), состав защищаемых данных и срок хранения из
контракта проекта по
architecture:DATA-BACK-001–DATA-BACK-003. Расписание, topology, retention
и ресурсы backup и restore должны позволять выполнить эти значения и не должны
задавать конкурирующие цели по умолчанию.
Обоснование¶
Наличие backup без численных целей не определяет пригодность восстановления.
Проверка¶
- сопоставление проектного контракта с расписанием и retention;
- расчёт худшего RPO по расписанию;
- измерение RTO на rehearsal.
Исключения¶
Восстанавливаемые из внешнего источника данные MAY не копироваться при проверенном времени полной реконструкции.
INF-BCK-002. Копия вне отказного домена¶
Уровень: MUST
Применяется к: production backup
Как минимум одна актуальная копия должна находиться вне кластера и storage, отказ которых она покрывает. Kubernetes backup через Velero и Longhorn backup должны использовать одобренное внешнее S3-совместимое хранилище, включая MinIO в другом отказном домене.
Обоснование¶
Реплика в том же кластере не переживает потерю кластера или storage.
Проверка¶
- сопоставление topology источника и назначения;
- восстановление в чистую целевую среду.
Исключения¶
Не допускаются.
INF-BCK-003. Velero для ресурсов Kubernetes¶
Уровень: MUST
Применяется к: production Kubernetes-цели с capability persistent-data
Velero должен сохранять явно выбранные namespaced-ресурсы и требуемые CRD. Метод защиты каждого volume — CSI snapshot, File System Backup, native backup сервиса или Longhorn backup — должен быть указан отдельно. Сам факт включения Pod/PVC в Velero Backup не должен считаться доказательством application-consistency данных. Короткоживущие runtime-ресурсы не должны восстанавливаться без необходимости.
Обоснование¶
Определённый состав ускоряет восстановление и уменьшает перенос устаревшего runtime-состояния.
Проверка¶
- инспекция Backup/Restore и включённых ресурсов;
- проверка фактически выбранного метода каждого volume;
- восстановление в отдельный namespace или кластер.
Исключения¶
Эквивалентная автоматизация допустима, если проверяет тот же состав и результат.
INF-BCK-006. Регулярная проверка восстановления¶
Уровень: MUST
Применяется к: production backup
Инфраструктурная автоматизация должна выполнять и сохранять результат recovery
exercise, определённого architecture:DATA-BACK-004, с зафиксированными
backup, версиями platform/operators, длительностью этапов и результатами
инфраструктурных post-check. Расписание должно использовать максимальный
интервал из проектного контракта; инфраструктура не должна устанавливать второй
независимый интервал.
Обоснование¶
Успешная запись backup не доказывает возможность восстановления.
Проверка¶
- review последнего restore report;
- сверка контрольных данных и времени.
Исключения¶
Не допускаются.
INF-BCK-007. Согласованность данных¶
Уровень: MUST
Применяется к: backup изменяемого persistent state
Владелец должен выбрать и проверить уровень согласованности: native backup сервиса, транзакционно согласованный snapshot либо crash-consistent volume backup. Для PostgreSQL и другого транзакционного сервиса обычная копия файлов работающего процесса не должна считаться пригодной без документированной поддержки такого восстановления. Pre/post hooks MAY использоваться только с timeout, обработкой ошибки и гарантированным снятием quiesce.
Обоснование¶
Поблочная или файловая копия разных моментов времени может быть успешно записана и при этом не восстанавливаться приложением.
Проверка¶
- восстановление под нагрузкой записи;
- проверка целостности средствами сервиса;
- тест ошибки и timeout backup hook.
Исключения¶
Неизменяемые данные не требуют quiesce.
INF-BCK-008. Защита backup¶
Уровень: MUST
Применяется к: production backup
Механизм backup должен реализовывать полноту, шифрование, управление ключами,
retention и удаление по architecture:DATA-BACK-002–DATA-BACK-003.
Credential backup должен иметь минимальные права и быть отделён от credential,
которым приложение изменяет исходные данные; компрометация последнего не должна
позволять удалить все пригодные точки восстановления. Секрет доступа к backup
не должен храниться только внутри самого backup.
Обоснование¶
Компрометация приложения не должна автоматически позволять удалить все точки восстановления.
Проверка¶
- review TLS, encryption, bucket policy и credentials;
- негативный тест удаления backup credential приложения;
- проверка retention expiry.
Исключения¶
Допускается compensating control внешнего immutable/versioned storage с тем же проверяемым результатом.
INF-BCK-009. Наблюдаемость backup¶
Уровень: MUST
Применяется к: production backup job
Платформа должна экспортировать и проверять сигналы, требуемые
architecture:DATA-BACK-005, и связывать их с target и механизмом backup.
Alert на ошибку, отсутствие запуска или приближение к нарушению RPO должен
иметь владельца и runbook; порог RPO должен поступать из проектного контракта,
а не определяться второй инфраструктурной нормой.
Обоснование¶
Незапущенный scheduler не создаёт ошибочную задачу и иначе остаётся незаметным.
Проверка¶
- отключение job и контролируемая ошибка upload;
- проверка alert после нарушения RPO.
Исключения¶
Не допускаются.
INF-BCK-010. Порядок полного восстановления¶
Уровень: MUST
Применяется к: production disaster recovery
Runbook должен определять совместимые версии платформы и operators, порядок восстановления CRD, secrets, data services, volumes, migrations, workload, routes и reconciliation. Запись в восстанавливаемые данные должна быть запрещена до выбора единственного authoritative экземпляра. После восстановления должны проверяться целостность, пользовательский результат и фактическая потеря данных.
Обоснование¶
Правильные отдельные backup не гарантируют безопасный порядок сборки системы.
Проверка¶
- clean-cluster recovery rehearsal;
- попытка преждевременного запуска writer;
- измерение RPO/RTO.
Исключения¶
Частичное восстановление MAY использовать сокращённый порядок при доказанной независимости компонента.