Create a Project Zomboid server backupBack up world, player data and configuration

Published on August 9, 2026 · last updated on October 21, 2026

What should be backed up

Project Zomboid separates world, players and configuration - all three belong in a complete backup:

• The world folder with all changes to the map: torn-down walls, built bases, looted houses, vehicles.
• The player data with the characters and their skills - the part whose loss hurts the most.
• servertest.ini with server settings, mods and WorkshopItems.
• SandboxVars.lua with the game rules.

The last two are small but important: a sandbox configuration fine-tuned over weeks and a grown mod list can only be reconstructed with a lot of effort.

When downloading, you quickly notice that the world does not consist of one big file, but of a great many small ones. Project Zomboid saves the map in sections and creates separate files for every explored area. For the backup, that means two things: the process takes longer than the pure amount of data would suggest, and an abort in the middle of the download leaves an incomplete backup that is worthless in an emergency. So always download the world folder completely and check afterwards whether the size matches the state on the server.

Creating a backup

1. Save cleanly. Send a save via RCON or shut the server down via quit - it saves in the process.
2. Connect via WebFTP or SFTP.
3. Download the world folder, player data, servertest.ini and SandboxVars.lua.
4. Name it locally with a date, for example pz-2026-08-09.zip.
5. Start the server again.

The backup is safest with the server stopped - then nothing is guaranteed to be in the middle of being written. If that is not possible, a save beforehand is the minimum.

When to back up?

• Before every mod change. The two-key system of WorkshopItems and Mods is error-prone - see Install mods.
• Before switching the branch to Build 42, see Switch to Build 42. A downgrade of the world is not intended afterwards.
• Before adding a custom map - map stacks change the world permanently.
• Regularly, as soon as players have characters with many hours on them.

Project Zomboid is relentless: a dead character is dead. That is exactly why a backup is worth more here than in most other games - it is the only way to make up for a server error without punishing the players.

Restoring selectively

The advantage of the separate folders: you do not have to reset everything at once.

The procedure: stop the server, rename the affected folder instead of deleting it, upload the backup, start. Check that the folder names match the configured world name - otherwise the server creates a new, empty world.

A note: restoring world and player data separately can lead to inconsistencies, for example characters in bases that no longer exist. For short time intervals, that is not a problem; with days in between, it is more likely to be one.

Keeping several states

A single backup that is overwritten on every run fails you exactly when you need it most. If you only notice after two weeks that a player has been systematically clearing out bases, you will find the same damage in the current backup. The value of a backup lies not in how recent it is, but in the choice:

• A state from today for the obvious case - a crashed server, an accidentally deleted configuration, a failed mod update.
• A weekly state for everything that happens slowly and is noticed late.
• A state before every larger intervention, kept permanently and marked in the file name, for example pz-2026-08-09-before-b42.zip. You do not delete this one along with the usual rotation.

The space required does not speak against several generations: the world folder grows with the explored map, but servertest.ini and SandboxVars.lua are only a few kilobytes in size. Even if you only keep the world in two or three states, you can back up the configuration with every change - it is the part you touch most often and are most likely to break, see servertest.ini explained.

Trying the backup out once

A backup that has never been restored is an assumption, not a safeguard. The test takes twenty minutes and uncovers exactly the errors that otherwise only surface in an emergency - ideally at a time when nobody is playing:

1. Stop the server in the panel.
2. Rename the existing world folder instead of deleting it - that way, you always have a way back.
3. Upload the backup and set the folder name exactly as it was before.
4. Start the server and check whether the expected state is there. Via RCON, a players and a quick look into the game are enough.
5. Afterwards, either stay with the restored state or activate the renamed folder again.

By far the most common mistake is a name mismatch. World folder and configuration files follow the server name - if it does not match, the server starts without an error message with a fresh, empty world. Many take exactly this picture for the actual data loss, even though the old world lies untouched right next to it and is only wrongly named.

And the limit of the procedure: a backup restores a state, it does not resolve an incident. If you have to restore repeatedly, you do not have a backup problem but a moderation problem - roles, bans and the right tools for it are under Admin & server commands. Nor does a backup replace preparing for a branch switch: it allows the way back, but does not make the old world compatible with the new build.

Frequently asked questions