Project Zomboid: проблема с повреждённым сохранением

MAATRIX GAMES

Заходишь на сервер после перезагрузки хоста или обновления мода — а вместо привычного лутания видишь зависшую загрузку, краш процесса или сообщение с обнулённой версией мира. Битый сейв в Project Zomboid — не редкость: движок регулярно пишет на диск десятки файлов карты, и любой обрыв в неудачный момент (жёсткая перезагрузка, kill -9, забитый диск) может испортить один из них. Разберём, как отличить именно повреждение сейва от других проблем, что можно починить точечно, а когда откатываться сразу к бэкапу.

Как понять, что причина именно в повреждённом сохранении

Симптомы битого сейва в Project Zomboid обычно узнаваемы, но их легко спутать с обычным крашем от мода или нехватки памяти. Смотрите на такие признаки:

• В консоли или логе клиента при попытке зайти на сервер — Error loading savefile, либо в списке миров у сохранения вдруг стоят Last Played: ??? и World Version: 0.
• Серверный процесс стартует, пишет строки инициализации, но падает именно на этапе загрузки конкретной карты — не через час игры, а в первые секунды после старта.
• После обновления мода или самой игры сервер, который вчера работал, перестал подниматься — а откат мода/версии сразу всё чинит (это косвенно указывает не на карту, а на несовместимость, но стоит проверить оба варианта).
• В логе мелькают ошибки, связанные с чтением конкретного чанка или объекта мира, а не с сетью, модами или памятью в целом.

Первым делом гляните на сам процесс:

ps aux | grep ProjectZomboid

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

Где лежат файлы сохранения и что из них могло повредиться

Данные дедицированного сервера разбросаны по двум местам в домашней директории пользователя, под которым он запущен (если ставили сервер по инструкции для Project Zomboid, это servertest по умолчанию, если не меняли -servername):

~/Zomboid/db/servertest.db                  — основная SQLite-база: объекты, зомби, погода, таймеры
~/Zomboid/Saves/Multiplayer/servertest/
    ├── map_ver.bin                          — версия карты и метаданные
    ├── map_X_Y.bin                          — данные конкретных чанков (появляются по мере исследования территории)
    ├── players.db                           — персонажи и инвентари игроков
    └── vehicles.db                          — состояние транспорта

Точный набор файлов немного отличается между билдами игры (в частности, между устоявшимся B41 и более новым B42) и от того, какие моды стоят на сервере — ориентируйтесь на реальное содержимое своей папки, а не строго на этот список. Важно другое: повреждение может задеть как один конкретный map_X_Y.bin (тогда битой окажется одна область карты), так и map_ver.bin или сам .db (тогда сервер не поднимется вообще, независимо от того, куда идут игроки).

Логи, где искать подтверждение, лежат в ~/Zomboid/Logs/ — сначала смотрите свежий server-console.txt, а если по нему не понятно, что случилось, ищите последний файл *_DebugLog-server.txt (это подробный лог движка с Lua-стеком, там обычно и видна причина краша последней строкой перед обрывом):

ls -lt ~/Zomboid/Logs/ | head -5
tail -n 200 ~/Zomboid/Logs/server-console.txt

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

sudo journalctl -u pzserver -f

Первым делом: правильная остановка и что не трогать руками

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

1. Остановите сервер штатно: если это systemd-юнит — sudo systemctl stop pzserver, если запущен вручную в консоли — команда quit в игровой консоли сервера, а не закрытие терминала.
2. Убедитесь, что процесс реально завершился:

pgrep -fa ProjectZomboid

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

1. Никогда не убивайте процесс через kill -9 в момент, когда пытаетесь диагностировать проблему с сейвом, — это ровно тот сценарий, который чаще всего и порождает повреждение файла в первую очередь.

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

cp -r ~/Zomboid/Saves/Multiplayer/servertest ~/Zomboid/Saves/Multiplayer/servertest_broken_$(date +%Y-%m-%d)

Только после этого шага переходите к попыткам починки.

Точечные фиксы: map_ver.bin и повреждённые чанки

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

cd ~/Zomboid/Saves/Multiplayer/servertest
rm map_ver.bin

Запустите сервер и проверьте, поднимается ли карта. Важный нюанс: подставлять map_ver.bin из чужого мира или свежего сингл-сейва (даже с теми же модами) — плохая идея, такие «доноры» несовместимы по внутренней версии и чаще углубляют повреждение, чем чинят его. Если удаление не помогло — откатывайтесь к бэкапу, не экспериментируйте дальше с этим файлом.

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

# Пример: подозрение на битый чанк в районе координат 45, 32
ls map_45_32*.bin

Замените найденные map_45_32.bin, связанные с ним chunkdata_45_32.bin (если есть) и файлы вида zpop_*.bin для той же области — версиями из последнего рабочего бэкапа, скопировав их поверх текущих (после того как сделали копию текущего состояния, как в предыдущем разделе). Это не всегда идеально стыкуется с остальным миром (могут пропасть постройки за период между бэкапом и повреждением именно в этой зоне), но зато не откатывает весь сервер целиком. Для точечных правок такого рода нужен актуальный внешний бэкап — если моды на сервере уже стоят, самое время свериться со списком установленных через Steam Workshop и убедиться, что после последнего изменения набора модов бэкап действительно снимался заново.

Полный откат из внешнего бэкапа

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

1. Сервер уже остановлен (см. выше), процесс подтверждённо завершён.
2. Отложите битое состояние в сторону, не удаляя (если ещё не сделали):

mv ~/Zomboid/Saves/Multiplayer/servertest ~/Zomboid/Saves/Multiplayer/servertest_broken_$(date +%Y-%m-%d)
mv ~/Zomboid/db/servertest.db ~/Zomboid/db/servertest_broken_$(date +%Y-%m-%d).db

1. Распакуйте архив последнего рабочего бэкапа на прежнее место:

mkdir -p ~/Zomboid/Saves/Multiplayer/servertest
tar -xzf /home/pzuser/backups/backup_2026-08-29_04-00.tar.gz -C ~/Zomboid --strip-components=0

Точная команда распаковки зависит от того, как именно вы паковали бэкап (какие пути были в архиве относительно ~/Zomboid) — если сомневаетесь в структуре, сначала распакуйте во временную папку и посмотрите содержимое, а не сразу поверх рабочей директории.

1. Проверьте права доступа — после ручной распаковки файлы иногда оказываются с другим владельцем:

chown -R pzuser:pzuser ~/Zomboid

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

sudo systemctl start pzserver
sudo journalctl -u pzserver -f

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

Как не оказаться здесь снова: внешний бэкап и проверка восстановления

Без регулярного внешнего бэкапа рано или поздно каждый долгоживущий сервер Project Zomboid попадает в ситуацию, когда чинить уже нечем. Специфика именно этой игры в том, что сохранение — это не один файл, а набор из .db и десятков-сотен map_X_Y.bin, поэтому бэкапить нужно сразу обе директории целиком, а не пытаться угадать, какой конкретный чанк-файл когда-нибудь понадобится:

#!/bin/bash
# backup-pz.sh
DATE=$(date +%Y-%m-%d_%H-%M)
tar -czf /home/pzuser/backups/pz_backup_${DATE}.tar.gz \
    -C /home/pzuser \
    Zomboid/db/servertest.db \
    Zomboid/Saves/Multiplayer/servertest

Общая схема настройки автобэкапа через cron, ротации старых копий и выноса архива на другой сервер расписана в статье про автобэкапы игрового сервера — для Project Zomboid она применима без изменений, меняются только пути. Отдельно стоит взять за привычку: перед любым «рискованным» действием (обновление мода, смена пресета сложности, крупная чистка карты через админ-команды) снимать внеплановый бэкап вручную, не дожидаясь ночного cron.

И главное — бэкап нужно хотя бы иногда разворачивать в тестовом окружении и убеждаться, что сервер с ним реально стартует. Архив, который никогда не распаковывали обратно, может оказаться неполным (например, забыли добавить .db в список путей скрипта) — и это вскроется в худший возможный момент, когда бэкап нужен по-настоящему.

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