7 Days to Die не сохраняет прогресс игры — решение

MAATRIX GAMES

Заходите на сервер после рестарта — а база разграблена заново, склад пуст, а то и весь прогресс откатился на несколько дней назад. Знакомая ситуация для админов 7 Days to Die, и в девяти случаях из десяти причина не в мистике движка, а в том, как именно был остановлен процесс перед тем, как мир перестал сохраняться. Разберём, где искать проблему и как её закрыть раз и навсегда.

Как понять, что прогресс правда потерян, а не просто "не тот сейв"

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

Проверьте в первую очередь:

• GameName и GameWorld в serverconfig.xml — сохранение мира привязано именно к этой паре параметров. Если после правки конфига (например, вы меняли WorldGenSeed или переустанавливали сервер) значение GameName изменилось хотя бы на один символ, сервер честно создаст новый мир с нуля в отдельной папке, а старый сейв останется нетронутым на диске.
• Путь до папки сохранений — стандартно это /home/<пользователь>/7dtd/Data/Saves/<GameWorld>/<GameName>/, но если сервер запускался с флагом -datadir или через панель хостинга с нестандартным путём, легко потерять из виду, где физически лежат сейвы.
• Смену пользователя или прав доступа — если сервер запускали то от root, то от отдельного пользователя (как в нашей инструкции про установку сервера 7 Days to Die), сервис может физически не иметь прав на запись в папку с прежними сохранениями и молча создавать новую.

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

Повреждённые файлы в папке Saves

Сохранение мира 7 Days to Die — это не один файл, а набор: main.ttw с общим состоянием мира, региональные файлы карты в подпапке Region (расширение .7rg) и профили игроков в подпапке Player (.ttp). Если запись в любой из этих файлов оборвалась на середине — при следующей загрузке движок либо откатится к последнему целому состоянию, либо не сможет прочитать регион и перегенерирует его заново (что игроки воспринимают как "стёрло прогресс на этом участке карты").

Симптомы битого сейва в логах (journalctl -u 7dtd -f или консоль сервера):

• ошибки вида Error reading region file или Failed to load рядом с координатами конкретного региона;
• сервер зависает на загрузке дольше обычного и в итоге поднимается с "пустым" куском карты там, где раньше была застройка;
• профиль конкретного игрока (инвентарь, статы) сбрасывается, а у остальных всё на месте — почти всегда это повреждённый именно .ttp-файл этого игрока.

Частая причина порчи файлов — запись на диск в момент обрыва питания хоста, заполнение диска под ноль (движок не может дописать файл, но не всегда падает с явной ошибкой) или сетевая ФС с задержками записи. Проверьте свободное место (df -h) в первую очередь — это самая тупая и самая частая причина.

Главная причина: kill вместо graceful shutdown

Если сохранения бьются регулярно, а не разово — почти всегда виновата остановка процесса. 7 Days to Die, как и большинство игровых серверов, пишет мир на диск не непрерывно, а сохраняет "снимок" состояния в определённые моменты, и корректное завершение обязано дождаться, пока текущая операция записи закончится.

Что происходит при разных способах остановки:

• kill -9 или pkill -9 — сигнал SIGKILL, процесс убивается мгновенно, без единого шанса на завершение операции ввода-вывода. Если в этот момент шла запись региона карты — файл остаётся в недописанном, часто нечитаемом состоянии.
• Обычный kill (SIGTERM) без ожидания — сигнал корректный, но если скрипт или систем-юнит не дают серверу времени среагировать и через секунду досылают SIGKILL, эффект тот же, что и выше.
• Команда shutdown через Telnet-консоль (порт 8081 по умолчанию, включается параметром TelnetEnabled) — единственный по-настоящему штатный способ: сервер сохраняет мир и завершает процесс сам.

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

[Service]
...
Restart=on-failure
RestartSec=15
TimeoutStopSec=60

По умолчанию systemd ждёт 90 секунд после SIGTERM и только потом досылает SIGKILL — на большой карте с активной ордой сохранение может не уложиться в стандартный таймаут, особенно на медленном диске. Увеличьте TimeoutStopSec до 90-120 секунд для крупных миров, и не полагайтесь на дефолт вслепую.

Отдельная ловушка — панели управления хостинга. У части панелей кнопка "Стоп" бьёт по процессу напрямую, не дожидаясь сохранения, особенно если сервер завис или долго не отвечает на пинг. Если вы часто видите потери именно после нажатия "Стоп" в панели, а не после честного рестарта VPS — сообщите об этом в поддержку хостинга или переходите на панель, где остановка сервера 7 Days to Die реализована через штатный Telnet-shutdown, а не SIGKILL по таймауту.

Автосохранение и мифы про SaveDataLimit

В комьюнити 7 Days to Die периодически всплывает параметр SaveDataLimit как якобы способ настроить частоту автосейва через serverconfig.xml. Если вы искали его в актуальной версии игры и не нашли — это нормально: в стабильных билдах на конец августа 2026 года такого свойства в конфиге нет, и полагаться на инструкции, где оно упоминается, не стоит — они, скорее всего, написаны под старую альфа-версию или вообще путают 7 Days to Die с другой игрой.

Реальный механизм автосохранения в 7 Days to Die устроен иначе: движок сохраняет мир периодически сам, привязываясь к внутриигровым событиям (смена дня, определённые триггеры), и явно управлять этим интервалом через простое свойство конфига в актуальных версиях нельзя. Что реально работает:

• Ручное сохранение через Telnet — команда saveworld сохраняет текущее состояние мира немедленно, без остановки сервера. Полезно вызывать её из cron перед плановыми операциями (бэкап, обновление, рестарт):

echo "saveworld" | telnet 127.0.0.1 8081

• BloodMoonFrequency и DayNightLength косвенно влияют на то, как часто наступают внутриигровые "контрольные точки" — не путайте их с настройкой сохранений напрямую, это про баланс геймплея.
• Перед каждым внешним бэкапом или обновлением сервера отправляйте saveworld вручную (или через telnet-скрипт) — это надёжнее, чем гадать, успел ли сработать автосейв.

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

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

Если прогресс уже потерян и штатного пути "просто пересохранить" нет — откатываемся на последний рабочий бэкап. Порядок действий:

1. Останавливаем сервер корректно, если он ещё жив и просто выдаёт ошибки — через Telnet shutdown, не kill -9, чтобы не усугубить порчу файлов:

sudo systemctl stop 7dtd

1. Делаем копию текущего (битого) состояния перед тем, как его трогать — мало ли, часть данных из него ещё пригодится:

cp -r /home/sdtd/7dtd/Data/Saves/<GameWorld>/<GameName> \
      /home/sdtd/broken-save-$(date +%Y%m%d-%H%M)

1. Разворачиваем бэкап на место текущей папки сохранения:

rm -rf /home/sdtd/7dtd/Data/Saves/<GameWorld>/<GameName>
cp -r /path/to/backup/<GameName> /home/sdtd/7dtd/Data/Saves/<GameWorld>/
chown -R sdtd:sdtd /home/sdtd/7dtd/Data/Saves/<GameWorld>/<GameName>

Права доступа после копирования — частая мелкая грабля: если бэкап разворачивали от root (например, через scp или rsync в чужой сессии), сервис не сможет писать в папку под своим пользователем, и вы получите ту же проблему по новой кругу.

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

sudo systemctl start 7dtd
journalctl -u 7dtd -f

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

Настройка регулярных бэкапов через cron

Чтобы больше не оказаться в ситуации "восстанавливать нечего", настройте автоматический бэкап с предварительным сохранением через Telnet:

#!/bin/bash
# /home/sdtd/backup-7dtd.sh
BACKUP_DIR="/home/sdtd/backups"
SAVE_DIR="/home/sdtd/7dtd/Data/Saves/RWG/MyGame"
DATE=$(date +%Y%m%d-%H%M)

mkdir -p "$BACKUP_DIR"
echo "saveworld" | telnet 127.0.0.1 8081 > /dev/null 2>&1
sleep 10
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 --

Ставим в cron на ночное время, когда онлайн минимальный:

crontab -e
0 4 * * * /home/sdtd/backup-7dtd.sh

Пауза sleep 10 после saveworld — не для галочки: команда возвращает управление в Telnet мгновенно, но сама запись на диск занимает время, особенно на большой карте. Для тяжёлых миров (30+ игроков или карта 8-10К) паузу стоит увеличить до 20-30 секунд — лучше перебдеть, чем архивировать недописанные файлы. Отдельно от этого сервера полезно держать копии ещё и вне самого VPS — простой rsync бэкапа на другой хост или в облачное хранилище раз в сутки спасёт даже при полном отказе диска, а не только при программной порче сейва.

Профилактика: чек-лист, чтобы это не повторилось

Собрали в один список всё, что реально снижает риск потери прогресса на постоянной основе:

• Никогда не гасите процесс kill -9 — только Telnet shutdown или штатная остановка сервиса с достаточным TimeoutStopSec.
• Проверьте TimeoutStopSec в systemd-юните — для больших миров увеличьте до 90-120 секунд, дефолта может не хватить.
• Держите минимум 15-20% свободного места на диске под директорию сохранений — заполненный диск — частая скрытая причина порчи файлов без явной ошибки в логе.
• Настройте cron-бэкап с предварительным saveworld и храните хотя бы 1-2 недели истории, а не только последнюю копию.
• Не выключайте систему принудительно (по питанию или через панель хостинга) без предварительной штатной остановки сервера — это тот же эффект, что и kill -9.
• После крупных модов или обновлений делайте внеплановый бэкап перед первым запуском с новой версией — если что-то пойдёт не так, откатитесь без потери недель прогресса.
• Если хостинг присылает уведомления о плановых работах на инфраструктуре — заранее сохраняйтесь и по возможности временно останавливайте сервер сами, а не полагайтесь на то, что провайдер сделает это аккуратно за вас.

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