[Главная](https://hmbastion.com/ru/) [Блог](https://hmbastion.com/ru/blog/) Безопасность Безопасность 5 мин чтения # Проведите учения по восстановлению: превратите RPO и RTO в процедуру восстановления Успешное задание резервного копирования сообщает, что копия создана. Учения по восстановлению отвечают на более полезный вопрос: может ли команда восстановить работающий сервис с приемлемой потерей данных за время, которое проект может выдержать? Редакция HM Bastion Опубликовано 2026-10-26 ## В этом руководстве - [Разделите целевой показатель потери данных и целевой показатель времени восстановления](https://hmbastion.com/ru/blog/backup-restore-drill-rpo-rto/#define-two-targets) - [Резервируйте всё необходимое для воссоздания одного согласованного сервиса](https://hmbastion.com/ru/blog/backup-restore-drill-rpo-rto/#build-coherent-copy) - [Сделайте копию для восстановления независимой и доступной](https://hmbastion.com/ru/blog/backup-restore-drill-rpo-rto/#separate-copy-access) - [Восстанавливайте в безопасной среде и проводите конкретную проверку](https://hmbastion.com/ru/blog/backup-restore-drill-rpo-rto/#perform-safe-drill) - [Превратите результат проверки в поддерживаемый журнал восстановления](https://hmbastion.com/ru/blog/backup-restore-drill-rpo-rto/#close-recovery-loop) [Все руководства по хостингу](https://hmbastion.com/ru/blog/) ## Практический вывод Задайте явные целевые показатели восстановления, восстановите согласованную копию в изолированной среде, проверьте важное поведение приложения и зафиксируйте измеренные результаты, а не полагайтесь на достаточность расписания. ## Разделите целевой показатель потери данных и целевой показатель времени восстановления Целевая точка восстановления, или RPO, описывает момент времени, к которому данные должны быть восстановимы. Целевое время восстановления, или RTO, касается того, сколько может длиться восстановление, прежде чем прерывание окажет неприемлемое воздействие. Переведите оба показателя в деловой разговор, прежде чем выбирать программное обеспечение. Сайт-портфолио переносит прерывание иначе, чем сервис, принимающий новые заказы каждую минуту. Рассмотрим иллюстративное приложение для бронирования, владелец которого допускает потерю не более часа обновлений и стремится восстановить сервис в течение двух часов. Только ночная копия не может подтвердить часовой целевой показатель по данным: инцидент ближе к концу суточного интервала мог бы привести к потере гораздо более свежей работы. Целевые показатели в примере принадлежат этому проекту; они не являются обязательством HM Bastion по восстановлению. Выберите точную границу измерения. Зафиксируйте, когда сервис стал недоступен, когда инцидент был распознан и когда проверенный сервис вернулся. Во время плановых учений отличайте время, потраченное на пересборку, от времени, которое также потребовалось бы для обнаружения инцидента, получения разрешения и извлечения учётных данных. Отчёт только о самом быстром шаге импорта скрывает работу, задерживающую реальное восстановление. ## Резервируйте всё необходимое для воссоздания одного согласованного сервиса | Компонент восстановления | Что сохранять | Частое упущение | | --- | --- | --- | | Приложение | Идентификатор релиза, зависимости и инструкции по развёртыванию | Исходный код есть, но требуемый релиз невозможно пересобрать | | База данных | Поддерживаемая согласованная резервная копия плюс необходимые роли или конфигурация | Предполагается, что копию файлов работающей базы данных можно восстановить | | Пользовательский контент | Загрузки, документы и права доступа к хранилищу | Строки базы данных указывают на отсутствующие файлы | | Закрытая конфигурация | Восстановимые секреты и доступ к их ключам шифрования | Ключ доступен только на отказавшем сервере | | Операции | Детали DNS, запланированные задания и требования к внешним сервисам | Восстановленный сайт неожиданно отправляет реальные сообщения | Используйте метод резервного копирования, поддерживаемый движком базы данных. Логические дампы PostgreSQL обеспечивают согласованное представление базы данных, тогда как роли уровня кластера требуют отдельного рассмотрения. Резервное копирование на уровне файлов и непрерывное архивирование имеют разные требования. Логический дамп не взаимозаменяем с базовой резервной копией и архивным WAL, необходимыми для восстановления на момент времени. Выберите и протестируйте один документированный метод, а не комбинируйте несовместимые части. Согласуйте резервное копирование базы данных и загруженных файлов. Если клиент загружает документ во время копирования, резервная копия базы данных и значительно более старый архив файлов могут описывать разные состояния приложения. Определите стратегию обслуживания или согласованности, подходящую для приложения, и включите недавнее тестовое вложение в проверки восстановления. Одного количества файлов недостаточно, чтобы подтвердить соответствие нужных файлов восстановленным записям. ## Сделайте копию для восстановления независимой и доступной Храните копию для восстановления вне пути отказа, к которому вы готовитесь. Другой каталог на том же диске не поможет при потере этого диска. Копию, управляемую тем же скомпрометированным учётным данным приложения, злоумышленник также может удалить. Осознанно выберите доступ к хранилищу, срок хранения и любые средства обеспечения неизменяемости, а затем подтвердите их фактическое поведение, а не полагайтесь на название продукта. Шифруйте копии, содержащие конфиденциальную информацию, и храните ключ восстановления в рамках отдельно контролируемой процедуры. Предоставьте права людям, которым нужно восстанавливать копии, и проверьте получение с теми разрешениями, которые у них будут во время инцидента. Включите в план рост объёма хранилища резервных копий и время передачи. Копия, которая технически существует, но не может быть скачана оператором восстановления, не готова к использованию. ## Восстанавливайте в безопасной среде и проводите конкретную проверку - Выберите завершённую резервную копию и зафиксируйте её метку времени восстановления, размер и подтверждение целостности. - Подготовьте изолированное назначение с требуемыми версиями программного обеспечения и достаточным объёмом временного хранилища. - Заблокируйте реальную электронную почту, платёжные вызовы, запланированные задания и вебхуки до запуска восстановленного приложения. - Восстановите базу данных, файлы и приватную конфигурацию по документированной процедуре. - Проверьте вход, характерные записи, загруженный файл и синтетическую запись в изолированной копии. - Зафиксируйте последнюю восстановленную точку данных, длительность этапов, сбои и решения оператора. Для примера с бронированием найдите известное бронирование непосредственно перед границей резервной копии и проверьте связанного с ним клиента и вложение. Убедитесь, что ожидаемое недавнее бронирование присутствует, а намеренно более поздняя тестовая запись отсутствует. Затем создайте синтетическое бронирование в изолированной копии. Это проверяет связи и возможность записи, не связываясь с реальным клиентом и не изменяя рабочую среду. Ведите журнал этапов: получение учётных данных, подготовка назначения, скачивание, проверка, импорт, запуск приложения и приёмочные проверки. Предположим, импорт занимает двадцать минут, а согласование доступа — пятьдесят. Следующее улучшение — процедура доступа, а не обязательно более быстрый план базы данных. Сохраняйте измеренный результат, даже если он не достигает цели; неудачная репетиция выявила работу, пока сервис ещё исправен. ## Превратите результат проверки в поддерживаемый журнал восстановления Назначьте ответственного для каждой неудачной проверки и повторите затронутую часть после её исправления. Отсутствующие загрузки требуют лучшего набора резервных копий; неподдерживаемые расширения требуют воспроизводимой инвентаризации программного обеспечения. Повторяйте полную проверку после важных изменений приложения или хранилища и с частотой, обоснованной проектом. Отмечайте дату последнего успешного восстановления в рабочих заметках. Изучайте функции резервного копирования хостинга отдельно от собственной процедуры восстановления. Репликация, снимки и сохраняемые резервные копии имеют разные роли и границы отказов. Подтвердите с командой функции и объём восстановления, прилагаемые к приобретённой услуге. Проверенная процедура восстановления приложения остаётся ценной, даже если инфраструктура предлагает дополнительные средства восстановления. Примеры продуктов используют опубликованный каталог HM Bastion. Доступность, цены и доступные опции отображаются при настройке заказа. ## Выберите следующий фундамент. [Разберитесь в уровнях восстановления и защиты](https://hmbastion.com/ru/blog/ddos-protection-and-backups/) [Спланируйте контролируемую миграцию хостинга](https://hmbastion.com/ru/blog/hosting-migration-cutover-rollback/) [Подтвердите требование к восстановлению сервиса](https://hmbastion.com/ru/support/) ## Источники и дополнительное чтение - [Глоссарий NIST: целевая точка восстановления](https://csrc.nist.gov/glossary/term/recovery_point_objective) - [Глоссарий NIST: целевое время восстановления](https://csrc.nist.gov/glossary/term/recovery_time_objective) - [PostgreSQL: логическое резервное копирование и восстановление](https://www.postgresql.org/docs/current/backup-dump.html) - [PostgreSQL: непрерывное архивирование и восстановление на момент времени](https://www.postgresql.org/docs/current/continuous-archiving.html) ## Продолжить изучение [ Планирование 5 мин чтения ## Переносите хостинг с проверенным переключением и реалистичным планом отката Спланируйте данные приложения, проверки назначения, изменения DNS и момент, после которого откат потребует согласования данных. ](https://hmbastion.com/ru/blog/hosting-migration-cutover-rollback/) [ Планирование 5 мин чтения ## Запустите Docker на VPS с производственным операционным планом Спланируйте ресурсы контейнеров, постоянные данные, опубликованные порты, релизы и ограниченные журналы перед развёртыванием приложения Compose. ](https://hmbastion.com/ru/blog/docker-vps-production-checklist/)