Резервный сервер (hot standby) — стоит ли для игрового комьюнити

MAATRIX GAMES

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

Что такое hot standby и чем он отличается от бэкапа

Бэкап — это снимок состояния, который лежит и ждёт, пока его развернут. Restore занимает время: скачать архив, распаковать, поднять процесс, дождаться загрузки мира. Для Minecraft-сервера на паре гигабайт мира это минуты, для сервера с большим миром или тяжёлой RP-экономикой (FiveM/ESX, QBCore) — уже 10-20 минут, если бэкап тянется из S3-совместимого хранилища.

Hot standby — второй сервер, который уже запущен, уже держит актуальную (или почти актуальную) копию данных и готов принять трафик за секунды-минуты. Вместо «поднять из архива» вы просто переключаете DNS, IP или балансировщик на уже работающую машину.

Есть промежуточный вариант — warm standby: сервер выключен или в спящем режиме, данные синхронизируются периодически (раз в 5-15 минут), а перед переключением его нужно быстро запустить. Дешевле hot standby, но переключение занимает не секунды, а пару минут — для большинства комьюнити это разумный компромисс между стоимостью и долгим восстановлением из холодного бэкапа.

Если у вас пока нет даже регулярных автобэкапов на расписании — начните с них, это база, без которой обсуждать standby бессмысленно: автобэкапы игрового сервера по расписанию и offsite-копирование в облако через rclone.

Что нужно синхронизировать между основным и резервным сервером

Тут главная сложность hot standby: у игрового сервера состояние размазано по нескольким слоям, и все их нужно тащить в резерв синхронно:

• Мир/сохранение — файлы региона мира (Minecraft: папка world/region), файлы карты и сохранений (Rust: *.map, *.sav), состояние кластера (ARK: файлы кластера в общей директории).
• Данные игроков — инвентари, статистика, экономика (для RP-серверов это обычно строки в MySQL/MariaDB: qbcore, es_extended и подобные схемы).
• Конфиги и whitelist — server.properties, whitelist.json, ops.json, конфиги плагинов/модов, права (LuckPerms и аналоги).
• База данных, если сервер её использует — RP-фреймворки (ESX, QBCore) и часть модов хранят экономику, банды, недвижимость в MySQL. Это самая критичная часть для синхронизации: расхождение в БД между основным и резервным сервером ломает экономику сильнее, чем расхождение в файле мира.

Практические инструменты синхронизации:

# Синхронизация файлов мира каждые N минут (простой вариант, cron)
rsync -az --delete /home/mc/world/ standby-host:/home/mc/world/

# Непрерывная синхронизация файлов через lsyncd (реагирует на изменения, не ждёт cron)
# /etc/lsyncd/lsyncd.conf.lua
sync {
    default.rsync,
    source = "/home/mc/world",
    target = "standby-host:/home/mc/world",
    delay = 15
}

Для MySQL/MariaDB синхронизация между основным и резервным — это уже репликация на уровне СУБД, а не rsync файлов:

# На главном сервере (my.cnf)
[mysqld]
server-id = 1
log_bin = /var/log/mysql/mysql-bin.log
binlog_do_db = qbcore

# На резервном сервере
[mysqld]
server-id = 2
relay-log = /var/log/mysql/mysql-relay-bin.log

Дальше CHANGE MASTER TO на резерве, указывающий на главный сервер как на источник репликации. Это стандартная MySQL master-slave репликация, но настраивать её нужно осторожно: тестируйте на копии базы перед тем как трогать боевую.

Важный нюанс: rsync и репликация с лагом в 15-30 секунд — норма для warm standby, но означает, что при падении вы теряете последние секунды-минуты прогресса игроков. Hot standby не гарантия нулевой потери данных, если только вы не настроили синхронную репликацию, а она заметно сложнее и требовательнее к сети между серверами.

Как обнаружить падение и переключиться

Мало иметь готовый резерв — нужен механизм, который поймёт, что основной упал, и переключит трафик. Три уровня, от простого к сложному:

1. Health check + ручное переключение. Простой скрипт раз в минуту дёргает игровой порт (или Query API) и шлёт алерт в Discord/Telegram, если сервер не отвечает — дальше вы вручную меняете DNS-запись или IP. Дёшево, но требует, чтобы кто-то был на связи 24/7. Подробнее про сам мониторинг: мониторинг uptime игрового сервера: инструменты.

2. Floating IP + keepalived. Если хостер поддерживает floating/virtual IP (не все VPS-провайдеры это дают, у выделенных серверов чаще есть), настройте keepalived с протоколом VRRP: серверы постоянно проверяют друг друга, и при падении основного резервный сам перенимает IP-адрес за секунды, без ручных действий.

# /etc/keepalived/keepalived.conf на основном сервере
vrrp_script chk_game {
    script "/usr/local/bin/check_game_port.sh"
    interval 5
    weight -20
}

vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 100
    virtual_ipaddress {
        203.0.113.10/24
    }
    track_script {
        chk_game
    }
}

На резервном сервере то же самое, но state BACKUP и priority 90. Плюс — игроки подключаются по одному и тому же IP, ничего менять на их стороне не нужно. Минус — требует, чтобы оба сервера были в одной L2-сети или хостер поддерживал floating IP поверх разных машин, что не всегда так для распределённых по регионам серверов.

3. DNS-переключение. Если у вас настроен свой домен с SRV/A-записью, можно менять A-запись на IP резервного сервера. Минус — DNS TTL: даже при TTL в 60 секунд часть клиентов кэширует DNS дольше, и переключение не мгновенное. Плюс — работает с любым хостером, без требования единой сети.

Отдельная головная боль: игроки, у которых сервер добавлен в избранное по IP, а не по домену — при смене IP они физически не найдут сервер, пока вы не скинете новый адрес в Discord.

Hot standby vs просто быстрый restore — что выбрать

Ключевой момент таблицы — стоимость. Hot standby это второй счёт за сервер каждый месяц, работающий вхолостую в 95%+ времени. Для сервера на грани окупаемости через донат это может съедать всю маржу.

Когда hot standby реально оправдан, а когда это избыточно

Оправдан, если совпадает несколько из этого:

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

Избыточен, если:

• Комьюнити небольшое или среднее (до пары десятков одновременных игроков), и час-два даунтайма раз в месяц — неприятность, с которой лояльное комьюнити мирится.
• Сервер не платный или донат минимальный — второй тариф просто не окупается.
• Падения крайне редки (адекватный SLA у хостера, вменяемая нагрузка) — вероятность, что standby вообще пригодится за год, ниже, чем время на его настройку и поддержку.
• У вас нет ресурса регулярно проверять, что резерв в рабочем состоянии — непроверенный standby хуже, чем его отсутствие: создаёт ложное чувство защищённости.

Для большинства администраторов золотая середина — не hot standby, а быстрый и надёжный restore: offsite-бэкапы каждые 15-30 минут плюс отработанный скрипт разворачивания за 5-10 минут на резервный тариф, включаемый только когда реально нужен. Это закрывает 90% практических сценариев падения гораздо дешевле полноценного hot standby.

Практическая реализация: минимальный warm standby на два сервера

Если после всего вышесказанного вы решили, что вам это нужно — вот скелет разумного warm standby без избыточной сложности:

1. Синхронизация данных. lsyncd или cron-rsync каждые 5 минут для файлов мира; для баз RP-фреймворков — периодический дамп и восстановление на резерв, а не полноценная репликация (проще в поддержке небольшой команде):

# cron на основном сервере, каждые 10 минут
*/10 * * * * mysqldump -u backup_user -p'PASSWORD' qbcore | ssh standby-host "mysql -u backup_user -p'PASSWORD' qbcore"

1. Health check с алертом, а не автопереключением — для warm standby ручное решение обычно безопаснее автоматики: ложное срабатывание (сеть моргнула на 10 секунд) может само породить рассинхрон, если оба сервера внезапно окажутся «живы» одновременно (split-brain).

#!/bin/bash
# check_main.sh — запускать по cron раз в минуту
if ! nc -z -w5 203.0.113.10 25565; then
    curl -s -X POST "https://discord.com/api/webhooks/.../..." \
        -H "Content-Type: application/json" \
        -d '{"content":"Основной сервер не отвечает на порт 25565! Проверить и решить вопрос о переключении на резерв."}'
fi

1. Понятный runbook переключения — заранее написанная короткая инструкция, что именно делать: запустить процесс на резерве, поменять DNS/IP, кинуть сообщение в Discord с новым адресом. Когда сервер реально упал и нервы на пределе, импровизировать — плохая идея, лучше заранее протестированный чек-лист.

1. Регулярная проверка резерва — раз в месяц реально переключитесь на резервный сервер на 10-15 минут в спокойное время (например, во время планового рестарта) и убедитесь, что всё работает: игроки заходят, инвентари на месте, плагины грузятся. Непроверенный standby с высокой вероятностью подведёт именно тогда, когда понадобится больше всего.

Если решаете вопрос глобальнее — например, переносите комьюнити на другого хостера целиком, а не держите резерв, — процесс миграции лучше разбирать отдельно: миграция сервера к другому хостеру без потери мира.

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