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

MAATRIX GAMES

Заходите на фабрику после рестарта сервера — а поезда стоят не там, где вы их оставляли, склад биоплазмы наполовину пуст, или сервер вообще не может загрузиться и молча падает при старте. Прогресс в Factorio теряется реже, чем в играх с более простой моделью сохранений, но зато когда это случается, часто бьёт по-крупному: карта на десятки часов может откатиться сразу на автосейв многочасовой давности. Разберём по порядку, где искать причину и как вернуть фабрику к жизни.

Сначала выясняем, что именно произошло

Прежде чем чинить, стоит понять, с каким именно сценарием вы столкнулись — они лечатся по-разному.

• Сервер вообще не стартует, падает с ошибкой при загрузке сейва — файл .zip скорее всего повреждён.
• Сервер стартует, но карта откатилась на заметный промежуток — сохранение либо не успело записаться перед остановкой, либо вы случайно загрузили не тот файл.
• Файл сейва весит 0 байт или заметно меньше обычного — запись оборвалась на середине, почти всегда из-за нехватки места на диске или аварийного завершения процесса.

Первым делом смотрите лог сервера — если вы направляли вывод в файл флагом --console-log, ищите последние строки о сохранении:

tail -100 ~/factorio-server/factorio/console.log

Строка вида Saving game as _autosave3.zip подтверждает, что запись хотя бы началась. Если следом нет строки об успешном завершении (Saving finished) — процесс, скорее всего, убили посреди записи, и это подозреваемый номер один.

Сервер убили до того, как он дописал сейв

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

Если сервер запущен через systemd (как в стандартной установке headless-сборки), проверьте таймаут на остановку в юните:

sudo systemctl cat factorio

Если параметр TimeoutStopSec не задан явно или стоит маленьким (systemd по умолчанию даёт около 90 секунд, но некоторые самописные юниты урезают этот срок), а сервер как раз попал под систематический рестарт мониторингом — есть риск, что процесс убьют силой раньше, чем он допишет большую карту. Увеличьте таймаут явно:

[Service]
TimeoutStopSec=120

После правки — sudo systemctl daemon-reload и перезапуск сервиса.

Важная оговорка: поведение headless-сервера Factorio на сигналы SIGTERM/SIGINT менялось от версии к версии, и я не готов гарантировать, что конкретно ваша сборка всегда успевает сохраниться при обычной остановке systemd (systemctl stop). Надёжнее всего — не полагаться на сигнал вслепую, а завершать сервер явной командой через консоль (stdin) или RCON:

/quit

Она инициирует штатное завершение. Если видите в логе финальную запись о сохранении перед строкой о выходе — всё отработало правильно. Если сомневаетесь, что стоит именно за вашей текущей схемой автозапуска (скрипт, панель хостинга, systemd) — стоит свериться с общей статьёй про systemd, screen и tmux для игровых процессов, там разобрано, как правильно настраивать сигналы остановки для игровых серверов в целом.

Кончилось место на диске

Обидная, но очень частая причина — сервер физически не может дописать файл, потому что раздел заполнен под ноль. У Factorio сейвы растут вместе с картой: у поздней фабрики с сотнями составов, разросшимися заводами и модами вроде Space Exploration архив легко может весить сотни мегабайт, а autosave_slots по умолчанию хранит сразу несколько таких копий одновременно.

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

df -h

Смотрите именно на раздел, где физически лежит папка factorio/saves/ — если сервер на отдельном смонтированном диске под данные, корневой раздел системы может быть свободен, а данные всё равно упрутся в лимит.

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

• Накопленные автосейвы, если autosave_slots выставлен большим, а карта — тяжёлой.
• Ручные бэкапы папки saves/, сделанные "на всякий случай" и забытые.
• Логи консоли без ротации, если запускали с --console-log и никогда их не чистили.
• Кэш обновлений, если качали новую версию поверх старой без удаления временных архивов.

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

du -sh ~/factorio-server/factorio/saves/* | sort -rh | head -10

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

Проверяем права на папку с сейвами

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

Проверка:

ls -la ~/factorio-server/factorio/saves/
ps aux | grep factorio

Сверьте пользователя из вывода ps aux с владельцем файлов. Если они не совпадают:

sudo chown -R youruser:youruser ~/factorio-server/factorio/saves/
sudo chmod -R u+rwX ~/factorio-server/factorio/saves/

Замените youruser на реального пользователя, от которого крутится процесс. Проверьте права не только на саму папку saves/, но и на родительские каталоги — если где-то по цепочке стоит слишком жёсткое ограничение для чужого владельца, до конечной папки процесс не доберётся, даже если права на неё самой в порядке.

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

Если основной файл сейва (например, base.zip) оказался битым или недописанным, паниковать рано — Factorio по умолчанию хранит несколько ротирующихся автосохранений отдельно от основного файла, в той же папке saves/, с именами вида _autosave1.zip, _autosave2.zip и так далее (количество слотов задаётся полем autosave_slots в конфиге).

Сначала проверьте, что архив вообще целый, прежде чем тратить время на попытку его загрузить:

unzip -t ~/factorio-server/factorio/saves/base.zip

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

ls -la ~/factorio-server/factorio/saves/

Выбирайте самый свежий _autosaveN.zip, у которого дата изменения выглядит осмысленно (не 0 байт, не совпадает по времени с моментом сбоя). Запуск с конкретным файлом:

./bin/x64/factorio --start-server ~/factorio-server/factorio/saves/_autosave2.zip \
  --server-settings ~/factorio-server/factorio/data/server-settings.json

Есть и более ленивый способ — флаг --start-server-load-latest заставляет сервер самостоятельно найти и загрузить самый свежий по времени файл в папке saves/ (включая автосейвы), не разбираясь руками, какой из них новее:

./bin/x64/factorio --start-server-load-latest \
  --server-settings ~/factorio-server/factorio/data/server-settings.json

Если и автосейвы не спасают (например, папка saves/ пострадала целиком — упал диск, кто-то случайно стёр каталог) — остаётся внешний бэкап. Если у вас хостинг с настроенным автобэкапом на уровне панели, а не только внутриигровыми автосейвами — механика периодичности и восстановления точек описана в статье про автобэкапы игрового сервера. Если бэкапов на уровне хостинга нет, а свои вы делали cron-задачей — распакуйте нужный архив в saves/ и запускайте сервер как обычно, указав восстановленный файл явно.

Настраиваем автосейв, чтобы не терять прогресс впредь

После того как пожар потушен, стоит перепроверить настройки автосохранения в server-settings.json, чтобы следующий раз обошёлся без нервов:

{
  "autosave_interval": 10,
  "autosave_slots": 5,
  "autosave_only_on_server": true,
  "non_blocking_saving": true
}

• autosave_interval — интервал автосейвов в минутах. Чем меньше значение, тем меньше потенциальная потеря при сбое, но тем чаще сервер пишет на диск — на очень больших картах это заметная нагрузка на I/O. 10 минут — разумная стартовая точка, не догма; если у вас скромная база и слабый диск, можно держать интервал больше, если карта огромная и вы боитесь потерь — меньше.
• autosave_slots — сколько последних автосейвов хранится одновременно по кругу. Больше слотов — больше шансов найти рабочую точку восстановления, если один из файлов окажется битым, но и больше места на диске уходит.
• autosave_only_on_server — если true, автосейв срабатывает по таймеру сервера независимо от того, что происходит у клиентов; полезно, чтобы не зависеть от подключения игроков.
• non_blocking_saving — включает запись сейва в отдельном процессе, чтобы игра не подвисала на всех подключённых во время записи большого архива. Насколько заметен выигрыш — зависит от размера карты и версии игры, универсальных цифр тут давать не буду, но включать стоит почти всегда, ощутимого минуса у опции нет.

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

/server-save

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

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