План восстановления IT: что запускать первым и сколько простоя допустимо
План восстановления должен возвращать рабочий процесс компании: приём заказов, доступ к документам или связь с клиентами. Сначала определите допустимую потерю данных и срок простоя, затем расположите системы по зависимостям. Запишите ответственных, доступ к копиям и проверку результата. Подтвердите план пробным восстановлением на отдельной площадке.
Что понадобится для плана
- Список критичных рабочих процессов и систем, от которых они зависят.
- Доступные копии, ключи и порядок получения подходящего нового сервера.
- Координатор восстановления, технический исполнитель и сотрудники, которые проверят рабочий результат.
Опишите, что потеряно и что осталось #
В оптовой компании утром отказал основной сервер с CRM, базой и файлами. Копии виртуальных машин есть на отдельном Proxmox Backup Server, данные приложения — в restic вне основного хоста. Руководителю нужно вернуть оформление заказов, а не просто включить сервер.
Один файл или одна машина. Удаление документа и отказ виртуальной машины требуют разных действий. Определите, можно ли вернуть часть данных без восстановления всех систем.
Основной хост. Запишите, где взять новый сервер, кто откроет копии и какие данные остались доступны. Копия на диске сломанного хоста не является независимой.
Вся площадка. Если резервный сервер зависит от того же помещения и оборудования, нужна ещё одна доступная копия. Укажите, как исполнитель получит её и ключи.
Для каждого случая опишите простыми словами, что потеряно и что сохранилось. Это помогает выбрать правильную копию и не тратить время на неподходящий порядок действий. Отдельно укажите связь с сотрудниками, если привычный чат тоже перестал работать.
Согласуйте потерю данных и время простоя #
RPO — допустимая потеря последних изменений. RTO — срок возвращения согласованной работы. В примере руководство допускает потерю до 60 минут изменений CRM и четыре часа до оформления заказов. Расписание копий и пробная проверка должны соответствовать этим требованиям.
Одна ночная копия не обеспечивает потерю не больше часа в середине рабочего дня. Быстрый запуск виртуальной машины тоже не подтверждает, что CRM готова. В срок включите обнаружение, получение оборудования, передачу данных, восстановление и проверку сотрудником.
Согласуйте временную работу: менеджер записывает заказы в отдельный журнал с уникальными номерами, чтобы затем перенести их без дублей. Руководитель решает, когда включить этот порядок и кому сообщить задержку. Для файлов и чата допустимые сроки могут отличаться.
Чем меньше допустимая потеря и простой, тем больше ресурсов потребуют копирование и проверки. Не задавайте одинаковые требования ради удобной таблицы. Начните с процесса, который приносит компании наибольшие потери, затем определите сроки его зависимостей.
| Компонент | До него нужно | Цель примера | Приёмка |
|---|---|---|---|
| Сеть и DNS | Доступ к площадке и реквизитам | До 60 минут | Исполнитель достигает копий и нужных адресов |
| База CRM | Сеть и подходящий сервер | RPO 60 минут; до 120 минут | Контрольные записи читаются |
| Приложение CRM | База, файлы и конфигурация | Рабочий результат до 240 минут | Менеджер открывает заказ и вложение |
| Общие файлы | Хранилище и права | RPO 240 минут; до 360 минут | Открывается контрольный документ |
| Чат и вторичные сервисы | Основная связь уже организована | По отдельной договорённости | Пользователь вошёл и отправил сообщение |
Заполните план до аварии #
JSON ниже — заполняемый шаблон, а не программа восстановления. В нём перечислены сервисы, зависимости, сроки и проверка результата. Поле depends_on указывает, что нужно запустить раньше; его значения должны ссылаться на существующие сервисы и не образовывать замкнутую цепочку.
Значения rto_minutes отсчитываются от начала выбранной аварии, поэтому их не нужно складывать. Поля раздела exercise заполните после пробного восстановления: начало, окончание, измеренные минуты и оставшиеся проблемы. До проверки сохраните пустые значения времени, чтобы не смешивать требования с измерениями.
Ресурсы и контакты. Добавьте адреса копий, версии приложений, порядок получения нового сервера, исполнителя и владельцев проверки результата.
Доступ. В плане оставьте ссылку на закрытое хранилище секретов. Проверьте, что запасной специалист сможет открыть его при недоступности основного сервера.
Комплект данных. Для виртуальной машины укажите сеть, диски и выбранную копию. Для приложения перечислите базу, файлы, конфигурацию и дополнительные модули в совместимых версиях.
Укажите условие отдельного запуска восстановленной машины. Она не должна случайно принять рабочие изменения одновременно с исходным сервером. Чем точнее описаны адреса, доступы и состав копии до аварии, тем меньше времени исполнитель потеряет на поиск.
{
"scenario": "loss-of-primary-host",
"owner": "руководитель компании",
"executor": "дежурный администратор",
"replacement_host": "заполнить адрес и порядок получения",
"secrets_location": "ссылка на закрытое хранилище",
"services": [
{"id":"network","depends_on":[],"rpo_minutes":0,"rto_minutes":60,"acceptance":"доступны DNS, маршруты и хранилище копий"},
{"id":"database","depends_on":["network"],"rpo_minutes":60,"rto_minutes":120,"acceptance":"выбрана согласованная копия; контрольные записи читаются"},
{"id":"crm","depends_on":["database"],"rpo_minutes":60,"rto_minutes":240,"acceptance":"сотрудник вошёл, открыл заказ и вложение"},
{"id":"files","depends_on":["network"],"rpo_minutes":240,"rto_minutes":360,"acceptance":"доступен контрольный документ и проверены права"}
],
"exercise": {"started_at":null,"accepted_at":null,"measured_minutes":null,"unresolved":[]}
}Восстанавливайте по зависимостям #
Порядок при потере основного сервера
- Назначьте координатора, объявите проблему и запишите начало. Включите согласованный временный порядок работы.
- Проверьте независимую копию, ключи и подходящую площадку. Выберите согласованный комплект данных с допустимой потерей изменений.
- Подготовьте сеть, DNS и хранилище. Запускайте восстановленные машины отдельно от рабочей сети.
- Восстановите базу, настройки и файлы в совместимых версиях. Для виртуальной машины используйте предусмотренный Proxmox способ.
- Запустите приложения по зависимостям. Выполните техническую проверку и обычные действия сотрудников.
- После подтверждения переключите рабочие адреса. Согласуйте завершение временного режима и перенос записанных во время простоя заказов.
Proxmox VE позволяет восстанавливать виртуальные машины и контейнеры из архивов, в том числе с PBS. Проверка данных PBS — verify — помогает обнаружить повреждения. Она не проверяет вход в CRM, работу подключения к другому сервису или открытие документа.
restic возвращает выбранное сохранённое состояние в целевую папку. Для учебной проверки используйте отдельное пустое место. Восстановление файлов поверх работающего приложения может смешать старые и новые данные; для рабочего переключения нужен согласованный порядок остановки или переноса.
Проверьте работу перед переключением #
Сначала администратор проверяет журналы и зависимости, затем менеджер выполняет обычную задачу: входит, открывает контрольный заказ и вложение, создаёт учебную запись в выбранном месте. Владелец процесса подтверждает, что компания снова может работать, а не только видеть страницу входа.
Рабочие данные. Проверьте известные записи, файлы и права обычного сотрудника. Сравните дату копии с началом аварии и определите недостающие изменения.
Связанные действия. Проверьте фоновые задания и отправку по безопасному учебному каналу. Временные заказы переносите из отдельного журнала с контролем повторов.
Один рабочий экземпляр. Не возвращайте исходный сервер в сеть автоматически. Координатор должен знать, какая система теперь принимает рабочие изменения и когда переключены адреса.
Для каждого компонента запишите исполнителя, время готовности и незакрытые вопросы. Целевой срок заканчивается рабочим результатом, а не завершением загрузки архива. Если срок превышен, укажите конкретную причину: оборудование, передача копии, несовместимая версия или отсутствующий доступ.
Проверяйте и обновляйте план #
Проводите пробное восстановление с согласованной частотой и после существенных изменений. Выберите один случай, например потерю хоста, и копию, доступную запасному исполнителю. Сохраните время этапов, ручные действия и результаты проверки сотрудниками — это покажет реальные задержки.
На учебной площадке отключите отправку реальных писем и событий. Восстановленное приложение должно оставаться отдельно от клиентской работы. После проверки устраните главную причину задержки и обновите порядок, чтобы следующее восстановление не повторило ту же проблему.
Новая база, перенос файлов, смена подрядчика или рост объёма меняют план даже при прежних названиях сервисов. Проверяйте версии, порядок запуска, историю копий и аварийные контакты. План готов к использованию, когда другой специалист может выполнить его без поиска скрытых зависимостей.
Когда план подтверждён проверкой
- Записаны начало, завершение этапов и время возвращения рабочих действий.
- База, файлы и настройки совместимы; сотрудник проверил заказ, вложение и свои права.
- Определена фактическая потеря данных и порядок переноса временных записей.
- Сроки и потеря данных соответствуют требованиям либо пересмотрены с руководителем; задержки имеют задачи по исправлению.