Match this symptom
A Palworld update is available, but the server contains an irreplaceable shared world, or players see a dedicated server version mismatch after an update.
The answer first
Save the running world, stop the server cleanly, copy the complete save tree somewhere outside the install folder, update the server files, and verify the same world before inviting players back. Never use reinstall as the first update step.
Before the update
- 1Tell connected players about the maintenance window and stop new building or inventory changes.
- 2Use the documented /Save server command, then use /Shutdown with a countdown or stop the service cleanly after players disconnect.
- 3Confirm the process has exited. Copy the complete Palworld save directory, including the world and player data, to storage outside the server install directory.
- 4Record the current server version, launch arguments, configuration file and mod state. A backup without the configuration can restore a world but still leave a mismatched server.
Update only the server files
Use the same deployment method that installed the server, such as SteamCMD or the server manager's update action. An update should refresh application files while preserving the save tree. If the tool proposes deleting the install directory, cancel and verify its behavior first.
- Keep the external backup disconnected from the update operation.
- Do not copy an empty new save folder over the backup.
- Update every player client to a compatible version before the group reconnects.
- Temporarily disable or verify mods when a patch changes the server API or loader.
Verify before reopening
- 1Start the server and confirm the expected server name, world and player count.
- 2Join with one test account. Check the base, storage, party and recent progression before allowing the group back.
- 3Stop the server and inspect timestamps if the wrong world appears. Restore by replacement only while the process is stopped.
- 4Keep the pre-update backup until the group has completed at least one normal session and a fresh post-update backup exists.
If the server creates a new world
Stop immediately. A new world usually means the process is reading a different save path or world identifier; continuing to play only makes the diagnosis harder. Compare the current configuration and launch identity with the recorded pre-update values before restoring anything.
Separate a binary update from a data migration
Compare the pre- and post-update app build, active configuration path, save-directory timestamps, and first startup log. Official binaries may update while the world remains untouched, yet a changed service account, working directory, or launch option can point the new process at another save location. Identify which files the first post-update save actually writes before copying anything back.
If the updated build changes save data, keep the untouched pre-update snapshot and treat the first successful load as a one-way test until Pocketpair documents compatibility. A rollback requires a compatible available server build plus its matching configuration, mod state, and complete save set; restoring only old binaries over an already-upgraded production world is not a verified recovery plan.