Restore one complete snapshot into a stopped dedicated server, then check the selected world and existing characters before reopening it. A running process or familiar server name does not show that the intended save loaded.
This guide covers recovery of an existing dedicated-server world on Windows or Linux. Converting a co-op host into a dedicated-server character is a separate identity-migration task; do not apply character-conversion scripts merely because a restored server presents a creation screen.
Identify the actual world before replacing files#
Find the installation and persistent storage used by the running instance. The normal dedicated-server world path is Pal/Saved/SaveGames/0/<WorldID>/, relative to the server installation. Docker may expose that tree through a differently named host directory. Follow the mounted volume, not an unused copy under another Steam library.
Look in Pal/Saved/Config/LinuxServer/GameUserSettings.ini, or the corresponding WindowsServer directory. Its DedicatedServerName selects the world-folder identifier. Record the existing value before changing it. If several worlds exist, compare that selection with the actual files; the directory modified most recently may be a newly generated empty world.
The active folder should contain the world data, including Level.sav, and the Players/ directory. Preserve companion files present in that build as well. LevelMeta.sav and WorldOption.sav are examples, not a universal list of everything worth retaining. World state and character data belong to one recovery point.
Freeze the current state and keep a way back#
Arrange downtime, disconnect players and suspend automatic restart/update jobs for this instance. If it is responsive, an authenticated administrator can request /Save and then a normal shutdown, for example /Shutdown 60 Maintenance. Wait for the process to exit and check its shutdown log. Do not confuse /DoExit, the force-stop command, with completed graceful saving.
Copy the entire stopped Pal/Saved/ tree to a separate directory outside the live save path. Keep startup settings, container environment or service configuration and the server build information with it. Preserve mods when the world depends on them. Copy the archive off the game host and verify that it extracts; a second folder on the same failing disk is a limited fallback.
If the current save is already damaged, retain it anyway. It may contain newer player data, logs or another intact generation needed for diagnosis. Keep automatic rotation from deleting the last known good archive during recovery.
Choose a snapshot that contains the whole world#
Palworld's bIsUseBackupSaveData setting enables native rotating backups below the save directory. Look for dated world snapshots under the active world's backup/world/ tree. Choose a time before the incident, taking the machine's timezone into account. The newest copy can contain the same empty or broken state you are trying to undo.
Inspect the chosen snapshot after copying it to a staging directory. It needs the matching world files and player files, preserving their relative layout. Do not select a local-client backup instead of a world snapshot, or combine a newer Level.sav with an older Players/ directory. If the candidate lacks the required player data, find a complete generation rather than filling gaps from arbitrary dates.
An external archive may contain an outer Saved/ directory, whereas a native world snapshot contains files to place inside <WorldID>/. Inspect the extracted levels before copying anything. Do not create SaveGames/0/<WorldID>/Saved/SaveGames/0/… by blindly extracting into the active folder.
Put the selected state in place while stopped#
Move the current live world aside into the preserved recovery area. Place the chosen snapshot under Pal/Saved/SaveGames/0/<WorldID>/, so its world files and Players/ sit directly inside that folder. Restore the entire selected set instead of merging it with leftovers from the failed world.
Match DedicatedServerName to the intended folder identifier. Edit that setting only while stopped, retaining the file's existing section and unrelated settings. On a different machine, reconcile its effective configuration deliberately; copying a full Saved/ archive can also bring back old ports and passwords.
Confirm that the game service account can read and write the restored tree. For containers, inspect the effective UID/GID and mount destination rather than making all files world-writable. Use a compatible server build and mod set. A backup does not guarantee that an older executable can read a world saved by newer code.
Verify characters and persistence before normal play#
Start with access limited to the recovery check. Confirm the world selection in logs and, if an existing private REST connection is available, compare /info's worldguid with the intended identifier. Then join with an existing account. Check a known base, inventory, Pals and guild membership against the selected recovery date.
If character creation appears unexpectedly, stop before creating replacements. An empty world points first to the selected folder/path; familiar bases with a missing character require checking the complete snapshot and identity context. Neither symptom justifies deleting player files.
After the correct state loads, make a harmless recognizable change, save, shut down normally and restart. Confirm it persists before admitting everyone. If acceptance fails, preserve the attempt separately and return to the retained stopped state or another complete snapshot. For administration on your own VPS, Nexardo helps organize infrastructure management; keep world selection and recovery acceptance explicit in that workflow.
Sources#
- Pocketpair: effective configuration and native backups
- Pocketpair: save and shutdown commands
- Dedicated-server container: world selection and mounted paths, backup implementation and restore implementation
- Save Toolkit: observed world-folder layout
- Save Studio: complete dedicated-server snapshot requirements
