Core Keeper: проблема с сохранением прогресса

MAATRIX GAMES

Зашли на сервер Core Keeper после рестарта, а там либо откат на несколько часов назад, либо сейв вообще не грузится и сервер стартует с ошибкой. Обидно вдвойне, если вы неделю копали к боссам на нижних уровнях и вложились в строительство базы. Хорошая новость — в подавляющем большинстве случаев дело не в баге игры, а в одной из нескольких конкретных и вполне чинимых причин, и ниже разберём их по порядку — от самой частой к самой редкой.

Как вообще устроено сохранение в Core Keeper

Core Keeper пишет прогресс мира на диск не постоянно, а по внутреннему таймеру и в ключевые моменты — например, при штатном выключении сервера. В отличие от игр с явной командой save в консоли, у выделенного сервера Core Keeper нет широко задокументированного RCON-интерфейса для форс-сохранения "по требованию" — сервер сам решает, когда писать данные на диск, ориентируясь на внутреннюю логику.

Из этого следует важный практический вывод: если процесс сервера убивают резко, посреди игровой сессии, есть шанс потерять всё, что накопилось с момента последнего автоматического сохранения. Именно поэтому большинство жалоб на "пропавший прогресс" в Core Keeper сводится не к поломке самой игры, а к тому, как именно сервер останавливают.

Точный путь к файлам сохранения зависит от версии сервера и способа установки, но обычно это подпапка внутри директории установки или в пользовательском каталоге. Найти её на своей машине можно так:

find ~ -iname "*.sav" -o -iname "*.dat" 2>/dev/null | grep -i core

Запомните этот путь — он понадобится и для проверки прав доступа, и для бэкапов, о которых ниже.

Причина №1: сервер убивают, а не останавливают штатно

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

Правильный способ — дать процессу сигнал SIGTERM и подождать, пока он сам завершится штатно, а не рубить его сразу SIGKILL:

kill -SIGTERM $(pgrep CoreKeeperServer)

Если сервер запущен через systemd-юнит (как в базовой инструкции по установке), проверьте параметры остановки в файле юнита — TimeoutStopSec по умолчанию может оказаться меньше, чем реально нужно серверу на дозапись данных при большом изученном мире:

[Service]
...
KillSignal=SIGTERM
TimeoutStopSec=30

Про то, как правильно настраивать автозапуск и остановку игровых процессов через systemd, screen или tmux, подробно написано в статье про systemd, screen и tmux для игровых процессов — если у вас сервер поднят через одну из этих схем, стоит свериться, не рубит ли скрипт рестарта процесс жёстче, чем нужно.

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

Причина №2: не хватает места на диске

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

Проверка свободного места:

df -h

Смотрите именно на раздел, где физически лежит папка с игрой и сохранениями — если у вас смонтирован отдельный диск под данные, корневой раздел может быть свободен, а рабочий диск — забит под ноль. Меньше 1-2 ГБ свободного места — уже тревожный сигнал.

Что обычно съедает место на сервере Core Keeper незаметно:

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

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

du -sh ~/coreserver/* 2>/dev/null | sort -rh | head -10

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

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

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

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

ls -la ~/coreserver/

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

sudo chown -R coreserver:coreserver /home/coreserver/coreserver
sudo chmod -R u+rwX /home/coreserver/coreserver

Замените coreserver на реальное имя пользователя, от которого у вас крутится процесс — узнать можно через:

ps aux | grep CoreKeeperServer

Колонка с именем пользователя в выводе покажет, кто фактически владеет процессом, а значит, кто должен владеть и папкой сохранений.

Причина №4: два процесса сервера пишут в один сейв

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

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

ps aux | grep CoreKeeperServer

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

sudo ss -tulnp | grep 27015

Процесс, который порт не удерживает, — зомби от предыдущего запуска. Остановите его корректно (штатным сигналом, см. причину №1), убедитесь, что он действительно завершился, и только после этого перезапускайте сервер обычным способом — через systemctl start corekeeper или ваш стартовый скрипт.

Восстановление из бэкапа

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

Порядок действий при восстановлении:

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

tar -xzf ~/backups/coreworld-20260828-0300.tar.gz -C /home/coreserver/coreserver/saves

1. Проверьте владельца и права распакованных файлов — после tar от root они снова могут принадлежать не тому пользователю (см. причину №3).
2. Запустите сервер и проверьте, что мир грузится и содержит ожидаемый прогресс.

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

Настройка регулярного бэкапа как профилактика

Раз штатной команды принудительного сохранения по запросу у Core Keeper Server нет, единственная надёжная страховка — регулярный бэкап файлов мира по расписанию, независимо от внутренней логики автосохранения игры.

Простой вариант — cron-задача, которая архивирует папку сохранений раз в несколько часов:

crontab -e

Добавьте строку (бэкап каждые 4 часа):

0 */4 * * * tar -czf /home/coreserver/backups/coreworld-$(date +\%Y\%m\%d-\%H\%M).tar.gz -C /home/coreserver/coreserver/saves . 2>> /home/coreserver/backups/backup.log

Не забудьте настроить и очистку старых архивов, иначе бэкапы сами станут причиной нехватки места на диске (см. причину №2) — например, хранить только последние 10-14 копий:

ls -t ~/coreserver/backups/*.tar.gz | tail -n +15 | xargs -r rm

Если планируете смену тарифа или расширение RAM под сервер, при апгрейде важно не потерять текущий мир и сохранения в процессе переноса — об этом отдельно в статье про апгрейд тарифа без потери мира и сохранений.

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