A Build 42 unstable update broke my server save: recover or restart
You ran a Project Zomboid dedicated server happily for weeks, an automatic Steam update landed overnight, and now the server either refuses to boot or generates a brand new empty world on top of your community's save. This is the single most common shock for admins running on the Build 42 unstable branch, and it is usually not a Supercraft fault or a corrupt file. It is the unstable branch doing exactly what The Indie Stone warns it will do: change the save format between patches.
The short version: on the unstable branch, a save written by one patch is not guaranteed to load on the next. The 42.15 to 42.16 jump was a hard break, and the dev patch notes spelled it out: "B42.15 and earlier saves will not be compatible with B42.16+ builds." Plan every unstable update as a potential wipe.
Why this keeps happening on unstable
Build 42 is still in active development. The Indie Stone publishes it on the Steam unstable beta branch so players can test the next patch and report bugs. Between those patches the team frequently changes the data structures that the world is written to disk with: the crafting database, animal data, terrain detail, and the multiplayer chunk format have all shifted during the B42 cycle. When the on-disk shape changes, an older save can no longer be read, and the dev team has stated repeatedly that an in-place upgrade is not supported.
Their standing recommendation, repeated in nearly every unstable patch note, is blunt: "it is recommended that you create a new save with no mods after updates." That advice is aimed at single-player, but it applies double to a dedicated server, where the save also carries multiplayer player records and a server database.
The two ways it shows up on a dedicated server
1. The server starts but the world is gone
The process boots cleanly, players connect, and they spawn into a fresh, untouched map. Their old bases, vehicles, and characters are simply not there. This happens when the new patch could not read the old save and silently generated a new one in its place. The old data is usually still on disk under the save folder; the game just refused to load it.
2. The server will not boot at all
The process exits during world load, often with a save-format or a database error in the console. On a dedicated server the multiplayer player database (players.db inside the save folder) and the world chunks were written by the previous patch and the new binary rejects them. The auto-restart in the panel picks the server back up, it fails again, and you get a restart loop.
First move: stop the server and take a backup right now
Before you touch anything, stop the server and take a manual backup. Even a save the new patch cannot load is worth keeping, because the escape hatch below depends on it still existing.
- Click Stop in the panel. Do not let the auto-restart keep cycling.
- Take a Backup Now from the Installation tab, or use Cloud Backup if your panel exposes it.
- Note the save folder so you can find it later: the dedicated world lives at
~/Zomboid/Saves/Multiplayer/servertest/on Build 42 (the data root moved out of the install tree in B42, see B42 server file paths).
If a daily auto-backup already ran from before the update landed, that pre-update snapshot is your cleanest rollback point. Cloud Restore is usually a separate sidebar item from Cloud Backup, so look for both.
Option A: keep playing the old save on the matching branch
When The Indie Stone makes a hard save break, they often pin an outdatedunstable Steam beta branch to the previous version so existing runs are not stranded. For the 42.15 to 42.16 break, the outdatedunstable branch was kept at 42.15. If your save was written by the version that branch is pinned to, you can roll the server back to that branch and your world loads normally.
- Stop the server and confirm you have a backup.
- Open the Installation tab and choose Reinstall.
- Select the outdatedunstable branch instead of unstable.
- Start the server. The old save should load because the binary now matches the version that wrote it.
This is a holding pattern, not a permanent home. The outdatedunstable branch stops receiving fixes, so treat it as the place to finish the current chapter of your world while you decide what to do. Do not subscribe new players to a server you intend to wipe soon.
The community "continue your save" patch: there are Workshop mods that claim to convert a 42.15 multiplayer save so it loads on 42.16+. They can work, but they are unofficial, The Indie Stone does not support continuing across the break, and a converted save can carry subtle world damage. If you use one, keep your untouched backup and test on a copy first.
Option B: accept the wipe and start fresh on the current patch
If your save was written by an older patch than outdatedunstable is pinned to, or you simply want to be on the newest build, the supported path is a fresh world. On a dedicated server you have to clear the old save so the new patch does not try to read it again.
- Stop the server and confirm your backup is safe.
- In the File Manager, delete the world folder:
~/Zomboid/Saves/Multiplayer/servertest/. This removes the chunks, the player database, and the old world data in one move. - Leave
~/Zomboid/Server/servertest.iniandservertest_SandboxVars.luain place so your settings, mod list, and password survive the wipe. - Start the server. The next boot generates a clean world using your existing sandbox and spawn configuration.
Deleting only the save folder, not the whole data root, keeps your configuration. If you also want to reset settings, see soft reset vs hard wipe for the difference between clearing the world and clearing everything.
Audit your mods before you trust the new world
A save break usually rides in on a patch that also changes the modding API. A mod that loaded last week may now silently fail or actively break world generation. After the update:
- Check each Workshop mod's page for a Build 42 and current-patch compatibility note.
- Watch
~/Zomboid/Logs/<date>_DebugLog-server.txtforMod not foundor load errors on first boot. - If the world still misbehaves, boot once with an empty
Mods=line to confirm vanilla loads clean, then re-add mods a few at a time. The full debug flow is in mods installed but not loading.
How to stop being surprised next time
The unstable branch will keep breaking saves until Build 42 promotes to stable. You cannot prevent the format changes, but you can stop them from costing you the world:
- Take a Backup Now before every unstable patch, not just after. A pre-patch snapshot is the only thing that makes Option A possible.
- Glance at the patch notes before reinstalling. The dev team flags hard save breaks in the very first lines of the post. If you see "saves will not be compatible," plan the wipe in advance and tell your players.
- If you want a long-running, untouched world, run the stable branch instead. Build 41 multiplayer is still patched and broadly mod-compatible, and a stable save will not be torn up by a development patch. See unstable branch: what to expect for the full trade-off.
Build 42 multiplayer on unstable is genuinely fun, but it is a preview, and previews change underneath you. Treat each patch as a possible reset and the save breaks stop being a crisis.
Related guides
- PZ unstable branch: what to expect on a server
- B42 server file paths: where saves and config live
- Soft reset vs hard wipe (Build 42)
- Build 42 stable migration guide (for when B42 promotes)
- ZipBackup ENOSPC and map_meta corruption recovery
Want one-click branch switching and a pre-patch backup you can roll back to? Get a Project Zomboid server with daily auto-backups across both branches and a File Manager that surfaces the right save tree for whichever build you are on.