Зачем VDS нужен Disaster Recovery (DR), даже если «у нас всё просто»
Disaster Recovery для VDS — это не «ещё один бэкап», а заранее спроектированный и проверенный способ восстановить сервис после серьёзного инцидента: отказа узла/диска, потери доступности площадки, разрушения данных, компрометации, человеческой ошибки или неудачного релиза.
Типичная проблема: резервные копии вроде бы есть, но они не проверяются, хранятся рядом с сервером, а в момент аварии выясняется, что восстановление займёт сутки, хотя бизнес ожидал «час». DR-план нужен, чтобы ожидания и ответственность были формализованы, а восстановление было повторяемым процессом, а не разовой импровизацией.
Важно: DR — это не только про инфраструктуру. Это ещё и про людей: кто принимает решение о переключении, где лежит инструкция, какие доступы нужны в 03:00, как и кому вы сообщаете статус.
Базовые определения: RTO, RPO и почему их нельзя угадывать
Если вы не измеряете цели восстановления, DR превращается в декларацию. Два ключевых параметра:
RTO (Recovery Time Objective) — сколько времени сервис может быть недоступен. Например, RTO 30 минут означает, что от момента инцидента до восстановления работоспособности должно пройти не больше 30 минут.
RPO (Recovery Point Objective) — сколько данных вы можете потерять «по времени». Например, RPO 5 минут означает, что в худшем случае вы теряете до 5 минут изменений.
RTO/RPO задаются не «по желанию админа», а по бизнес-процессам: что ломается при простое, сколько стоит час недоступности, сколько стоит потеря транзакций за 5–60 минут, есть ли ручные обходные сценарии.
Практика: сначала фиксируйте RTO/RPO на уровне сервисов (сайт, API, БД, очередь, админка), а уже затем выбирайте архитектуру DR под эти цифры.
Чтобы не спорить «на глаз», полезно оформить простую таблицу зависимостей и критического пути (что должно восстановиться раньше чего). Такой документ потом становится основой для runbook и DR-учений.
Классы DR-стратегий для VDS: от бэкапа до актив-актива
Условно DR на VDS можно разложить по зрелости и стоимости. Чем ниже целевые RTO/RPO, тем дороже инфраструктура и сложнее эксплуатация.
1) Backup-only: «восстановимся из бэкапа»
Самый частый сценарий: есть резервные копии, но нет подготовленного «второго места», куда быстро разворачивать. RTO обычно измеряется часами, RPO зависит от частоты бэкапов.
Подходит, если у вас допустимы простой на несколько часов и потеря данных в пределах, например, 1–24 часов (в зависимости от графика резервного копирования).
2) Pilot Light: «держим минимальную инфраструктуру»
В резервной зоне заранее подготовлены базовые образы/плейбуки, конфиги, возможно, пустая БД или реплика без постоянной нагрузки. При аварии вы быстро поднимаете полноценный стек. RTO — десятки минут или пара часов, RPO — от минут до часов.
3) Warm Standby: «тёплый резерв»
Есть постоянно работающий резервный VDS (или несколько), на нём развёрнуты сервисы и регулярно синхронизируются данные. Переключение быстрее: RTO обычно минуты-десятки минут. RPO может быть небольшим, если настроена репликация.
4) Hot Standby / Active-Active: «почти без простоя»
Параллельно работают две площадки, трафик балансируется, данные реплицируются максимально близко к реальному времени. RTO — минуты или меньше, RPO — близко к нулю (но не «ноль» по умолчанию, особенно в распределённых сценариях).
Важно: active-active — это не про «круто», а про дисциплину. Сложнее схема — больше вариантов получить логическую порчу данных, конфликты записи и тяжёлые для расследования инциденты.
Модель угроз и типовые «бедствия», которые стоит заложить
DR-план имеет смысл строить от реальных сценариев. Для VDS обычно закладывают:
Потерю узла/диска: корневая ФС не монтируется, файловая система повреждена, снапшоты битые.
Недоступность сети/провайдера/площадки: сервер жив, но недоступен извне, или «отвалился» регион.
Компрометацию: утечка ключей, внедрение бэкдора, шифровальщик, уничтожение данных.
Человеческую ошибку: удаление таблицы/директории, неверный ansible-playbook, ошибочная миграция.
Логическую порчу: приложение записало некорректные данные, баг «разнёс» мусор по репликам.
От сценариев зависят требования к бэкапам (частота, глубина истории, точки во времени), необходимость неизменяемого хранения, а также процедура incident response: когда «лечим», а когда сразу изолируем и переключаемся.
Инвентаризация: что именно восстанавливаем
«DR для сервера» часто проваливается, потому что никто не описал состав сервиса. Для VDS минимальный чек-лист объектов восстановления:
ОС и пакеты: версия ОС, установленные пакеты, источники репозиториев.
Конфигурация: Nginx/Apache, systemd unit’ы, конфиги приложения, переменные окружения.
Секреты: ключи SSH, токены, пароли, ключи шифрования, API-ключи (и порядок их ротации).
Данные: БД, загруженные файлы, очередь, кэши (понимать, что можно пересоздать).
DNS и TLS: записи, TTL, сертификаты, сценарий перевыпуска/переноса.
Наблюдаемость: логи, метрики, алерты (хотя бы чтобы видеть, что восстановление прошло успешно).
Практичный подход: оформите «паспорт сервиса» в репозитории (README), и держите рядом контакты/доступы/владельцев. В аварии память подводит, а чек-лист — нет.
Бэкапы для DR: частота, хранение, проверка, защита от порчи
Бэкап в DR отвечает за достижение RPO, но только если вы можете гарантировать, что он:
создаётся регулярно и без пропусков;
хранится вне основной площадки (иначе это не DR, а «копия рядом»);
восстанавливается в тесте (иначе это вера, а не план);
защищён от удаления/шифрования при компрометации (раздельные учётки, раздельные ключи, по возможности неизменяемое хранение).
3-2-1 как база, но с уточнениями для VDS
Классика: 3 копии, 2 разных носителя, 1 копия вне площадки. На практике для VDS это часто превращается в: локальный снапшот + удалённый бэкап + «холодная» копия (архив на долгий срок). Ключевой момент: эти копии не должны управляться одной и той же учёткой, которая может быть скомпрометирована.
Проверка восстановления: «бэкап есть» недостаточно
Минимум раз в месяц (лучше чаще) делайте тренировку: разворачивайте новый сервер, поднимайте сервис из бэкапа, проверяйте критичные ручки/страницы, сверяйте целостность БД. Это и есть «DR в реальности», а не на бумаге.
Репликация и консистентность: как не получить «быстрый failover в сломанные данные»
Если ваша цель — низкий RPO, одной резервной копии обычно мало: нужна репликация. Но репликация не заменяет бэкап: если вы удалили данные или записали некорректное значение, реплика честно повторит это же.
Синхронная vs асинхронная репликация
Синхронная помогает приблизиться к минимальному RPO, но увеличивает задержки записи и сложнее между площадками.
Асинхронная проще и чаще применима между регионами, но даёт «окно потери» (репликационный лаг), которое нужно учитывать в RPO.
Точка истины и процедура промоушена
Для БД важно определить: кто является primary, как именно происходит промоушен реплики, какие проверки вы делаете перед переключением, и как предотвращаете split-brain (когда две ноды думают, что обе primary).
Если у вас нет чёткой процедуры «кто primary» и «как мы запрещаем старому primary принимать записи», вы проектируете не DR, а генератор сложных инцидентов.
Отдельно продумайте, как вы откатываетесь назад, если переключение было ложным (например, сетевой инцидент), и что делаете с «бывшим primary», чтобы не размножить расхождения.
DNS-переключение: TTL, healthchecks и что делать, если кэш не слушается
DNS — популярный механизм failover для веб-сервисов на VDS, но он работает не так мгновенно, как ожидают. На скорость влияют TTL, кэши резолверов и поведение клиентов. Поэтому DR-план должен учитывать «DNS-инерцию».
TTL: заранее снижать или держать умеренным?
Частая рекомендация: «снизьте TTL до 60 секунд». Это помогает при плановых переключениях, но в реальности:
не все резолверы и клиенты строго соблюдают TTL;
малый TTL увеличивает нагрузку на DNS и риски при проблемах у DNS-провайдера;
слишком маленький TTL усложняет расследования: ответы быстрее «прыгают».
Практика для большинства проектов: держать TTL в диапазоне 60–300 секунд для критичных A/AAAA записей, а перед плановыми работами временно снижать TTL, если это удобно и управляемо.
Сценарии DNS-failover
Ручной: вы меняете A/AAAA на резервный IP по чек-листу.
Условно-автоматический: мониторинг сигналит, дежурный подтверждает переключение.
Автоматический: healthcheck триггерит смену записи. Подходит не всем, потому что риск ложных срабатываний часто недооценивают.
В DR-инструкции обязательно укажите: какие записи менять, где они управляются, какой ожидаемый TTL, и как проверять распространение с разных резолверов.
Если DR затрагивает домен (перенос управления DNS, смена NS, аварийные контакты регистратора), полезно заранее продумать «доменные» риски и защиту. См. также: как защитить домен от угона и ошибок управления.
Пошаговый DR-runbook: что должен уметь дежурный в 03:00
Runbook — это конкретные шаги, которые выполняются в аварии. Хороший runbook не начинается словами «проверьте логи и разберитесь». Он начинается с диагностики уровня «сервис недоступен» и ведёт к восстановлению.
Структура runbook, которая реально работает
Сигнал: какой алерт/симптом, как подтвердить инцидент из 2–3 независимых источников.
Классификация: деградация, частичная недоступность, полное падение, подозрение на компрометацию.
Решение “failover или fix”: когда чиним на месте, а когда переключаемся.
Процедура переключения: инфраструктура, БД, приложение, DNS, сертификаты, фоновые задачи.
Верификация: проверки после восстановления (снаружи и изнутри), контроль метрик/ошибок.
Коммуникация: кого уведомить, что писать пользователям, где обновлять статус.
Post-incident: сбор артефактов, таймлайн, RCA, действия по предотвращению повторения.
DR — часть incident response, просто с акцентом на восстановление доступности и данных. Если есть подозрение на компрометацию, в runbook должны быть отдельные «стоп-сигналы» (например, немедленная изоляция и ротация ключей), иначе вы рискуете восстановить атакующего вместе с сервисом.
Практический минимальный DR для типового веб-проекта на VDS
Возьмём типичный стек: веб-сервер, приложение, база данных, файловые загрузки. Цель: адекватный RTO 30–60 минут и RPO 15–60 минут без космической сложности.
Минимальный набор
Автоматизация развёртывания: IaC/плейбук, который поднимает ОС, пакеты, конфиги.
Бэкапы БД: по расписанию, с хранением вне площадки и с периодическим тестом восстановления.
Бэкапы/синхронизация загрузок: каталог uploads/хранилище файлов.
Резервный сервер: pilot light или warm standby (зависит от RTO).
DNS-план: список записей, TTL, шаги смены.
Для TLS заранее решите, как вы обеспечиваете сертификаты на резервной площадке: переносите существующий сертификат, либо выпускаете новый автоматически. Если используете wildcard и автоматизацию через DNS-01, заранее проверьте доступы к DNS и процедуру обновления: wildcard SSL и автоматизация DNS-01.
Как «приземлить» RTO/RPO в цифры: простой метод оценки
Чтобы RTO/RPO не были абстрактными, оцените критический путь восстановления по компонентам. Пример логики:
Приложение: развёртывание из автоматики — 10–20 минут.
База данных: восстановление бэкапа + прогон миграций — 15–90 минут (зависит от объёма).
DNS: распространение — 5–30 минут (иногда больше из-за кэшей).
После этого суммируете критический путь и сравниваете с целевым RTO. Если не сходится — либо улучшаете архитектуру (warm standby, реплика), либо пересматриваете ожидания и коммуникации.
В runbook удобно добавить «шаблон замера» (фактическое время по шагам), чтобы на учениях и реальных инцидентах вы собирали цифры, а не ощущения.
Периодические DR-учения: что именно проверять
DR-учения должны быть повторяемыми и измеримыми. Минимальный набор проверок:
поднимается ли новый VDS по вашему описанию (без ручной «магии»);
восстанавливается ли БД из актуальной резервной копии и проходит ли проверку целостности;
подтягиваются ли загрузки/статические файлы;
работает ли выдача/перенос TLS-сертификата по вашему процессу;
сколько времени заняли шаги (фактический RTO) и какой объём данных потеряли (фактический RPO).
Результат учений — это обновлённый runbook и список улучшений. DR — живой процесс: меняется код, зависимости, объёмы данных и команда, поэтому «один раз настроили и забыли» не работает.
Типовые ошибки при DR на VDS и как их избежать
Смешали бэкап и репликацию: репликация не спасает от логической ошибки. Нужны точки восстановления во времени и тесты восстановления.
Секреты не вынесены: в аварии сервис не поднять, потому что ключи/пароли были только на упавшем сервере.
DR не тестируется: первый «тест» происходит в проде во время реального инцидента.
Не учли DNS и кэши: запись поменяли, но часть пользователей ещё 10–30 минут ходит на старый IP.
Нет критерия “когда переключаемся”: команда час «чинит на месте», хотя быстрее было сделать failover.
Нет защиты бэкапов: при компрометации злоумышленник удаляет или шифрует и бэкапы тоже.
Итоги: минимальный DR-план, который уже приносит пользу
Начните с фиксации RTO/RPO для ключевых сервисов, опишите инвентарь (что восстанавливаем), настройте бэкапы вне площадки и регулярно проверяйте восстановление. Затем добавляйте репликацию и автоматизацию переключения ровно там, где это оправдано целями восстановления.
Самое ценное в DR для VDS — предсказуемость. Когда случится серьёзный инцидент, вы будете действовать по проверенному сценарию, а не собирать план на ходу.
