Миграция игры на новую мажорную версию без потери сервера

MAATRIX GAMES

Вышла новая мажорная версия — Minecraft 1.20 на 1.21, Rust получил очередной форс-вайп с крупным обновлением движка, ARK выкатил патч, ломающий половину модов. Игроки уже спрашивают в Discord, когда обновляемся, а ты знаешь: один неверный шаг — и полсотни часов чужого прогресса превратятся в битые чанки или сервер, который просто не стартует. Разница между патчем и мажорным апдейтом принципиальна, и подход "накатил и молимся" тут не работает. Ниже — рабочая схема миграции через тестовую копию, которой я пользуюсь сам: без простоя продакшена и с понятным путём назад, если что-то пойдёт не так.

Почему мажорное обновление рискованнее патча

Патч чаще всего чинит баги и добавляет мелкий контент, не трогая формат сохранений. Мажорная версия — другое дело: она может менять формат чанков и структуру сохранения мира, переписывать ID блоков и предметов, ломать API, на который завязаны плагины и моды, и требовать миграции базы данных у RP-фреймворков вроде ESX или QBCore.

Ключевая проблема — необратимость. Как только мир открыт новой версией игры, он получает новый DataVersion (для Minecraft это буквально числовое поле в level.dat), и откатить его обратно на старую версию клиента или сервера штатными средствами уже нельзя. Игра либо откажется грузить "мир из будущего", либо начнёт вести себя непредсказуемо — сносить блоки, которых не знает, ломать сущности с новыми полями. Поэтому тестировать нужно строго на копии, а не на живом мире "на всякий случай сделаю бэкап и обновлюсь прямо тут".

Вторая головная боль — экосистема модов и плагинов почти всегда отстаёт от ядра игры. Paper обычно догоняет ванильный Minecraft за 1-3 дня, но конкретные плагины на Bukkit/Spigot API могут не обновляться неделями. У модовых сборок на Forge и Fabric разброс ещё больше: тяжёлые модпаки с полусотней зависимостей иногда ждут совместимой версии месяц и дольше. Обновить ядро раньше экосистемы вокруг него — гарантированный способ остаться либо без части контента, либо вовсе без рабочего сервера.

Шаг 1: разворачиваем тестовую копию сервера

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

Минимальный набор для копии:

# создаём отдельную директорию под тестовый инстанс
mkdir -p /home/user/mc-test
cd /home/user/mc-test

# копируем мир и конфиги с продакшена (сервер продакшена можно не останавливать —
# главное скопировать консистентный снапшот, а не мир "на лету" под активной записью)
rsync -a --exclude 'logs' --exclude 'crash-reports' /home/user/mc-prod/world ./
rsync -a /home/user/mc-prod/server.properties /home/user/mc-prod/plugins ./

Если хостинг у вас на панели вроде Pterodactyl или аналога — проще всего клонировать сервер целиком через встроенную функцию клонирования, либо выгрузить архив мира через файловый менеджер и залить в новый тестовый инстанс. У MAATRIX GAMES для этого достаточно поднять второй сервер той же игры — он изолирован от продакшена по умолчанию, порт и IP не пересекаются с боевым.

Дальше в тестовой копии:

1. Скачиваем сборку нужной новой версии (новый server.jar для Paper/Vanilla, актуальный установщик Forge/Fabric, обновлённый бинарник через SteamCMD для игр на Source/Unity).
2. Меняем порт в конфиге (server.properties → server-port=25566 вместо продовых 25565), чтобы не было конфликта, если копия крутится на том же хосте.
3. Запускаем и смотрим лог загрузки мира построчно — любые ERROR/WARN про конвертацию чанков, отсутствующие блоки или сущности нужно фиксировать сразу, не дожидаясь падения сервера.

tail -f logs/latest.log

Про то, как настроить регулярные автобэкапы, чтобы у вас всегда был свежий консистентный снапшот для такого клонирования — отдельная статья про автобэкапы игрового сервера.

Шаг 2: проверяем совместимость модов и плагинов

Это самый трудозатратный этап, и торопиться здесь нельзя. На тестовой копии проходим по каждому плагину/моду из вашего текущего набора и проверяем три вещи:

• Есть ли вообще сборка под новую версию. Для плагинов Bukkit/Spigot/Paper смотрим страницу проекта на SpigotMC или Hangar — большинство авторов явно пишут поддерживаемые версии в шапке. Для модов Forge/Fabric — Modrinth или CurseForge, файл релиза обычно помечен тегом версии игры и модлоадера.
• Совпадает ли api-version в plugin.yml. Начиная с современных версий Paper плагин со старым api-version может не загрузиться вовсе или загрузиться с предупреждениями о недоступных методах API. Не факт, что автор перевыпустил файл — иногда достаточно распаковать jar и подправить вручную, если знаете, что делаете, но это временный костыль, а не решение.
• Нет ли конфликтов между модами по требуемой версии модлоадера. У Forge и Fabric каждая версия ядра тянет за собой минимальную версию Minecraft Forge/Fabric Loader — если один мод из сборки требует Forge 51+, а другой ещё сидит на 47, сервер упадёт при старте с понятной ошибкой несовместимости в логе.

Загружаем сервер на тестовой копии с полным набором модов/плагинов и смотрим на консоль:

[Server thread/ERROR]: Could not load 'plugins/SomePlugin.jar' in folder 'plugins'
[Server thread/WARN]: Plugin SomePlugin does not implement getFile

Такие строки — сигнал, что конкретный компонент к миграции не готов. Дальше решаете сами: искать форк с апдейтом, временно отключить плагин/мод, отложить обновление сервера до выхода совместимой сборки. Если сервер сильно завязан на модах (крупный модпак, RP-фреймворк с кастомными скриптами) — иногда разумнее подождать 1-2 недели, пока догонят самые критичные зависимости, чем переезжать день в день с релизом игры. Про то, как автоматизировать саму проверку и подтягивание новых версий модов, писали в статье про автообновление модов на сервере.

Отдельно — для RP-серверов на FiveM/alt:V/SA-MP с фреймворками вроде ESX или QBCore: обновление ядра фреймворка часто требует миграции структуры базы данных. Тестовая копия обязана включать и копию БД, а не только файлы мира — накатывать миграцию SQL сразу на продовую базу без проверки на дубликате не стоит.

Шаг 3: тестовый прогон — что проверить перед переключением

После того как сервер на тестовой копии стартовал без ошибок в логе, это ещё не значит, что можно переключать продакшен. Прогоните базовый чек-лист:

• Загрузка всех зон мира. Пройдите пешком или телепортом по ключевым точкам — центральные базы игроков, шахты, фермы. Дальние непрогруженные чанки могут конвертироваться только при первом заходе, и именно там чаще всего всплывают проблемы.
• Кастомные предметы и блоки. Если на сервере были датапаки, кастомные крафты или предметы от модов — проверьте, что они по-прежнему существуют и не превратились в баг-объекты (для Minecraft это иногда видно как блок с текстурой "вопросительный знак" или отсутствующим ID).
• Права и группы. Плагины permissions (LuckPerms и аналоги) иногда сбрасывают или конфликтуют группы при смене версии — проверьте, что админские права и группы игроков не потерялись.
• Производительность. Даже без модов новая версия ядра может по-другому нагружать CPU. Дайте серверу повисеть 15-20 минут с тестовыми клиентами и посмотрите TPS/тикрейт через встроенные команды (/tps для Paper-серверов или консоль для других движков) — не как точный бенчмарк, а как ориентир, что производительность не просела в разы.
• Сохранение и повторная загрузка. Сделайте save-all, перезапустите тестовый сервер и убедитесь, что мир грузится второй раз без ошибок — иногда проблема проявляется не при первой конвертации, а при повторном чтении уже сконвертированных данных.

Если что-то из списка не проходит — фиксируем проблему, откатываем тестовую копию к чистому бэкапу (не продакшену!) и разбираемся точечно, прежде чем повторять попытку.

Шаг 4: переключаем продакшен-сервер на новую версию

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

Порядок действий:

1. Предупреждаем игроков и в назначенное время останавливаем продакшен-сервер штатно (stop в консоли, не kill процесса — это снижает риск повреждения файлов при записи).
2. Делаем финальный ручной бэкап мира и конфигов с понятным именем (pre-migration-1.21-YYYYMMDD), отдельно от автоматических снепшотов по расписанию — при откате его проще найти. Как выглядит грамотная процедура восстановления из такого бэкапа, если что-то пойдёт не так уже после переключения — в статье про восстановление сервера из бэкапа.
3. Заменяем исполняемый файл/сборку на продакшене на ту же версию, что уже прошла проверку на тестовой копии — не более новую, не менее новую, именно ту же самую, включая билд-номер плагинов и модов.
4. Запускаем продакшен, смотрим лог до момента "Done" (или аналогичного сообщения о готовности), только после этого открываем порт для игроков.
5. Первые 30-60 минут после открытия держим сервер под особым присмотром — следим за логом на предмет ошибок, которые не всплыли на тестовой копии из-за меньшего количества игроков и меньшей нагрузки на чанки.

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

План отката, если что-то пошло не так

Даже при аккуратной подготовке иногда что-то всплывает уже на продакшене — редкий edge case, специфичная постройка игрока, паттерн нагрузки, которого не было на тесте. План отката должен быть готов заранее, а не придумываться в панике:

• Держите старую версию под рукой. Не удаляйте старый server.jar/сборку модлоадера сразу после обновления — оставьте её в отдельной папке минимум на неделю-две.
• Бэкап перед миграцией — неприкосновенен, пока не убедитесь, что новая версия стабильна. Не перезаписывайте автоматические снепшоты поверх него в первые дни.
• Откат — это возврат к состоянию ДО конвертации, а не "поставить старую версию поверх нового мира". Мир, уже сохранённый новой версией, крайне не рекомендуется открывать старой — именно поэтому бэкап делается ДО запуска новой версии, а не после неудачной попытки.

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

# останавливаем сервер на новой версии
stop

# восстанавливаем мир и конфиги из бэкапа "pre-migration"
tar -xzf pre-migration-1.21-20260828.tar.gz -C /home/user/mc-prod/

# возвращаем старую сборку сервера
cp /home/user/mc-prod/backup_jars/paper-1.20.jar /home/user/mc-prod/server.jar

# запускаем на старой версии
java -jar server.jar --nogui

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

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