Миграция сервера к другому хостеру без потери мира

MAATRIX GAMES

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

Почему переезд редко проходит гладко без плана

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

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

Фаза подготовки: разворачиваем новый сервер заранее

Закажите новый сервер за несколько дней до планируемого переезда — старый в это время продолжает работать без изменений. На новом сервере нужно воспроизвести окружение один в один:

• та же версия игры и её сборка (например, Minecraft 1.21.х, а не просто "последняя версия" — при миграции мира версии должны совпадать или новая быть равна/новее старой);
• тот же загрузчик модов/API: Forge, Fabric, Paper, Oxide/uMod, BepInEx — с теми же версиями плагинов и модов, что стояли на старом сервере;
• идентичные конфиги запуска — параметры JVM для Java-игр, стартовые флаги для Source/Steam-серверов, настройки server.cfg/server.properties.

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

Список модов и плагинов удобно сверять построчно — выгрузите содержимое папки mods/ или plugins/ со старого сервера через SFTP-клиент (FileZilla, WinSCP) и сравните с тем, что установлено на новом. Расхождение хотя бы одного файла модов/плагинов между серверами — частая причина краша мира сразу после переноса ("не тот мод-лоадер съел не тот формат чанков"), поэтому на этом шаге торопиться не стоит.

Отдельно проверьте версию игрового движка на новом сервере командой из консоли (version в Minecraft, вывод при старте для большинства Source-игр) — она должна точно совпадать с той, что писала мир на старом сервере, иначе при первом же чтении сохранения могут посыпаться ошибки формата.

Перенос файлов сохранения: SFTP или rsync

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

Если у вас есть SSH-доступ на оба сервера (VPS/выделенный сервер), самый надёжный вариант — rsync, потому что он докачивает только изменившиеся файлы и не рвётся на больших мирах:

rsync -avz --progress -e ssh /home/steam/rust-server/server/rustserver/ user@new-server-ip:/home/steam/rust-server/server/rustserver/

Для Minecraft то же самое — переносим папку мира и конфиги отдельно от джарников:

rsync -avz --progress -e ssh /opt/minecraft/world/ user@new-server-ip:/opt/minecraft/world/
rsync -avz --progress -e ssh /opt/minecraft/plugins/ user@new-server-ip:/opt/minecraft/plugins/

Если хостинг с панелью (это в целом типичный сценарий для аренды игровых серверов) и прямого SSH нет — используйте SFTP-доступ панели или встроенный файловый менеджер: скачайте архив мира на свой компьютер и загрузите на новый сервер тем же способом. Для больших миров (Rust-карты на 4000+, ARK-сейвы с десятками построек — процедура установки такого сервера описана в статье как поднять сервер ARK: Survival) архивируйте перед переносом — tar -czf world-backup.tar.gz world/ — это и ускоряет передачу, и даёт вам готовый бэкап на всякий случай.

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

Финальное окно: точка невозврата

Это самая короткая и самая важная часть миграции. Последовательность строгая:

1. Предупредите игроков заранее — в Discord сервера, через MOTD или объявление в игре: "Технические работы, сервер будет недоступен ориентировочно N минут". Честное ожидание снижает раздражение сильнее любого извинения постфактум.
2. Остановите старый сервер командой выключения игры, а не обрывом процесса — так все данные корректно сбрасываются на диск. Для большинства игр это stop в консоли (Minecraft, многие Source-движки) или штатная команда выключения через панель.
3. Сделайте финальный бэкап мира именно после остановки, не раньше. Если сохранить архив до stop, в него не попадут последние минуты игры — прогресс потеряется, и всё придётся объяснять комьюнити заново.
4. Перенесите именно этот последний архив, а не более раннюю черновую копию из фазы подготовки — тут легко перепутать файлы, если в папке лежит несколько бэкапов с похожими именами. Проверяйте временную метку файла перед загрузкой.
5. Распакуйте архив в нужную директорию нового сервера, поверх (или вместо) черновой копии, которую заливали заранее.

Именно на шаге 3-4 чаще всего теряют мир — не из-за технической сложности, а из-за спешки в стрессовый момент. Не торопитесь: 10 лишних минут простоя дешевле, чем откат мира на день назад.

Тестирование нового сервера перед объявлением

Не открывайте новый сервер сообществу сразу после переноса файлов. Сначала проверьте сами:

• Запуск без ошибок — смотрите консольный лог на предмет варнингов о несовместимости версии мира, отсутствующих модах или битых чанках.
• Загрузка мира целиком — зайдите сами, пройдитесь по ключевым точкам (спавн, крупные базы, если это возможно проверить), убедитесь что постройки на месте.
• Работоспособность модов/плагинов — экономика, права доступа (permissions), античит — часто именно интеграции ломаются первыми, а не сам мир.
• Сеть и порты — убедитесь, что игровой порт (и Query/RCON, если используете) открыт и проброшен так же, как на старом сервере. Проверить снаружи можно, например, через сторонний сервис проверки открытых портов или просто зайдя с телефона по мобильному интернету.
• Права и владелец файлов (актуально для Linux) — если переносили через SFTP под другим пользователем, права на папку мира могут не совпадать с тем, от чьего имени запускается служба сервера. Это частая причина "сервер стартует, но не видит сохранение".

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

Домен и SRV-запись: переключаем адрес на новый IP

Если у вашего сервера есть собственный домен (например, play.vashserver.ru) вместо голого IP:порт — это стоит того, чтобы не заставлять игроков переучивать новый адрес при каждом переезде. После успешного теста обновите DNS:

• для игр, где подключение идёт по IP:порту напрямую (Rust, ARK, CS2 и большинство Source-игр) — меняете обычную A-запись на новый IP;
• для Minecraft, где хочется скрыть нестандартный порт за красивым доменом — используется SRV-запись, указывающая клиенту, на какой хост и порт подключаться при вводе просто play.vashserver.ru.

Учтите TTL (время жизни) записи в DNS — если он был выставлен на 24 часа, часть игроков ещё сутки будет попадать по старому IP, даже после смены записи. Перед миграцией имеет смысл заранее снизить TTL до 5-10 минут, подождать, пока это применится, и только потом начинать финальное окно переноса — тогда переключение произойдёт быстро для всех.

Не спешите удалять старый сервер

Даже если новый сервер отработал тестовый час без единой ошибки, не отключайте старый сразу. Держите его активным ещё несколько дней (обычно достаточно 3-7 суток) на случай, если:

• всплывёт проблема, которая не проявилась за первый час — например, крашится конкретный плагин при определённом действии игрока;
• понадобится что-то донести с старого сервера — забытый конфиг, лог, скриншот настройки, о которой вспомнили не сразу;
• потребуется откат — если что-то пошло совсем не так, у вас должен быть путь назад без паники.

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

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