Сервер не сохраняет прогресс: диагностика

MAATRIX GAMES

Заходите на сервер после рестарта — а там вчерашняя база не достроена, лута в сундуках меньше, чем оставляли, или вообще откат на несколько часов назад. Первая мысль обычно про "сервер сломался", но в 90% случаев дело не в поломке, а в том, что сохранение либо не запускалось, либо не успевало дописаться на диск до момента, когда процесс убили. Ниже — порядок проверки по пунктам, от самого частого к самому редкому, без гаданий.

Проверяем, что автосохранение вообще включено

Rust сохраняет мир сам, по таймеру, через консольную команду server.saveinterval (в секундах). Если кто-то когда-то поставил её в 0 или в неадекватно большое значение — сервер может неделями не писать save-файл на диск, и вы просто не замечали, потому что рестартов не было.

Проверить текущее значение можно прямо из консоли сервера или по RCON — вызовите переменную без аргумента, она вернёт текущую настройку:

server.saveinterval

Если стоит 0 — автосохранение выключено полностью, и это первая находка. Выставляйте разумный интервал в стартовых параметрах или в конфиге, который грузится при старте:

server.saveinterval 300

Дальше проверьте, что сохранение реально происходит, а не просто "настроено на бумаге". В консоли или в логе сервера при срабатывании таймера должна появляться строка вида Saving <world name>... и следом отчёт по времени сохранения. Если такие строки не появляются вообще — значит, таймер не тикает, и стоит проверить, не завершается ли процесс раньше, чем истекает интервал (актуально для серверов с частыми рестартами скриптом или хостинг-панелью).

Ручной save для проверки, что сама механика рабочая:

save

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

Где лежат сохранения и как проверить дату файла

Rust пишет мир в отдельную папку внутри server/<identity>/, где <identity> — имя, заданное параметром +server.identity при запуске (по умолчанию часто my_server_identity, но вы могли задать своё). Найти актуальный путь:

find / -iname "*.sav" 2>/dev/null

Основные файлы — <world>.sav, резервная копия предыдущего сохранения <world>.sav.bak и файл карты <world>.map. Смотрим дату изменения:

ls -la /home/rustserver/rust/server/<identity>/

Если .sav файл датирован часами или днями назад, а сервер всё это время работал — вот и подтверждение, что сохранения не долетают до диска. Дальше идём по причинам ниже.

Graceful shutdown vs аварийное завершение

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

Правильный путь — RCON-команда quit (или server.exit, в зависимости от версии сервера), которая инициирует штатное завершение с сохранением перед выходом:

quit

Если сервер запущен через systemd — важно, чтобы юнит останавливал процесс сигналом SIGTERM, а не SIGKILL, и давал время на сохранение перед тем, как считать процесс мёртвым. За настройку Restart=, KillSignal и таймаутов остановки подробно рассказано в статье про systemd, screen и tmux для игровых процессов — если у вас автозапуск через systemd и вы не трогали TimeoutStopSec, по умолчанию он может быть меньше, чем реально нужно серверу на сохранение большой карты, и systemd просто убьёт процесс силой, не дождавшись.

Отдельно проверьте, не завершает ли сервер хостинг-панель или скрипт рестарта через pkill -9 или kill -9 $(pgrep RustDedicated) — это частая практика в самописных крон-скриптах перезапуска по расписанию, и именно она чаще всего стоит за пропавшим прогрессом после планового рестарта. Если у вас настроен автозапуск при перезагрузке хоста, там же стоит свериться, как именно скрипт останавливает старый процесс — см. автозапуск игрового сервера при перезагрузке хоста.

Права доступа к папке сохранений

Если сервер не может писать в директорию server/<identity>/, он либо тихо промолчит в логе (в старых билдах это не всегда явная ошибка), либо выдаст что-то вроде отказа в доступе при попытке записи. Частая причина — папку когда-то создавали или чинили руками из-под root (например, при восстановлении бэкапа через scp или unzip), и владелец файлов сменился на root, а сам сервер работает от отдельного пользователя.

Проверка владельца и прав:

ls -la /home/rustserver/rust/server/

Если владелец не тот пользователь, от которого запущен процесс сервера — чиним:

sudo chown -R rustserver:rustserver /home/rustserver/rust/server/
sudo chmod -R u+rwX /home/rustserver/rust/server/

Замените rustserver на реального пользователя, от которого у вас крутится RustDedicated — посмотреть можно через ps aux | grep RustDedicated, колонка с именем пользователя покажет, кто на самом деле владеет процессом.

Отдельно проверьте права не только на саму папку сохранений, но и на родительские директории вплоть до корня установки — если где-то по цепочке стоит 700 для чужого пользователя, процесс не долезет до конечной папки, даже если права на неё самой правильные.

Не хватает места на диске

Самая обидная причина — сервер физически не может дописать файл, потому что диск заполнен под ноль. Save-файлы у Rust не маленькие: на картах 4000+ с активным вайпом каждый .sav может весить несколько гигабайт, и если параллельно копятся бэкапы, логи и апдейты через SteamCMD — место утекает быстрее, чем кажется.

Проверка:

df -h

Смотрите на раздел, где физически лежит папка с сервером (не всегда это тот же раздел, что корень системы, если у вас смонтирован отдельный диск под данные). Если свободного места меньше пары гигабайт — это уже красная зона: Rust может успешно писать .sav.bak, но не суметь дописать основной .sav, оставив мир в промежуточном состоянии.

Что обычно съедает место незаметно:

• Старые .sav.bak копии, которые никто не чистит годами.
• Логи консоли, если стартовые параметры пишут вывод в файл без ротации.
• Кэш SteamCMD и недокачанные обновления после сбойного app_update.
• Бэкапы карт, сложенные вручную "на всякий случай" и забытые.

Проверить, что именно занимает место:

du -sh /home/rustserver/rust/* | sort -rh | head -10

Освобождать место стоит аккуратно — не трогайте текущий .sav и свежий .sav.bak, чистите то, что старше нескольких вайпов.

Два процесса сервера конфликтуют за один save-файл

Реже, но метко: если случайно запущены два экземпляра RustDedicated с одинаковым +server.identity (например, старый процесс не завершился после неудачного рестарта, а скрипт автозапуска поднял новый поверх), оба будут пытаться писать в одну и ту же папку сохранений. Итог непредсказуем — от гонки за файл до порчи .sav, потому что оба процесса уверены, что владеют картой единолично.

Проверка на дубли:

ps aux | grep RustDedicated

Если в выводе больше одной строки с RustDedicated и одинаковым путём +server.identity — один из процессов лишний. Смотрите, какой из них реально держит игровой порт:

sudo ss -tulpn | grep 28015

(замените порт на свой, если меняли +server.port от значения по умолчанию). Процесс, который порт не держит, — зомби от предыдущего запуска, его нужно корректно остановить (по возможности через RCON quit, если он ещё отвечает, иначе kill, и только потом перезапускать штатным способом).

Такая ситуация типична, если сервер держат в screen/tmux сессии без systemd — старая сессия может "потеряться" из виду, пока новая уже поднялась. Если у вас именно такая схема запуска, стоит свериться со списком активных сессий (screen -ls или tmux ls) перед каждым ручным рестартом — подробнее про разницу подходов в статье про systemd, screen и tmux.

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