If your Project Zomboid server suddenly asks everyone to create characters and returns to day one, stop it before players establish a second world. First check which profile and data directory it opened. A different startup name, service account or container mount can select fresh data while the original world remains elsewhere.
This guide covers dedicated servers, with 42.21 Stable current on 26 October 2026. Keep a Build 41 world on its compatible installation and branch; changing a path cannot convert its save into Build 42. Earlier Build 42 saves also need their specific compatibility checks: the developers explicitly separated 42.19 saves from 42.20.
Separate the three names before changing anything#
A control panel can put several unrelated names on one screen:
| Setting | What it selects | What to check |
|---|---|---|
PublicName in the active INI | Name shown to players in the browser | Change this for a display-only rename |
Startup -servername | Internal profile used for settings, world and account database | Compare with the last working startup |
| Effective cache/data root | Directory containing the profile's persistent files | Check service user, explicit -cachedir and mounted storage |
The same environment-variable label can mean different things in different Docker images. Pterodactyl's maintained egg uses SERVER_NAME for the internal profile; the Renegade-Master image documents that label as a PublicName override. Read your actual launch command and image documentation rather than guessing from the field's caption.
For a display-only change, edit the existing active profile's INI while stopped:
PublicName=Evening Survivors
Leave its filename, startup profile and persistent mount unchanged. Restart and check the refreshed listing. A successful rename should preserve characters and the world's date.
Preserve both the old data and the accidental fresh run#
Through the existing dedicated console, send save, wait for saving to complete, then send quit. If a launcher owns shutdown, use its equivalent saving procedure. Wait for the game process to exit, and temporarily disable automatic restart while investigating. A restart loop can keep writing into the wrong directory and rotate useful startup backups.
Copy the entire effective persistent root to a separate, dated backup outside the source tree and automatic rotation. Include Server, Saves, db, logs and any local mod data. Record the server build, branch, mod versions, service definition, launch arguments and host-to-container storage mapping. Preserve the suspected original root too if it is different. Two stopped snapshots let you compare without choosing the wrong source irreversibly.
A client folder downloaded during play is not a complete server backup. Likewise, a copy of the game installation alone does not preserve the separate persistent root.
Find the profile the process actually opened#
Read the service definition, scheduled task, panel startup configuration or container entrypoint. Then compare the startup log with the final arguments actually passed to the game. Keep administrator passwords out of screenshots and support posts: launch arguments can contain them.
Record these four values together:
- The account running the game and its effective user-data location.
- Any explicit
-cachediroverride. - The value after
-servername; a default installation often usesservertest. - For containers, the host directory or volume backing that data location.
Inside the resolved root, inspect Server/<profile>.ini and its companion Lua settings, Saves/Multiplayer/<profile>, and the account database under db, typically <profile>.db. Check actual files and timestamps in your installation. Do not use an old forum path missing the Saves component as a universal current directory.
On Linux, compare spelling and case. After moving from an interactive launch to a service, the home/user-data directory can differ even though the installation directory is unchanged. A container can also start normally against a newly created empty volume because the original bind source was omitted.
Use the symptom to choose the next check#
| Observation | Next check | Interpretation |
|---|---|---|
| Fresh settings and day-one world appeared after a rename | Old versus new -servername | A different profile may have been selected |
| Profile name matches, but all data looks new | Cache root, service account and volume mapping | The same name can exist in another root |
| Old buildings exist, but one player gets character creation | Username, Steam/no-Steam identity and player data | This alone does not prove the wrong world loaded |
| Settings edits disappear on startup | Wrapper environment or panel-generated config | Change the controlling configuration source |
| Log rejects a save or reports missing mods | Exact build, active mod IDs and first relevant error | Resolve compatibility before attempting recovery |
File size and modification time are clues, not proof of which world is correct. Compare a known base, container contents, survivor progress and the recorded in-game date on a protected test copy.
Restore the selection before moving save files#
If the original complete root still exists, restore the known working launch profile and mount first. Correct ownership if the new service account cannot read and write its data; grant only the intended account access. Do not run two game processes against that root.
If restoration from backup is necessary, use a separate destination and keep the original archive untouched. Bring back the corresponding settings, world, account database and mod data as one stopped snapshot under the compatible build. Mixing yesterday's world with today's databases is not a reliable rollback. Moving a hosted game to a dedicated service can also involve account identity changes; get that distinction right before renaming or replacing databases.
Once selection is correct, join with an existing regular player account. Check the expected character, base and several saved objects. Save, shut down cleanly, restart through the normal service and join again. Have a second established player verify their character too. A console message saying the server started is only the beginning of this check.
For several machines, keep this profile-and-storage record alongside your operations inventory. Nexardo helps organize administration of your own infrastructure; verify the selected Project Zomboid build and its save compatibility before reopening the world.
Sources#
- The Indie Stone: 42.21 Stable release and 42.20 release and retained branches.
- Pterodactyl's actual Project Zomboid startup configuration, current Build 42 launcher, and Renegade-Master's storage and variable reference.
- Developer explanation of internal profiles and Host-versus-dedicated troubleshooting. These historical discussions explain the distinction; their old paths and network advice are not current setup instructions.
