Перенос игрового сервера на более мощный VPS или к другому провайдеру часто превращается в многочасовой простой для сообщества игроков. Если администратор пытается архивировать 80-гигабайтную директорию сервера в tar-архив и передавать её по сети после остановки процесса, игроки теряют доступ на несколько часов, а ошибки распаковки прав доступа (chown) приводят к сбоям запуска.
В этой статье разобран профессиональный протокол миграции с минимальным временем простоя (zero-downtime transition) с помощью двухэтапной синхронизации rsync, предварительной проверки зависимостей и безопасного переключения сети.
Подготовка целевого VPS и системных библиотек#
Самая частая причина неудачной миграции — запуск переноса на «голый» сервер без предварительно установленных библиотек ядра и рантаймов. Проверьте и установите необходимые зависимости на новом VPS до начала каких-либо манипуляций со старым сервером.
Создайте сервисного пользователя с идентичным UID на целевой машине:
sudo useradd -u 1001 -m -s /bin/bash gameserver
sudo mkdir -p /opt/gameserver
sudo chown -R gameserver:gameserver /opt/gameserver
Установите 32-битные и системные библиотеки, требуемые игровыми движками SteamCMD:
sudo dpkg --add-architecture i386
sudo apt update && sudo apt install -y lib32gcc-s1 lib32stdc++6 rsync curl
Фаза 1: Предварительная синхронизация статических данных онлайн#
Тяжеловесная часть любого игрового сервера — это исполняемые файлы движка, текстуры, звуки и карты мастерской (Steam Workshop). Они занимают 95% дискового пространства, но не изменяются во время работы сервера.
Выполните первичную синхронизацию со старого сервера прямо во время активной игры. Ключ --exclude защитит активные файлы сохранений и журналов от рассинхронизации:
rsync -avz -P --numeric-ids \
--exclude="saved" \
--exclude="saves" \
--exclude="*.log" \
/opt/gameserver/ gameserver@NEW_SERVER_IP:/opt/gameserver/
Флаг --numeric-ids гарантирует перенос числовых идентификаторов владельца без искажения имен пользователей, а ключ -z сжимает данные на лету, ускоряя передачу через интернет.
Фаза 2: Остановка сервера и финальная дельта сохранений#
Когда основная масса данных уже находится на новом VPS, объявите технический перерыв в игре (за 15 и 5 минут до отключения) и корректно остановите игровой процесс на старом сервере.
Остановите службу systemd на исходном VPS:
sudo systemctl stop gameserver
sudo systemctl is-active gameserver || echo "Process stopped"
Теперь выполните финальную передачу изменчивых данных (миры, инвентари игроков, sqlite базы). Поскольку объем этих файлов составляет всего несколько сотен мегабайт, операция займет меньше одной минуты:
rsync -avz -P --delete --numeric-ids \
/opt/gameserver/ gameserver@NEW_SERVER_IP:/opt/gameserver/
Флаг --delete удалит на целевом сервере устаревшие временные файлы, которых уже нет в источнике, обеспечив побитовую идентичность директории.
Перенос службы systemd и переключение сети#
Скопируйте юнит-файл службы systemd на новый сервер и примените конфигурацию:
scp /etc/systemd/system/gameserver.service root@NEW_SERVER_IP:/etc/systemd/system/
На новом VPS перезагрузите конфигурацию systemd и активируйте службу:
sudo systemctl daemon-reload
sudo systemctl enable --now gameserver
sudo systemctl status gameserver --no-pager
Проверьте, что сервер успешно слушает необходимый UDP-порт:
ss -ulnp | grep 27015
После успешного старта обновите A-запись вашего доменного имени или сообщите сообществу новый IP-адрес.
При регулярном управлении парком машин централизованные инструменты развёртывания в рамках панели управления серверами автоматизируют подобные миграции через декларативные профили конфигурации, исключая ручной ввод команд на уровне ОС.
