Проведите учения по восстановлению: превратите RPO и RTO в процедуру восстановления
Успешное задание резервного копирования сообщает, что копия создана. Учения по восстановлению отвечают на более полезный вопрос: может ли команда восстановить работающий сервис с приемлемой потерей данных за время, которое проект может выдержать?
Практический вывод
Задайте явные целевые показатели восстановления, восстановите согласованную копию в изолированной среде, проверьте важное поведение приложения и зафиксируйте измеренные результаты, а не полагайтесь на достаточность расписания.
Разделите целевой показатель потери данных и целевой показатель времени восстановления
Целевая точка восстановления, или RPO, описывает момент времени, к которому данные должны быть восстановимы. Целевое время восстановления, или RTO, касается того, сколько может длиться восстановление, прежде чем прерывание окажет неприемлемое воздействие. Переведите оба показателя в деловой разговор, прежде чем выбирать программное обеспечение. Сайт-портфолио переносит прерывание иначе, чем сервис, принимающий новые заказы каждую минуту.
Рассмотрим иллюстративное приложение для бронирования, владелец которого допускает потерю не более часа обновлений и стремится восстановить сервис в течение двух часов. Только ночная копия не может подтвердить часовой целевой показатель по данным: инцидент ближе к концу суточного интервала мог бы привести к потере гораздо более свежей работы. Целевые показатели в примере принадлежат этому проекту; они не являются обязательством HM Bastion по восстановлению.
Выберите точную границу измерения. Зафиксируйте, когда сервис стал недоступен, когда инцидент был распознан и когда проверенный сервис вернулся. Во время плановых учений отличайте время, потраченное на пересборку, от времени, которое также потребовалось бы для обнаружения инцидента, получения разрешения и извлечения учётных данных. Отчёт только о самом быстром шаге импорта скрывает работу, задерживающую реальное восстановление.
Резервируйте всё необходимое для воссоздания одного согласованного сервиса
| Компонент восстановления | Что сохранять | Частое упущение |
|---|---|---|
| Приложение | Идентификатор релиза, зависимости и инструкции по развёртыванию | Исходный код есть, но требуемый релиз невозможно пересобрать |
| База данных | Поддерживаемая согласованная резервная копия плюс необходимые роли или конфигурация | Предполагается, что копию файлов работающей базы данных можно восстановить |
| Пользовательский контент | Загрузки, документы и права доступа к хранилищу | Строки базы данных указывают на отсутствующие файлы |
| Закрытая конфигурация | Восстановимые секреты и доступ к их ключам шифрования | Ключ доступен только на отказавшем сервере |
| Операции | Детали DNS, запланированные задания и требования к внешним сервисам | Восстановленный сайт неожиданно отправляет реальные сообщения |
Используйте метод резервного копирования, поддерживаемый движком базы данных. Логические дампы PostgreSQL обеспечивают согласованное представление базы данных, тогда как роли уровня кластера требуют отдельного рассмотрения. Резервное копирование на уровне файлов и непрерывное архивирование имеют разные требования. Логический дамп не взаимозаменяем с базовой резервной копией и архивным WAL, необходимыми для восстановления на момент времени. Выберите и протестируйте один документированный метод, а не комбинируйте несовместимые части.
Согласуйте резервное копирование базы данных и загруженных файлов. Если клиент загружает документ во время копирования, резервная копия базы данных и значительно более старый архив файлов могут описывать разные состояния приложения. Определите стратегию обслуживания или согласованности, подходящую для приложения, и включите недавнее тестовое вложение в проверки восстановления. Одного количества файлов недостаточно, чтобы подтвердить соответствие нужных файлов восстановленным записям.
Сделайте копию для восстановления независимой и доступной
Храните копию для восстановления вне пути отказа, к которому вы готовитесь. Другой каталог на том же диске не поможет при потере этого диска. Копию, управляемую тем же скомпрометированным учётным данным приложения, злоумышленник также может удалить. Осознанно выберите доступ к хранилищу, срок хранения и любые средства обеспечения неизменяемости, а затем подтвердите их фактическое поведение, а не полагайтесь на название продукта.
Шифруйте копии, содержащие конфиденциальную информацию, и храните ключ восстановления в рамках отдельно контролируемой процедуры. Предоставьте права людям, которым нужно восстанавливать копии, и проверьте получение с теми разрешениями, которые у них будут во время инцидента. Включите в план рост объёма хранилища резервных копий и время передачи. Копия, которая технически существует, но не может быть скачана оператором восстановления, не готова к использованию.
Восстанавливайте в безопасной среде и проводите конкретную проверку
- Выберите завершённую резервную копию и зафиксируйте её метку времени восстановления, размер и подтверждение целостности.
- Подготовьте изолированное назначение с требуемыми версиями программного обеспечения и достаточным объёмом временного хранилища.
- Заблокируйте реальную электронную почту, платёжные вызовы, запланированные задания и вебхуки до запуска восстановленного приложения.
- Восстановите базу данных, файлы и приватную конфигурацию по документированной процедуре.
- Проверьте вход, характерные записи, загруженный файл и синтетическую запись в изолированной копии.
- Зафиксируйте последнюю восстановленную точку данных, длительность этапов, сбои и решения оператора.
Для примера с бронированием найдите известное бронирование непосредственно перед границей резервной копии и проверьте связанного с ним клиента и вложение. Убедитесь, что ожидаемое недавнее бронирование присутствует, а намеренно более поздняя тестовая запись отсутствует. Затем создайте синтетическое бронирование в изолированной копии. Это проверяет связи и возможность записи, не связываясь с реальным клиентом и не изменяя рабочую среду.
Ведите журнал этапов: получение учётных данных, подготовка назначения, скачивание, проверка, импорт, запуск приложения и приёмочные проверки. Предположим, импорт занимает двадцать минут, а согласование доступа — пятьдесят. Следующее улучшение — процедура доступа, а не обязательно более быстрый план базы данных. Сохраняйте измеренный результат, даже если он не достигает цели; неудачная репетиция выявила работу, пока сервис ещё исправен.
Превратите результат проверки в поддерживаемый журнал восстановления
Назначьте ответственного для каждой неудачной проверки и повторите затронутую часть после её исправления. Отсутствующие загрузки требуют лучшего набора резервных копий; неподдерживаемые расширения требуют воспроизводимой инвентаризации программного обеспечения. Повторяйте полную проверку после важных изменений приложения или хранилища и с частотой, обоснованной проектом. Отмечайте дату последнего успешного восстановления в рабочих заметках.
Изучайте функции резервного копирования хостинга отдельно от собственной процедуры восстановления. Репликация, снимки и сохраняемые резервные копии имеют разные роли и границы отказов. Подтвердите с командой функции и объём восстановления, прилагаемые к приобретённой услуге. Проверенная процедура восстановления приложения остаётся ценной, даже если инфраструктура предлагает дополнительные средства восстановления.
