Холодный, тёплый и горячий резерв: три сметы на одну задачу

MAATRIX

Когда на ремонт квартиры просят три сметы у разных подрядчиков, никто не удивляется, что цифры отличаются в разы — просто один предлагает косметику, а другой капитальный ремонт с заменой всего. С резервированием инфраструктуры та же история: задача формально одна — «пережить аварию основного сервера без катастрофы», но за холодный, тёплый и горячий резерв вы получаете три принципиально разных счёта, потому что покупаете не «надёжность вообще», а конкретное время восстановления. Разберём, из чего складывается каждая из трёх смет, за что именно вы платите в каждой и как выбрать смету под свой бизнес, а не под общее ощущение «надо бы понадёжнее».

Почему это три сметы, а не три версии одной цены

Ошибка, с которой обычно начинается разговор о резервировании — попытка сравнить холодный, тёплый и горячий резерв как «дешёвый, средний и дорогой вариант одного и того же». На деле это не одна смета с разной степенью округления, а три разных набора статей расходов, потому что физически вы покупаете разное:

• в холодной смете основная статья — хранение (место под бэкапы и образы, которые почти всегда лежат мёртвым грузом);
• в тёплой смете основная статья — постоянно работающий сервер плюс канал для регулярной синхронизации;
• в горячей смете основная статья — дублирующая инфраструктура целиком: второй сервер, который либо активно участвует в обслуживании трафика, либо простаивает в горячей готовности, плюс механизм автоматического переключения.

Дальше при равном уровне неопределённости (провайдер, конфигурация, объём данных не фиксированы) сравнивать три сметы имеет смысл не по итоговой цифре в рублях — она у каждого проекта своя и зависит от тарифов конкретного провайдера, — а по структуре расходов и по тому, какое время восстановления (RTO) и какую допустимую потерю данных (RPO) вы получаете за эти деньги. Дальше разберём каждую смету по отдельности, а в конце — как сопоставить их со стоимостью простоя, который резерв должен предотвратить.

Если нужен более широкий контекст — от одного сервера без резерва до полноценного кластера с автоматическим failover, — мы уже разбирали стоимость отказоустойчивости по уровням. Здесь фокус только на трёх режимах резервного сервера и на том, как именно расписывается расходная часть каждого.

Смета №1: холодный резерв

Холодный резерв (cold standby) — самая короткая по числу строк смета, потому что большую часть времени вы не платите за вычислительные мощности вообще, только за хранение.

Что реально входит в эту смету:

• Хранение бэкапов и образов конфигурации — объектное хранилище или диск на отдельном сервере, куда регулярно складываются дампы БД и снапшоты файловой системы. Это единственная статья, которая работает постоянно.
• Время на подготовку сценария восстановления — Ansible-плейбук, Docker Compose файл, скрипт разворачивания с нуля. Формально это не строка в счёте от провайдера, но это реальные трудозатраты, и без них холодный резерв на бумаге не превращается в холодный резерв на практике за разумное время.
• Резервируемый, но не оплачиваемый заранее тариф — вы заранее знаете, какую конфигурацию арендуете при аварии, но платите за неё только в момент, когда она реально понадобилась (если провайдер это позволяет), либо держите минимальный тариф, который разворачивается до нужной мощности по требованию.

Пример структуры простого скрипта резервного копирования, который ложится в основу этой сметы:

#!/bin/bash
# /opt/scripts/backup-nightly.sh
DATE=$(date +%Y-%m-%d)
BACKUP_DIR=/mnt/cold-storage
pg_dump -U app_user -Fc appdb > "$BACKUP_DIR/appdb_$DATE.dump"
tar czf "$BACKUP_DIR/app-files_$DATE.tar.gz" /var/www/app
# грузим во внешнее хранилище, на сервере не держим больше 3 копий
aws s3 sync "$BACKUP_DIR" s3://cold-backups-bucket/ --delete
find "$BACKUP_DIR" -mtime +3 -delete

Что не входит в эту смету — постоянно работающий второй сервер и репликация в реальном времени. Именно поэтому итоговая цифра здесь минимальна по сравнению с двумя другими сметами: вы платите практически только за место под бэкапы, которое стоит на порядок дешевле полноценного сервера.

Цена этой экономии — время. RTO холодного резерва измеряется часами: нужно поднять новую машину, накатить конфигурацию, восстановить данные из последней копии, переключить DNS или IP. RPO — интервалом между бэкапами, то есть от нескольких часов до суток, в зависимости от частоты дампов. Это рабочая смета для сайтов-визиток, внутренних инструментов, тестовых окружений — везде, где простой в несколько часов не превращается в прямые убытки.

Смета №2: тёплый резерв

Тёплый резерв (warm standby) — смета, в которой появляется постоянная, регулярная статья расходов: второй сервер работает непрерывно, даже если ни разу не примет боевой трафик.

Из чего складывается эта смета:

• Полная аренда второго сервера — тарифная строка, идентичная по сути первому серверу (может быть чуть скромнее по мощности, если резерв не обязан выдерживать пиковую нагрузку сразу, а только дотянуть до апгрейда после переключения).
• Трафик и нагрузка на синхронизацию — потоковая репликация БД или регулярный rsync создают постоянный фоновый поток данных между серверами, который на некоторых тарифах учитывается отдельно.
• Мониторинг лага репликации — без отдельного алерта на отставание реплики есть риск переключиться на резерв, который на самом деле не синхронизирован уже несколько часов; это либо строка в существующем мониторинге, либо отдельная его настройка.
• Время администратора на переключение — при аварии кто-то должен вручную или полуавтоматически остановить репликацию, промоутнуть реплику в мастер, переключить DNS/балансировщик. Это не постоянная статья расходов, но её нужно учитывать как трудозатраты в момент инцидента.

Настройка потоковой репликации PostgreSQL, которая обычно лежит в основе этой сметы:

# на основном сервере, postgresql.conf
wal_level = replica
max_wal_senders = 3
wal_keep_size = 1GB

# на резервном сервере — разворачивание из базового бэкапа мастера
pg_basebackup -h primary_ip -D /var/lib/postgresql/16/main -U replicator -P -R

По деньгам эта смета заметно тяжелее холодной — вы фактически оплачиваете второй сервер целиком, а не только место под хранение, просто эта машина не обслуживает трафик до момента аварии. Зато RTO сокращается с часов до минут: сервер уже развёрнут, данные уже почти актуальны, переключение — это смена конфигурации, а не разворачивание с нуля. RPO — минуты, то есть объём потенциально потерянных данных ограничен задержкой репликации, а не интервалом между ночными бэкапами.

Это типичная смета для интернет-магазинов вне пикового сезона, для SaaS с платящими, но не безлимитно требовательными клиентами, для внутренних систем, от которых зависит работа всей команды в рабочие часы.

Смета №3: горячий резерв

Горячий резерв (hot standby) — самая насыщенная строками смета, потому что здесь резерв перестаёт быть «на всякий случай» и становится частью постоянно работающей продакшн-инфраструктуры.

Основные статьи расходов:

• Второй сервер в режиме полной готовности — конфигурация, как правило, сопоставимая с основным сервером, потому что при active-active схеме он реально обслуживает часть трафика, а при active-passive должен быть готов принять его целиком без деградации.
• Балансировщик или механизм автоматического обнаружения сбоя — HAProxy/nginx с health-check, либо связка вроде keepalived с VRRP для виртуального IP, которая переключает трафик без участия человека.
• Синхронная или полусинхронная репликация — гарантирует, что подтверждённая запись уже попала на резервный узел, но платит за это задержкой на каждую транзакцию: чем строже гарантия сохранности данных, тем выше цена по производительности записи. Это скрытая, но реальная статья расходов — не в деньгах напрямую, а в пропускной способности, которую приходится закладывать с запасом.
• Инженерное время на поддержание готовности — регулярное тестирование failover, разбор ложных срабатываний, контроль за тем, чтобы split-brain (оба узла одновременно считают себя главными) не случился на проде. Это постоянная, а не разовая нагрузка на команду.

Пример конфигурации VRRP для автоматического переключения виртуального IP при active-passive схеме:

# /etc/keepalived/keepalived.conf на основном сервере
vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 150
    virtual_ipaddress {
        10.0.0.100
    }
}

На резервном сервере — та же конфигурация с state BACKUP и меньшим priority; если основной перестаёт отвечать на проверки, виртуальный IP автоматически уходит на резервный без участия администратора.

Эта смета самая дорогая из трёх — по сути, вы содержите два полноценных сервера постоянно, плюс инфраструктуру для синхронизации и переключения между ними, плюс регулярное инженерное время на проверку, что всё это реально сработает в момент аварии. Взамен RTO падает до секунд, а RPO — близко к нулю при синхронной репликации. Такая смета оправдана там, где простой считается не часами и не минутами, а прямыми деньгами за каждую секунду: платёжные сервисы, крупный интернет-магазин в высокий сезон, API с жёстким SLA перед партнёрами.

Сравнение трёх смет по структуре расходов

Важная оговорка: конкретные множители стоимости между сметами зависят от провайдера, тарифов и объёма данных настолько сильно, что любое единое число здесь было бы фиктивным. Ориентируйтесь не на «во сколько раз дороже», а на структуру: холодная смета — это в основном хранение, тёплая — постоянная аренда второй машины, горячая — вторая машина плюс всё необходимое для мгновенного переключения и постоянная эксплуатационная нагрузка на команду.

Мы отдельно и подробнее разбирали техническую сторону всех трёх режимов — что именно настраивается на уровне ОС и БД для каждого — в статье про холодный, тёплый и горячий режим резервного сервера; там больше конкретики по конфигурации, здесь — по логике выбора сметы. Про то, как формализовать процесс восстановления в документ, а не держать в голове, — в материале про disaster recovery plan для малого бизнеса.

Как понять, какая смета оправдана: считаем от цены простоя

Правильный вопрос не «какой резерв надёжнее», а «сколько стоит час (или минута) простоя моего сервиса, и сколько стоит содержание резерва, который эту минуту сокращает». Смета на резервирование — это регулярный, предсказуемый расход. Простой без резерва — редкий, но потенциально крупный расход, который к тому же непредсказуем по времени наступления.

Логика сравнения простая, хотя многие её пропускают и выбирают режим «на глаз»:

1. Посчитайте ориентировочную стоимость часа простоя вашего сервиса — упущенная выручка, отток пользователей, штрафы по SLA, если они прописаны в договоре с клиентами. Методику такого расчёта с конкретными формулами мы разбирали в статье про стоимость минуты простоя магазина.
2. Оцените реалистичную частоту аварий, требующих полного восстановления, — не «а вдруг завтра», а на основе истории собственного сервиса и опыта similar-проектов: для большинства некрупных проектов это редкое событие, раз в год или реже.
3. Сравните: если разница между сметой на следующий уровень резерва и текущей сметой за год меньше, чем ожидаемые потери от одной серьёзной аварии за тот же период, — переход оправдан. Если больше — вы платите за спокойствие, которое статистически не окупается, и это тоже нормальный осознанный выбор, если бюджет позволяет.

Отдельный практический момент: смету можно менять сезонно. Интернет-магазин может держать тёплый резерв большую часть года и переводить его в горячий режим на период высокого сезона, когда цена минуты простоя резко растёт, а после пикового периода — снова понижать режим и возвращаться к более дешёвой смете. Это не требует пересматривать всю архитектуру — только временно нарастить готовность второго сервера и мониторинг.

И ещё один момент, который часто упускают при сравнении смет: ни одна из трёх не защищает от логической ошибки в данных саму по себе. Случайный DELETE без WHERE или битый деплой реплицируются на резервный сервер точно так же, как на основной, вне зависимости от режима — холодного, тёплого или горячего. От этого класса аварий защищают версионируемые бэкапы с историей, а не скорость переключения, поэтому даже при горячем резерве отдельная строка на бэкапы с ретенцией в смете должна остаться.

Частые вопросы