Resetting a Project Zomboid server comes in three sizes, and the save folder decides which you get. Deleting Zomboid/Saves/Multiplayer/<servername>/ wipes the world and every character, but leaves accounts, the whitelist and bans, which live in Zomboid/db/<servername>.db. Deleting only the map chunk files inside that folder - and keeping players.db - resets the world while characters keep their skills and inventory. Deleting only the chunks outside the areas you want to protect is a partial reset: the towns refill with loot and zombies, the bases stay. Whichever you choose, stop the server cleanly first, back up the whole Zomboid folder, and raise ResetID in the ini when the world itself is new.
This guide covers what each file in the save is, the three kinds of reset and how to do each one, the settings that force a reset when you change them, and how to run a server so you need resets less often. The wider settings file is covered in Project Zomboid server settings.
What lives where#
Everything a dedicated server knows sits under its Zomboid folder, and every file is named after the server name passed with -servername (default servertest):
Zomboid/ Server/ servertest.ini server options, mods, ResetID servertest_SandboxVars.lua world rules servertest_spawnregions.lua where new characters appear db/ servertest.db accounts, whitelist, access levels, bans Saves/Multiplayer/servertest/ the world as played map_<x>_<y>.bin one file per explored chunk players.db characters: skills, inventory, position vehicles.db vehicles in the world map_meta.bin safehouses, factions and other world metadata map_t.bin the world clock map_sand.bin the sandbox options this world was created with backups/ the server's own zipped backupsThe exact set of files in the save folder varies between builds, and you will see more than are listed here - per-cell zombie population files and various tables. What matters is the three categories:
| What | Where | Survives a world wipe? |
|---|---|---|
| Accounts, passwords, access levels, whitelist, bans | db/<servername>.db | Yes, unless you delete it |
| Characters | players.db in the save folder | Only if you keep that file |
| The world: buildings, loot, zombies, player constructions | Chunk files in the save folder | No |
| Server and sandbox settings | Server/ | Yes |
This is a Build 41 multiplayer layout, where characters are stored on the server. Build 42 changed the map's internal geometry and the save format, and the developers have said Build 41 saves will not carry over to it - so moving a server between the two is a fresh start whatever you keep.
Before any reset#
Every reset starts the same way. Do these in order, every time.
- Announce it. Give a date and say which kind of reset it is. "Map reset, characters kept" and "full wipe" produce very different reactions, and players who were told plan accordingly.
- Stop the server cleanly.
/quitfrom the console, or the panel's Stop. A clean stop writes the world out. A killed process leaves the last minutes unsaved and can leave a chunk half-written, which you will then carefully preserve in a backup. - Back up the entire `Zomboid` folder. Not just the save. Settings, the database and the save together are the only copy that restores to exactly what you had.
- Keep that backup somewhere other than the server's disk. Zomboid's own zipped backups in
Zomboid/backups/sit beside the thing they protect. On RE:NODE, backups are stored off the machine and can be locked against rotation, which is what you want for the last snapshot of a season.
Full wipe: new world, new characters#
The full wipe is the simplest and the most common at the end of a season.
- Stop the server and take the backup.
- Delete
Zomboid/Saves/Multiplayer/<servername>/. - Open
<servername>.iniand increaseResetIDby one. - Change any sandbox options you want for the new season (see below - some only take effect on a new world anyway).
- Start the server. The world generates as players explore, starting from the spawn regions.
ResetID=485729113The value is just a number. What matters is that it changes. Clients remember things about the servers they have joined, and a new ResetID tells them the world they knew is gone, which avoids odd behaviour from stale cached data when they reconnect.
Accounts survive, because they live in the database. Everybody logs in with the same username and password, the whitelist still applies, bans still apply, and moderators keep their access level. If you also want a fresh roster - a new community, or a server that was open and is becoming private - delete db/<servername>.db as well. That removes every account including admin, so have the admin password to hand for the next start; on RE:NODE the admin password is generated per server and shown with its other credentials.
Map reset: new world, same characters#
A map reset gives you a fresh, fully looted world with every zombie back, while players keep their characters - skills, traits, recipes they have learned and whatever they are carrying. It suits a long-running server where the map has been stripped bare but nobody wants to lose two months of carpentry levels.
- Stop the server and take the backup.
- In the save folder, keep
players.db. Decide aboutvehicles.db(below). - Delete everything else in the save folder.
- Start the server.
Characters load with their position from the old world, which means some will log in standing where a building used to have a second floor, or inside a building that is now locked and full of zombies. Two ways to handle that:
- Tell players to log in at a time when friends are around, and accept a little chaos as part of the reset.
- Before the reset, ask everyone to move to an open area - a field, a road - and log out there.
Their bases are gone, of course, along with every item stored in them. Only what a character carries survives. A popular courtesy is to announce the reset a week ahead so people can pack a bag with the things they care about.
vehicles.db holds every vehicle in the world. Keeping it while deleting the chunks under those vehicles is not a combination the game is designed for. Unless you have a specific reason, delete it with the map and let vehicles spawn fresh.
map_meta.bin holds safehouse claims. On a map reset the buildings they refer to are reset too, so delete it; otherwise players hold claims to buildings full of new zombies and loot, which is confusing at best.
Partial reset: refill the towns, keep the bases#
A partial reset is the one most long-running servers end up wanting. Looted towns come back with loot and zombies, while player bases and the areas around them stay exactly as they are.
It works because the world is stored in chunk files, one per explored chunk, named by chunk coordinates. Delete a chunk file and the server regenerates that piece of map from the original map data the next time somebody comes near: fresh loot, fresh zombies, doors closed, windows intact. Keep a chunk file and that piece of the world is unchanged.
In Build 41 a chunk is 10 by 10 tiles, so the file map_1180_1020.bin covers tiles x 11800-11809, y 10200-10209. To protect a base:
- Get the base's tile coordinates. An admin can read them in game; community web maps of the vanilla world show coordinates too.
- Work out the range of chunk coordinates covering the base plus a margin of a few chunks, by dividing tile coordinates by 10.
- Stop the server and back up.
- Delete every
map_<x>_<y>.binoutside the protected ranges. Keepplayers.db,vehicles.dbandmap_meta.bin. - Start the server and visit a reset town and a protected base to check both.
Doing this by hand for more than two or three bases is error-prone. Most admins write a small script, or use one of the community tools built for this, that reads a list of protected rectangles - often taken from the safehouse list - and deletes everything else. Whatever does the deleting, run it on a copy first and look at the result.
Two caveats. Vehicles parked inside a reset area can behave oddly once their chunk has been regenerated; ask players to bring vehicles home first. And the chunk size and file naming changed in Build 42, so a script written for Build 41 coordinates is wrong on a Build 42 server - check the files on your build before trusting any arithmetic, including this guide's.
Settings that need a new world#
Not every sandbox option applies to an existing world. The world stores the sandbox settings it was created with, which is what map_sand.bin is, and several options act once, at creation, or are tied to time since the world began:
- Start date and time -
StartYear,StartMonth,StartDay,StartTime. - Utility shut-off -
WaterShutandElecShutwork from the world's start, so changing them later does not restart the countdown. - Map choices -
Maporder and map mods, which decide the geography chunks are generated from. - Spawn regions - which towns new characters can start in.
Other options, such as zombie population and respawn, loot rarity and XP multipliers, can usually be changed on an existing world through the in-game admin panel's sandbox options or by editing the Lua file and restarting. The full option list is in Project Zomboid SandboxVars explained.
Map mods deserve their own rule. Adding a map mod to an existing world is fine; the new area generates when someone first walks into it. Removing one, or reordering Map so a different map wins in an explored area, leaves chunks that reference map data the server no longer has. That is a reset, at least of the affected area. Project Zomboid server mods covers the Map line and load order.
The soft reset option, and why to be careful with it#
Build 41 has a start-up option, -Dsoftreset, that runs a server-side reset of world objects while keeping characters. It is the kind of feature that appears in old forum threads and patch notes rather than in documentation, and its exact behaviour - what it clears, what it keeps, and whether it suits a modded world - has varied. If you want to try it, copy the server first, run it on the copy, and look at the result before going near the real one. For most servers the file-based resets above are more predictable, because you can see exactly what you removed.
Needing fewer resets#
Resets exist because the map runs out: loot is taken, zombies are cleared, the world goes quiet. Several sandbox options slow that down so a server lasts longer between them.
| Option | Effect |
|---|---|
LootRespawn | Containers refill on a schedule. Off by default |
SeenHoursPreventLootRespawn | Containers players looked into recently do not refill |
ConstructionPreventsLootRespawn | Areas with player construction do not refill, protecting bases |
ZombieConfig.RespawnHours | Zombies return to cells nobody has seen for a while |
ZombieConfig.RespawnMultiplier | How many come back |
Loot respawn with construction protection is effectively a slow, automatic partial reset. It suits public servers where players come and go. For a friends' server that likes the feeling of a world being used up, it removes something, and a reset every few months is the better rhythm.
Troubleshooting#
Players lost their characters after a map reset. players.db was deleted, or the server was started with a different -servername and loaded a different save folder.
Characters were kept but bases from the old world came back. The server was running when files were deleted, and wrote its in-memory chunks back out. Stop it first, and repeat.
Some players cannot join after a full wipe. They have stale client data for the old world. Make sure ResetID was changed, and have them restart the game.
Everyone had to register again. db/<servername>.db was deleted along with the save. Restore it from the backup if you did not mean to.
A protected base lost its garden and fence. The margin was too small. Restore those chunk files from the backup; it is one of the reasons to take it.
The world will not load after a map mod change. A map mod was removed from a world that had explored its area. Put it back, or reset the affected chunks.
The server would not start with new sandbox settings. A typo in the Lua file. The console shows the line. Compare against the file the server generated, or restore the previous one.
FAQ#
Does a wipe delete player accounts?
No. Accounts, passwords, access levels, the whitelist and bans live in Zomboid/db/<servername>.db, not in the save. Deleting the save leaves them alone. Delete the database as well only if you want everyone to register again.
Can players keep their skills through a map reset?
Yes, on Build 41 multiplayer. Characters are stored in players.db in the save folder. Keep that file, delete the rest of the save, and characters return with skills and carried items into a fresh world.
What does ResetID do?
It identifies the world to clients. Changing it tells them the world they remember no longer exists, which avoids stale-data problems after a wipe. Increase it whenever you create a new world.
How do I reset only the looted towns?
Delete the chunk files outside protected areas around player bases, keeping players.db, vehicles.db and map_meta.bin. Chunks regenerate from the original map when visited. Use a script or tool, test it on a copy, and leave wide margins.
Do I need to reset to change sandbox settings?
Only for options tied to the world's creation, such as the start date, utility shut-off timing, the map list and spawn regions. Most other options - zombie population, respawn, loot, XP - can be changed on an existing world.
Can I move a Build 41 world to Build 42?
No. The save format and map geometry changed, and Build 41 worlds do not load on Build 42. Moving a server between them is a new world, and you should plan it as a season change.




Comments
Completely anonymous: no account, no email, no cookie. We store the name you type, the text and the time - nothing else. Links are limited and markup is not rendered.