Экспорт и импорт игрового мира между серверами

MAATRIX GAMES

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

Чем это отличается от полной миграции сервера

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

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

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

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

Шаг 1: останавливаем запись перед копированием

Главное правило, которое нарушают чаще всего: нельзя копировать файлы мира, пока сервер продолжает в них писать. Игра постоянно сбрасывает данные на диск — регионы чанков в Minecraft, *.sav-файлы в ARK, содержимое server/<identity>/ в Rust. Если скопировать папку на лету, есть риск получить файл в промежуточном состоянии — не битый гарантированно, но и не факт что целый, а разбираться потом на боевом сервере совсем не хочется.

Правильный порядок:

# останавливаем сервер (или используем save-off, если хотите не выключать целиком)
screen -r minecraft-server
save-all
save-off

Для Minecraft save-off + save-all в консоли достаточно, если сервер должен продолжать принимать игроков (запись мира заморожена, но сам процесс жив) — но для чистого переноса между серверами надёжнее всё-таки штатно остановить процесс командой stop, дождаться, пока он допишет данные и завершится, и только потом копировать. Для игр без консольной команды сохранения (многие сборки на Rust, ARK, Palworld) единственный надёжный вариант — штатная остановка сервиса:

systemctl stop rust-server
# или, если запущено через screen/tmux без systemd-юнита
screen -r rust -X stuff "quit\n"

Не используйте kill -9 для остановки — резкое прерывание процесса с большей вероятностью оставит файл сохранения в незавершённом состоянии, чем штатный stop, у которого есть шанс корректно дописать данные и закрыть дескрипторы.

Шаг 2: находим и упаковываем нужные файлы

Что именно копировать — зависит от игры. Вот ориентир по самым частым:

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

Упаковывайте одним архивом, чтобы не растерять файлы и не сбить права доступа при копировании:

tar -czf world-export-$(date +%Y%m%d).tar.gz world/ world_nether/ world_the_end/

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

sha256sum world-export-20260830.tar.gz

Шаг 3: совместимость версий — самое узкое место

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

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

Перед переносом сверьте версию игры на исходном и целевом сервере одной командой — для большинства серверов это можно увидеть в логе запуска или в файле вроде version_history.json (Minecraft) или в баннере консоли при старте. Если версии не совпадают — сначала приведите целевой сервер к нужной версии (или наоборот, обновите исходный, если откат назад по версии не критичен), а уже потом переносите мир. Переносить «на удачу» между разными версиями не стоит — в лучшем случае получите ошибку при загрузке, в худшем — часть мира тихо потеряется, и вы заметите это через неделю, когда кто-то из игроков спросит, куда делась его база.

Шаг 4: конфигурация переносится отдельно от мира

Частая ошибка — думать, что если скопировать папку мира, сервер «просто заработает» на новом месте с теми же настройками. Это не так: server.properties, permissions.yml, whitelist/ban-листы, конфиги плагинов и модов физически лежат отдельно от файлов мира и сами по себе не переносятся.

Если целевой сервер — новый и настраивается с нуля, конфигурацию нужно перенести явным отдельным шагом:

scp server.properties whitelist.json ops.json banned-players.json user@new-server:/path/to/server/
scp -r plugins/*/config.yml user@new-server:/path/to/server/plugins/

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

Подробнее про то, как безопасно работать с конфигами разных форматов (ini/cfg/json/yaml) и когда после правки нужен полный рестарт, а когда хватает reload — в статье работа с конфигурационными файлами игрового сервера.

Шаг 5: копируем на целевой сервер

Для передачи файлов между серверами проще и надёжнее всего scp или rsync напрямую по SSH — без промежуточных облачных дисков, которые добавляют лишнее звено и время:

scp world-export-20260830.tar.gz user@new-server-ip:/home/user/

Для больших миров (на survival-серверах вроде ARK или Valheim архив может тянуть на десятки гигабайт при долгой истории) удобнее rsync — он показывает прогресс и, если соединение оборвётся, докачает файл, а не начнёт заново:

rsync -avzP world-export-20260830.tar.gz user@new-server-ip:/home/user/

На целевом сервере распаковывайте прямо в директорию сервера, предварительно убедившись, что старая папка мира (если она там была — например, на тестовом сервере, куда переносят боевой мир для отладки) переименована в бэкап, а не удалена сразу:

mv world world.old-$(date +%Y%m%d)
tar -xzf world-export-20260830.tar.gz -C /path/to/server/
chown -R gameserver:gameserver world/

Права доступа — отдельная мелкая грабля: если архив собирали от root, а сервер на новой машине запускается от отдельного пользователя gameserver, файлы после распаковки могут принадлежать не тому владельцу, и сервер откажется их читать при старте. chown после распаковки закрывает этот вопрос.

Шаг 6: запуск и проверка целостности

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

1. Запустите сервер и смотрите лог старта — если формат мира не читается или версия не совпала, это обычно видно сразу: ошибки чтения чанков, exception при загрузке сущностей, отказ стартовать вовсе.
2. Зайдите сами и визуально осмотритесь — постройки на месте, ландшафт не «съеден», спавн корректный. На больших мирах не обязательно облетать всё — но ключевые точки (спавн, известные базы игроков, торговые зоны) стоит проверить целиком.
3. Проверьте, что плагины/моды видят свои данные — экономика показывает правильные балансы, claims/территории привязаны к нужным игрокам, а не сброшены.
4. Сверьте количество онлайн-объектов, если есть с чем сравнить — например, число зарегистрированных претензий на землю или записей в базе игроков до и после переноса не должно радикально отличаться.
5. Не удаляйте архив и переименованную старую папку сразу. Держите их минимум несколько дней после переноса — если проблема всплывёт не в первую минуту, а через день активной игры (например, повреждённый чанк, до которого никто не долетел сразу), у вас должен быть путь назад. Как именно откатываться на резервную копию, если перенос всё-таки пошёл не по плану — подробно описано в статье восстановление сервера из бэкапа: практика.

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