A restored base is only half a recovery if everyone must create a new survivor. Back up Project Zomboid's complete persistent data root while the server is stopped, then prove the archive restores the expected world, accounts and characters together.
This guide covers a self-hosted dedicated server with filesystem access. On 26 October 2026, the developer lists 42.21 as Stable. Keep older saves on their recorded build: Build 41 saves are incompatible with Build 42, and even the 42.19 → 42.20 transition broke save compatibility. Recovery and a version upgrade should be separate operations.
Find the root used by the running instance#
Read the actual launcher, service account and startup log before copying anything. A default Linux installation commonly writes under the service user's Zomboid directory; -cachedir or a container mount can select another location. An administrator's home directory may contain a completely different, unused save.
The examples below assume this verified layout:
| Component | Example |
|---|---|
| Service account | pzserver |
| Persistent data root | /srv/pzserver/Zomboid |
| Internal server profile | coop |
| World and character data | Saves/Multiplayer/coop/ under that root |
| Account database | db/coop.db under that root |
| Settings and sandbox files | Server/coop.ini, Server/coop_SandboxVars.lua and the other profile files |
Keep the entire root, including players.db inside the world folder and the separate account database. Preserve existing database journal or WAL sidecars too. Copying selected map chunks or a lone player database does not produce a coordinated rollback.
Record the exact game build and branch, launch arguments, service user, mod IDs, Workshop items, map order and any wrapper configuration stored outside the root. Preserve the installed mod versions or another reproducible copy: Workshop can change after the backup. If persistent directories are symlinks or separate mounts, include their actual data in the recovery set; an archive of a symlink alone does not preserve its target.
Retain the matching dedicated-server installation, or establish that its exact build remains obtainable before replacing it; a branch name alone does not preserve a withdrawn patch.
Save, stop and make one consistent archive#
Announce maintenance and prevent the supervisor, panel or scheduled task from relaunching the server. In its server console, issue save, wait for the save-completion output, then issue quit and wait until the process exits. These are console commands; in-game administrator chat uses /save and /quit.
Check that no duplicate server still has the same data open. A live filesystem copy can cross SQLite transactions and mix different moments of the world. After a crash, preserve the entire stopped directory before attempting recovery; do not discard journal files to make it look cleaner.
Run this example only after confirming the paths and stopping all writers. The account running it needs read access to the whole data root and permission to create the backup directory. The dated directory must not already exist:
set -eu
umask 077
PZ_DATA='/srv/pzserver/Zomboid'
PZ_BACKUP='/srv/pz-backups/2026-10-26-coop'
test -d "$PZ_DATA/Saves/Multiplayer/coop"
test -f "$PZ_DATA/db/coop.db"
mkdir -m 700 "$PZ_BACKUP"
tar -czf "$PZ_BACKUP/Zomboid.tar.gz" -C "$PZ_DATA" .
cd "$PZ_BACKUP"
sha256sum Zomboid.tar.gz > Zomboid.tar.gz.sha256
sha256sum -c Zomboid.tar.gz.sha256
tar -tzf Zomboid.tar.gz > archive-files.txt
Create /srv/pz-backups beforehand with appropriate ownership. It sits outside the source tree, so the archive cannot include itself. Ensure enough free space: the full root may also contain earlier automatic backups. Keep the build/mod record beside the archive, restrict access because account data is included, and copy the recovery set to another disk or machine. A checksum verifies file integrity; it does not establish that the game can load the archive.
Restore into an empty, isolated location#
Keep the damaged or current root untouched. Use another host or an isolated test instance with its own writable directory and access limited to the test players. Do not point production and recovery processes at the same volume.
If both instances share a physical host, give the test instance its own supervisor and nonconflicting network ports as well; the launch example below assumes a separate isolated host.
Verify the checksum after transferring the archive. Create a new empty /srv/pz-recovery/Zomboid directory and extract this trusted archive into it:
tar -xzf /srv/pz-backups/2026-10-26-coop/Zomboid.tar.gz -C /srv/pz-recovery/Zomboid
Give the test service account ownership and write access to the restored files. Install the matching server build and mod versions. Preserve the internal name coop; changing the public display name is different from renaming the profile, world directory or database.
On the isolated Linux host, from the matching dedicated-server installation directory, start the recovered profile with an absolute data path:
./start-server.sh -servername coop -cachedir=/srv/pz-recovery/Zomboid
Read the log-selected root, profile and version. If the server creates an empty world, stop: check the path, filename case, ownership and mounted directory before allowing players in. If it requests a new character, decline creation and inspect profile/account identity and whether the backup actually includes character data. Do not repair this by deleting account records or rewriting player IDs in the only surviving database.
Prove persistence before reopening#
Join using an existing player's original account and Steam identity. Check their survivor, inventory and position, then inspect a known base, container and vehicle. Make a harmless identifiable change, log out, save and quit cleanly. Restart the recovered instance and rejoin to confirm both character and world changes persisted without database errors.
After that succeeds, schedule the production cutover with the original stopped root retained for rollback. For administration across your own machines, Nexardo offers a way to manage infrastructure; the recovery archive must still include this server's actual persistent files and a tested restoration procedure.
