Обновление сервера без потери прогресса игроков

MAATRIX GAMES

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

Почему обновление вообще может всё сломать

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

Второй по частоте случай — разработчики сторонних инструментов (Paper, Fabric, Oxide/uMod, BepInEx) не успевают за мажорным патчем игры на день-два, а иногда и на неделю. Если ты обновишь ядро игры раньше, чем выйдет совместимая сборка модлоадера, сервер либо не запустится, либо запустится без части модов — и тогда крашнется уже от несовпадения версий контента у игроков.

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

Шаг 1: бэкап мира перед любым обновлением — без исключений

Это правило без компромиссов: бэкап делается всегда, даже если патч кажется "мелким фиксом багов". Мелкие патчи иногда ломают больше, чем крупные — просто потому что их меньше тестируют.

Минимальный набор для бэкапа зависит от игры, но логика одна — копируем всё, что относится к сохранению прогресса, ДО остановки сервера или сразу после неё:

# Minecraft (Paper/Vanilla) — папка мира + конфиги
tar -czf backup_$(date +%Y%m%d_%H%M).tar.gz world world_nether world_the_end server.properties plugins/

# Rust — сохранения в server/<identity>
tar -czf backup_rust_$(date +%Y%m%d_%H%M).tar.gz server/my_server_identity/*.sav server/my_server_identity/*.map server/my_server_identity/cfg

# ARK: Survival — SavedArks
tar -czf backup_ark_$(date +%Y%m%d_%H%M).tar.gz ShooterGame/Saved/SavedArks

Важно: если сервер модифицированный (моды, плагины, кастомные карты), бэкапь и папку с ними тоже — при откате тебе нужна будет не только версия мира, но и версия модов/плагинов, которая с ней совместима.

Проверь, что бэкап реально читаемый и весит адекватно — распакованный tar -tzf backup.tar.gz | head покажет список файлов без полной распаковки. Файл на 4 КБ вместо привычных гигабайт — верный признак, что скопировалось не то (например, сервер работал и файлы мира были залочены).

Если бэкапы у тебя уже настроены по расписанию — не полагайся только на последний автоматический снепшот, сделай отдельный ручной бэкап прямо перед обновлением с понятным именем в стиле pre-update-1.21.4. В экстренной ситуации искать нужный файл среди тридцати одинаковых auto_backup_N — плохое занятие. Подробно про настройку расписания бэкапов — в статье про автобэкапы игрового сервера.

Шаг 2: предупреди игроков заранее

Даже быстрое обновление — это простой сервера, а игроки не любят, когда мир пропадает у них из-под ног посреди рейда или боя. Минимум за несколько часов (а для крупных апдейтов — за день-два) сообщи о плановых работах.

Самый простой способ — MOTD (message of the day), который игроки видят при заходе или в списке серверов:

# Minecraft, server.properties
motd=§eОбновление 31.08 в 20:00 МСК, сервер будет недоступен ~15 минут

# Rust, через RCON перед началом работ
server.description "Обновление сегодня в 20:00 МСК, ~10-15 минут простоя"

Второй канал — объявление в Discord-сообществе сервера, если он у тебя есть: там можно закрепить сообщение, упомянуть роль игроков и напомнить за час до начала. Если Discord ещё не подключен к серверу, у нас есть отдельный разбор, как настроить Discord-бота для управления сервером — через него же удобно рассылать такие анонсы автоматически.

Для survival-серверов с открытым PvP отдельно предупреди про паузу боевых действий на время работ — иначе кто-то успеет выйти из боя ровно в момент рестарта, а кто-то нет, и это гарантированно вызовет споры в чате.

Шаг 3: изучи changelog на breaking changes

Прежде чем нажимать "обновить", прочитай список изменений — официальный changelog игры и, если сервер модифицированный, страницы используемых модов/плагинов. Ищи конкретно:

• изменения формата сохранений или структуры мира (миграция чанков, новая система ID предметов);
• изменения API, от которых зависят твои плагины (Bukkit/Spigot/Paper API, Rust Oxide hooks, FiveM/RedM natives);
• удалённые или переименованные команды и конфиг-параметры — старый конфиг может просто не подхватиться;
• явные пометки "breaking change" или "incompatible with previous saves" — разработчики обычно выделяют такое отдельно, не прячут в мелком шрифте.

Если используешь модифицированную сборку (Paper + плагины, Fabric/Forge + моды, Oxide/uMod хуки), зайди на страницы каждого крупного мода/плагина и проверь, вышла ли уже версия под новый патч игры. Практика подсказывает: обновлять ядро сервера раньше, чем обновится хотя бы 80-90% используемых модов, — плохая идея. Часть комьюнити-модов может вообще не пережить переход на новую версию и остаться заброшенной — тогда придётся искать форк или задержаться на текущей версии дольше, чем хотелось.

Отдельно проверь минимальную поддерживаемую версию клиента — если разработчики подняли required-версию игры, старые клиенты у части игроков просто не смогут подключиться, пока они сами не обновятся.

Шаг 4: протестируй обновление на тестовом сервере

Если есть возможность — а на VPS/выделенном сервере поднять второй временный инстанс обычно недорого и быстро — протестируй апдейт не на боевом мире, а на копии. Схема простая:

1. Копируешь файлы мира и конфиги на тестовый сервер (тот же бэкап из шага 1 отлично подходит).
2. Обновляешь тестовый сервер ядром/движком новой версии.
3. Запускаешь, смотришь лог на ошибки при загрузке мира, проверяешь, что плагины/моды подгрузились без исключений.
4. Заходишь как игрок, проверяешь ключевые точки: спавн, ближайшие постройки, работу основных команд и плагинов.

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

Шаг 5: сам процесс обновления — порядок действий

Когда бэкап сделан, игроки предупреждены, changelog изучен, а тест (если был) прошёл без критичных ошибок — обновляем боевой сервер:

# 1. Предупреждение за 5 минут в игровом чате/RCON
rcon-cli say "Сервер уходит на обновление через 5 минут"

# 2. Корректная остановка (не kill!) — даёт серверу сохранить мир
rcon-cli stop
# или для systemd-юнита:
systemctl stop minecraft-server

# 3. Обновление через SteamCMD (для игр на Steam-движке — Rust, ARK, CS2 и т.д.)
./steamcmd.sh +force_install_dir /home/steam/rust +login anonymous +app_update 258550 validate +quit

# 4. Проверка целостности конфигов — сравнить с бэкапом на предмет
#    затёртых настроек (некоторые апдейты сбрасывают server.cfg)
diff server.cfg backup_pre_update/server.cfg

# 5. Запуск и мониторинг лога первые 5-10 минут
systemctl start minecraft-server && journalctl -u minecraft-server -f

SteamCMD здесь — тот же инструмент, что и при первой установке сервера, разница только в том, что мир и сохранения уже на месте и их важно не задеть при validate. Ключевой момент: не запускай +validate вслепую на директории с миром, если не уверен, что папка сохранений вне install_dir или явно исключена — validate проверяет и докачивает файлы игры и в норме не трогает пользовательские сейвы, но для нестандартных структур (кастомные пути, симлинки) лучше свериться с документацией конкретной игры.

Первые 5-10 минут после запуска — самое важное время: смотри лог на ошибки загрузки мира, исключения от плагинов/модов, предупреждения о несовместимых версиях данных. Если лог чистый и игроки заходят без проблем — обновление прошло штатно. Разбираться в логах и крашах подробнее — в статье про чтение логов и крash-репортов.

Шаг 6: план отката, если что-то пошло не так

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

Порядок отката:

# 1. Останавливаем сервер
systemctl stop minecraft-server

# 2. Откатываем бинарники/ядро игры на предыдущую версию
#    (для Steam-игр — конкретная сборка через -beta ветку, если доступна,
#    либо переустановка из локального бэкапа папки сервера)

# 3. Восстанавливаем мир из бэкапа, сделанного в шаге 1
rm -rf world world_nether world_the_end
tar -xzf backup_pre_update.tar.gz

# 4. Возвращаем конфиги, если апдейт их перезаписал
cp backup_pre_update/server.properties .

# 5. Запускаем и проверяем
systemctl start minecraft-server

Ключевое условие, чтобы этот шаг вообще сработал — бэкап из шага 1 должен включать не только мир, но и саму папку сервера (бинарники нужной версии) или хотя бы точную версию/build ID, которую можно переустановить заново. Если игра позволяет закрепить версию через SteamCMD (+app_update <appid> -beta <branch> или конкретный -manifest), сохрани себе эту команду до апдейта — она и станет твоим планом Б. Подробный разбор восстановления из бэкапа с реальными кейсами — в статье про восстановление сервера из бэкапа.

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

Шаг 7: чек-лист на будущее

Чтобы не собирать этот процесс заново при каждом патче, держи под рукой короткий чек-лист (буквально файл рядом с конфигами сервера):

Со временем этот процесс занимает 15-20 минут суммарно вместе с самим апдейтом — и это несопоставимо дешевле, чем восстанавливать доверие комьюнити после потерянного прогресса.

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