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

MAATRIX GAMES

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

Почему сохранение пропадает или бьётся: три типичные причины

Прежде чем чинить, стоит понять механику. Как и большинство игр на Unreal Engine с собственной системой сохранений, Satisfactory при записи сейва не переписывает существующий файл на месте — он готовит новые данные, пишет их во временный файл и только затем подменяет старую версию. Это защищает от полностью «убитого» сейва при обычном сбое, но не защищает от повреждения, если процесс сервера обрывается именно в момент этой операции — а на большом мире запись занимает не доли секунды.

На практике за жалобой «пропал сейв» или «сервер не грузит мир» почти всегда стоит одна из трёх причин:

1. Процесс сервера завершился некорректно прямо во время записи — принудительное убийство процесса, перезагрузка хоста без остановки службы, обрыв контейнера.
2. На диске физически не хватило места, чтобы дописать новый файл сохранения до конца.
3. Сейв никуда не пропадал — просто сервер смотрит не в ту сессию или не в ту папку, и файл спокойно лежит на месте, просто не виден в интерфейсе.

Дальше разберём каждую по отдельности, начиная с самой обманчивой.

«Сейв пропал», а на самом деле нет: путаница с сессией и папками

Прежде чем паниковать и лезть в бэкапы, стоит проверить самое банальное. Satisfactory хранит сохранения по пути ~/.config/Epic/FactoryGame/Saved/SaveGames/server/ на Linux (на Windows — %LOCALAPPDATA%\FactoryGame\Saved\SaveGames\server\), и Server Manager в веб-интерфейсе (https://IP-сервера:7777) показывает список сохранений исходя из того, с какой сессией вы сейчас работаете. Если сервер переустанавливали, меняли рабочую директорию при обновлении или запускали с другим именем сессии — старый сейв физически может лежать на диске, просто не попадать в список для загрузки.

Проверить напрямую, есть ли файлы на месте, проще всего через SFTP/SSH, не полагаясь на веб-интерфейс:

ls -la ~/.config/Epic/FactoryGame/Saved/SaveGames/server/

Если там есть .sav-файлы с недавней датой изменения — сейв никуда не делся, и остаётся только правильно скормить его серверу через «Load Game» в Server Manager или, если файл лежит не в той папке, скопировать его руками в SaveGames/server/ и перезапустить сервер. Обратите внимание на дату и время последней модификации файла — она честно показывает, когда реально было последнее успешное сохранение, в отличие от того, что может отображать интерфейс.

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

Повреждённый файл после аварийного завершения процесса

Если файлы на месте, но конкретный сейв отказывается грузиться (сервер зависает на загрузке мира, падает сразу после старта или Server Manager сообщает об ошибке чтения) — велика вероятность, что запись оборвалась на середине. Обычно это происходит по одной из таких причин:

• kill -9 вместо аккуратной остановки. Сигнал SIGKILL не даёт процессу дописать текущую операцию — если в этот момент шла запись сейва, файл может остаться в промежуточном состоянии.
• Перезагрузка или выключение хоста без остановки службы. Та же проблема: питание/сеть обрываются раньше, чем процесс успевает корректно завершиться.
• OOM Killer линукса прибивает процесс сервера из-за нехватки памяти — чаще всего именно в момент пиковой нагрузки при сохранении большого мира, когда в оперативной памяти одновременно держится и старое, и готовящееся к записи состояние.

Проверить последнюю причину:

dmesg | grep -i "out of memory"

Строка про Out of memory: Killed process рядом с FactoryServer или похожим именем процесса подтверждает диагноз — это не баг игры, а системная защита от переполнения RAM.

Правильная остановка сервера — всегда через systemd (или другой supervisor), который посылает SIGTERM и даёт процессу время корректно завершиться, а не обрывает его резко:

sudo systemctl stop satisfactory

Если сервер запущен через screen или голым процессом в терминале — используйте Ctrl+C в самой консоли сервера, а не kill -9 из другого окна, и дождитесь, пока процесс сам закроется, прежде чем выключать хост или контейнер.

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

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

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

df -h

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

du -sh ~/.config/Epic/FactoryGame/Saved/SaveGames/server/*

Что чистить в первую очередь, если место в дефиците:

• Логи сервера в Saved/Logs/, если они не ротируются автоматически.
• Старые ручные бэкапы сейвов без разумного лимита хранения — держите последние 7-14 копий, а не всё подряд.
• Кэш SteamCMD после обновлений сервера — временные файлы загрузки иногда остаются на диске.

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

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

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

1. Остановите сервис, чтобы исключить параллельную запись в проблемную папку:

sudo systemctl stop satisfactory

1. Отложите битую версию сейва в сторону, не удаляя сразу — часть данных иногда можно вытащить из неё вручную позже:

mv ~/.config/Epic/FactoryGame/Saved/SaveGames/server/<world>.sav \
   ~/.config/Epic/FactoryGame/Saved/SaveGames/server/<world>-broken-$(date +%F).sav

1. Скопируйте на место последнюю рабочую резервную копию:

cp /path/to/backups/<world>-latest.sav \
   ~/.config/Epic/FactoryGame/Saved/SaveGames/server/<world>.sav

1. Проверьте владельца файла — если копировали от root, права должны принадлежать пользователю, от которого работает служба сервера:

chown steam:steam ~/.config/Epic/FactoryGame/Saved/SaveGames/server/<world>.sav

1. Запустите сервер и сразу следите за логом на предмет повторной ошибки:

sudo systemctl start satisfactory
journalctl -u satisfactory -f

Вместо ручного копирования по SFTP тот же результат даёт вкладка загрузки в самом Server Manager — «Upload Save Game» позволяет залить сохранённую локально копию .sav-файла через браузер, это часто удобнее и надёжнее, чем возиться с правами доступа по SSH.

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

Настройка автосохранения и внешних бэкапов, чтобы не повторилось

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

Простой вариант внешнего бэкапа по расписанию через cron — архивировать папку сохранений с ротацией старых копий:

#!/bin/bash
SAVE_DIR=~/.config/Epic/FactoryGame/Saved/SaveGames/server
BACKUP_DIR=~/backups/satisfactory
DATE=$(date +%F_%H-%M)

mkdir -p "$BACKUP_DIR"
tar -czf "$BACKUP_DIR/save-$DATE.tar.gz" -C "$SAVE_DIR" .

# оставляем только последние 14 копий
ls -1t "$BACKUP_DIR"/save-*.tar.gz | tail -n +15 | xargs -r rm --

Добавить в crontab -e, например, на каждые 6 часов:

0 */6 * * * /home/steam/scripts/backup-satisfactory.sh

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

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