How to Back Up and Restore a Project Zomboid Server

What a complete backup actually includes

The first mistake most admins make is backing up only Zomboid/Saves/Multiplayer/servertest. That protects the map and character data, but not the server identity and admin data around it. If you launch with -servername NAME, replace servertest with that exact name everywhere below.

Use this as your minimum file set:

Two useful distinctions: players.db inside the save folder is character data, while servertest.db in the db folder is accounts and whitelist. Admins often confuse those and then wonder why a “character restore” did not bring back account permissions.

How the built-in backup system works

Project Zomboid has a built-in backup system in servertest.ini. It is worth turning on because it gives you quick, rolling restore points without extra tooling. Just do not confuse it with off-server disaster protection.

BackupsCount=5
BackupsOnStart=true
BackupsOnVersionChange=true
BackupsPeriod=0

BackupsOnStart creates a zip when the server starts. BackupsOnVersionChange does the same when the game version changes. BackupsPeriod is the periodic timer in minutes; 0 means disabled. BackupsCount is how many zips are kept in each rolling set before older ones are overwritten.

Those settings help with different failure types. Startup backups are handy when a restart introduces a problem. Version-change backups are the obvious safety net before an update. Periodic backups protect you from damage done during normal play. Each one zips the world to disk, so the shorter you make the interval, the less progress you lose, but the more often the machine does that work and the faster a small BackupsCount cycles through its slots.

Do not mistake saving for backing up. A normal world save writes current state into the live save. It does not give you history. A backup gives you an older point you can go back to.

Zomboid/
  backups/
    startup/
      backup_1.zip
    version/
      backup_1.zip
    period/
      backup_1.zip

The big weakness is simple: those zips live under Zomboid/backups on the same disk as the live world. If the disk is damaged, the host node fails, a mistaken deletion wipes the folder tree, or the instance is compromised, the backups can disappear with the world. That is why built-in backups are layer one, not the whole plan.

If you change backup options in servertest.ini, you can apply them with reloadoptions and confirm active values with showoptions. Sandbox changes still need a restart.

Build a three-layer routine, based on how much progress you can afford to lose

A backup routine only works if it matches your server’s risk. Think in terms of recovery point, not convenience: how much recent play are you prepared to lose after a bad mod, corruption or griefing incident?

• Layer one: built-in rolling backups. Use startup and version-change backups at minimum. Add periodic backups if you want short rollback points during play.
• Layer two: host panel backups or scheduled copies. This should put a second copy somewhere other than the live save path. On a rented server, that usually means the panel’s backup tool. On your own machine, it means a scheduled archive copied elsewhere.
• Layer three: a manual off-server archive before every update or mod change. This is the one you make deliberately, verify, and keep outside the server before you touch anything risky.

Pick BackupsPeriod from acceptable loss. If you can only accept losing a short stretch of play, use a shorter period. If you mainly care about update protection and can accept rolling back further, rely more on startup and version-change backups. Then set BackupsCount high enough that old zips are not overwritten before your next layer-two or layer-three copy. The rule is not “more is always better”; it is “keep enough restore points to bridge the gap until the next off-server backup”.

How do you know the routine is good enough? Check two things after a week or two: first, that the newest good backup is always within your acceptable loss window; second, that older copies are still there when you actually need them, instead of having been rotated away.

How to take a safe manual backup on Windows, Linux and rented panels

The safe sequence is always the same: save, stop, copy, verify. Stopping the server is the part admins skip, and it is the reason some archives restore into half-written chunks or mismatched databases. A clean stop costs you a short interruption; copying live files risks a useless backup.

1. Warn players and let the world save.
2. Shut the server down cleanly and wait for the process to exit.
3. Copy the save folder, the matching server config files, and the db folder into one archive.
4. Record the mod list if it is not already captured in the backed-up .ini.
5. Open the archive and confirm it is readable before you call the job done.

Windows

On Windows, the usual files live under your user’s Zomboid folder. Copy Zomboid\Saves\Multiplayer\servertest, the relevant files under Zomboid\Server, and Zomboid\db. Compress them into a dated zip and store that zip somewhere off the server machine as well, not just on the same drive.

Verification matters. Do not just trust that the zip exists. Open it and check that the expected folders are present, especially the save folder and the matching servertest.ini.

Linux

On Linux, the same logic applies. If you run a self-managed server and need the wider layout, branch handling or naming conventions, see our dedicated server setup guide. A simple archive command looks like this:

tar -czf "$HOME/pz-backup-$(date +%F).tar.gz" \
  "$HOME/Zomboid/Saves/Multiplayer/servertest" \
  "$HOME/Zomboid/Server" \
  "$HOME/Zomboid/db"

This bundles the live world, the server config set and the database in one file. The resource cost is mostly disk I/O and compression CPU. That is fine during maintenance; it is not what you want to start while the server is under load.

Rented panels

With a rented panel, stop the server first, then use the panel backup tool or file manager to archive and download the same items. The important question is not the panel wording; it is whether you are taking a copy of the complete data set and whether you can keep a copy off the server. A panel snapshot that never leaves the same machine is convenient, but it is still only one failure domain.

If you are about to add or remove mods, take an extra archive of the current state even if your automated schedule ran recently. Mod changes are one of the few moments where a world can become structurally broken rather than merely damaged.

How to restore a whole world, or only player characters

Restores go best when you decide the scope first. Do you want to undo world damage, or only send character data back to an earlier point? The restore order below keeps the server identity and account data aligned with the world state.

1. Stop the server fully. Do not restore on top of a running instance.
2. Take a copy of the current broken state first. If your first restore attempt is wrong, you want a way back.
3. Choose the restore scope. Full world for griefing, corruption or bad map changes; players.db only for character rollback.
4. Restore the matching files together. For a full restore, that means the save folder, the matching servertest.ini, the sandbox and spawn files, the db folder, and the mod list that belongs to that backup.
5. Check build and mod match before startup. The server and every client must be on the same game build, and the mod list must match the restored world.
6. Start the server and watch the logs. Check server-console.txt for missing mods, map errors or login issues before players pile in.

Restore only players.db

If the map is fine but characters were lost, corrupted or wiped, replace only players.db inside the world save folder with the backed-up copy. This rolls back inventories, skills, positions and character state without rewinding buildings, containers or vehicle work.

The catch: players.db holds every character on the server, so swapping the file rolls back everyone, not just the player who had the problem. That suits a server-wide character wipe or corruption. For one player who lost a character to a bug, it is usually kinder to the rest of the group to give their progress back with admin commands instead, such as /additem "username" Base.Axe 1 for items and /addxp "username" Woodwork=2 for skills.

The ResetID trap

If you restore a world but keep a different servertest.ini with changed ResetID or ServerPlayerID, players are treated as if they belong to another server identity and are forced to create new characters. This is one of the most common “the restore failed” reports, even though the world files themselves are fine.

The fix is to restore the matching .ini from the same backup, or at least make sure those values match the original server state. You can tell it worked when players reach their existing characters instead of the character creation screen.

Rollback after a bad update or mod change

Updates and mod changes are the two events most likely to turn a healthy world into a restore job. The safe approach is to make a manual off-server backup before the change, then roll back both the data and the software state if the change goes wrong.

1. Stop the server.
2. Restore the pre-change backup set: world, config, db and mod list.
3. Put the server back on the same build that backup was made on.
4. Make sure every client joins on the same build and branch.
5. Restore the original mod and map order exactly, then test before reopening fully.

Build compatibility matters here. Build 41 saves are not compatible with Build 42. Unstable 42.19 saves are not compatible with 42.20, and groups finishing those worlds need the 42.19 branch. If you are planning a bigger branch jump rather than a simple rollback, read our Build 42 migration guide before you touch the live server.

Mods add another layer. A save may depend on item definitions, tiles and map folders that no longer exist after a mod removal or reorder. Later map entries overwrite earlier ones where they intersect, so load order is part of the backup, not a minor detail. If the issue is somewhere in the mod stack, use a controlled disable-and-test approach rather than changing everything at once; our Workshop and map mods guide covers the server-side rules that matter.

On Build 42, if a mod that worked before now fails to load, check server-console.txt first. Guidance around how the Mods= line is written has varied by build and host panel, so the safest approach is to let the in-game Host or the panel write that line and then confirm in the log that the server accepted it.

Common restore symptoms, likely causes and the first fix to try

If the restore is clean but the server is still struggling, that is usually a separate performance problem, not a backup problem. Population growth, players spread across towns and a cramped Java heap all add pressure to the main simulation thread and memory. For that side of the job, see our Project Zomboid server lag guide and Project Zomboid server RAM guide.

What to check in a host’s backup system before you trust it

If you are comparing providers, do not just look at location and RAM. Backup handling decides how quickly you recover when something goes wrong, and that can matter more than raw plan size. Our Project Zomboid server hosting comparison is a useful starting point, but you still want to inspect the backup options closely.

Here is what the hosts in our comparison include for backups, in our ranking order:

A dash means the host doesn’t say where its backups are kept, so ask before you rely on them as your only copy. Whatever the host offers, these are the questions that decide how well you can recover:

The ideal host backup system reduces recovery time, but it does not remove the need for your own manual archive before risky changes. A panel restore is for speed. Your off-server copy is for certainty.

Project Zomboid server FAQ

Where are Project Zomboid server saves stored?

The world save normally lives in Zomboid/Saves/Multiplayer/servertest. The matching config files live in the Zomboid/Server folder, and account or whitelist data lives under Zomboid/db. If you use -servername NAME, those file names and save folders use that name instead of servertest.

How often should my server back up?

Set the periodic backup interval from the amount of progress you can afford to lose. Shorter intervals reduce rollback loss, but mean more disk work and need a higher BackupsCount to keep the same span of history. Even with a good schedule, still take a manual off-server backup before updates or mod changes.

Can I restore just one player’s character?

Not with a simple file copy. players.db holds every character on the server, so restoring it rolls back the whole group’s characters while leaving the map as it is. For a single player, admins usually give back lost items and skills with /additem and /addxp instead, and save the players.db restore for problems that hit everyone.

Will a backup from Build 41 work on Build 42?

No. The developers have stated that Build 41 saves are not compatible with Build 42. If you are moving branches, treat that as a migration project, not a normal restore, and make sure the server and all clients stay on the same build.

Are my host’s backups enough on their own?

Usually not. Host backups are useful for fast recovery, but you still need your own manual off-server archive before updates, build changes and mod work. The main reason is simple: you want at least one copy that is outside the live server environment and under your control.

More Project Zomboid server guides

The rest of our Project Zomboid server guides, plus the host comparison.