Подготовьте новый хост без смены версии
На старом хосте запишите java -version, ответ серверной консоли version, путь runtime и используемые TCP/UDP-порты. Новый хост сначала получает те же JAR и Java: обновление ядра одновременно с переездом затрудняет поиск причины отказа.
На новом Linux-хосте установите соответствующий JDK с Adoptium, создайте доступный пользователю каталог /srv/minecraft и проверьте запись. В server.properties пробного экземпляра укажите server-ip=127.0.0.1, server-port=25566; внешние БД и рабочие интеграции направьте на отдельные тестовые данные.
Передайте полную финальную точку
Следующие команды — пример для Linux/OpenSSH: старый runtime /srv/minecraft, новый SSH-адрес mc-new.example, пользователь minecraft. Замените адрес, каталог и пользователя своими. Сначала в консоли Minecraft выполните stop и дождитесь остановки; отключите автоматический запуск старого процесса. Внешняя БД требует отдельной согласованной выгрузки.
Создайте архив вне runtime и отправьте его по SSH. Синтаксис передачи описан в scp OpenSSH. На новом хосте сравните sha256sum /tmp/minecraft-final.tar.gz с исходным выводом, затем распакуйте в пустую папку. Старый архив и хост сохраните до проверки новой точки.
tar -czf /tmp/minecraft-final.tar.gz -C /srv/minecraft .
sha256sum /tmp/minecraft-final.tar.gz
scp /tmp/minecraft-final.tar.gz minecraft@mc-new.example:/tmp/Проверьте запуск на новом компьютере
Войдите по ssh minecraft@mc-new.example, выполните tar -xzf /tmp/minecraft-final.tar.gz -C /srv/minecraft, затем cd /srv/minecraft и привычную команду запуска. Если JAR называется paper.jar, пример — java -Xms2G -Xmx2G -jar paper.jar --nogui. По журналу подтвердите чтение прежних миров и плагинов.
Для локального закрытого теста откройте со своего компьютера SSH-туннель ssh -L 25566:127.0.0.1:25566 minecraft@mc-new.example и войдите Java-клиентом на localhost:25566. Проверьте старый сундук, права, баланс, смену мира и сохранение после stop/повторного запуска. Этот туннель TCP относится к Java; Bedrock UDP проверяется отдельным клиентом после подготовки порта.
Переключите единственную рабочую точку
После закрытого теста остановите новый экземпляр, верните нужные server-ip/server-port, включите проверенные рабочие интеграции и разрешите только требуемые порты. Для Geyser выполните внешний geyser connectiontest НовыйАдрес BedrockПорт. В панели DNS измените A/AAAA и при необходимости Java SRV; проверьте ответ nslookup ВашДомен с клиентского компьютера.
Старый сервер оставьте остановленным: DNS-кэш ещё может вести часть игроков к нему. Проверьте внешний вход Java и Bedrock по опубликованным адресам, создайте новую независимую резервную копию и обновите пути в задаче бэкапа. Только после этого переезд завершён; удаление старого комплекта отложите до подтверждённого восстановления новой копии.
Зафиксируйте всё, что новый хост должен уметь
Начните с параметров окружения: архитектура процессора, Java, объём памяти, дисковая ёмкость, системный пользователь и права каталогов. Затем добавьте сетевые точки: Java TCP, Bedrock UDP, административные локальные интерфейсы и сайт. Переезд Minecraft не завершён, если мир работает, а мост Bedrock, статистика или резервные копии ещё обращаются к старому адресу.
Составьте карту зависимостей без секретных значений. В ней видно, кто читает базу, куда отправляются игровые события и какой сервис выполняет резервное копирование. Для каждого подключения укажите владельца настройки и способ проверки. Ключи перенесите закрытым предусмотренным каналом; публикация рабочего env рядом с планом не требуется для воспроизводимости.
Проверьте, что очередь событий и серверный ключ относятся к правильному экземпляру после переноса. Интеграция с веб-сайтом.
Репетиция покажет реальное время
Восстановите свежую копию на новом хосте с закрытым внешним входом. Сначала проверьте права файлов и запуск runtime. Затем войдите тестовым аккаунтом, посетите несколько миров, измените данные и выполните штатный рестарт. Пустой запуск без чтения прежних баз проверяет лишь установку программы, поэтому используйте согласованную копию настоящей структуры состояния.
Измерьте отдельно время передачи, распаковки, старта и игровых проверок. Большой мир может передаваться намного дольше базы, а медленный диск — удлинить старт. Если планируется предварительная синхронизация и короткий финальный перенос, всё равно обеспечьте остановку записей для последнего согласованного состояния. Копия вчерашнего мира и сегодняшней экономики не является одной точкой.
Подготовьте переключение адреса
Если используется домен, учтите срок кэширования DNS и наличие записей SRV для Java. Bedrock также нужен фактически открытый UDP-порт нового хоста. Проверьте брандмауэр, публикацию контейнера и маршруты заранее. Рабочий ping или HTTPS не подтверждают доступность нужного игрового протокола; подключитесь соответствующим клиентом из внешней сети.
Последовательность локального и внешнего входа помогает найти закрытый порт до переключения игроков. Проверка нового адреса.
Финальная передача без двух писателей
Старый экземпляр должен оставаться остановленным. Кэш DNS может ещё приводить игроков к старому IP, поэтому там полезно оставить ясное сообщение или предусмотренный сетевой маршрут без второй записи состояния. Одновременное продолжение игры в двух копиях создаёт расхождение, которое нельзя устранить простым объединением папок region и балансов.
- Закройте вход на старый сервер и штатно остановите процесс.
- Создайте финальную копию мира, баз и устойчивых журналов.
- Передайте её на новый хост и проверьте целостность файлов.
- Запустите новый экземпляр с проверенными артефактами.
- Выполните критические игровые тесты и проверку внешних интеграций.
- Переключите опубликованный адрес и разрешите вход после успешного результата.
Откат согласуйте с новым прогрессом
До открытия входа откат проще: остановить новый процесс и вернуться к финальной точке на старом хосте. После того как люди начали играть, появляется вопрос о новом прогрессе. Если данные на новом хосте пригодны для переноса назад, нужна отдельная согласованная передача; если повреждены, выбирается сохранённая точка с известной потерей времени.
Не удаляйте старый комплект сразу. Однако запретите его случайный автозапуск после перезагрузки: два systemd-сервиса или контейнера способны подняться независимо. Проверьте конфигурацию запуска, резервных задач и мониторинга. Уведомление должно показывать новый production, а не тихо следить за отключённым старым процессом.
Завершение переноса
Создайте первую независимую резервную копию на новом хосте и выполните восстановление по прежнему регламенту. Обновите карту путей, версии runtime и адреса интеграций. Проверьте свободное место после нескольких сессий: мир, журналы и очереди могут расти иначе на новой схеме хранения.
Сохраните краткий протокол репетиции и активации: какой комплект перенесён, когда закрыта запись и какие проверки прошли. При следующем переезде он позволяет повторить фактическую процедуру. Автоматизация полезна именно тогда, когда каждый её шаг имеет проверяемый результат и понятную границу остановки при ошибке.
