Before stopping a Palworld server, request a world save, check its result, request an orderly shutdown and wait for the game process to exit. Only then make a cold copy or power off the host. Saving, ending the process and creating an independent backup are three different actions.
This procedure is for an existing Windows or Linux dedicated server. You need administrative access inside the game, or an already configured private management connection, plus access to the server's files and service controls. Do not change configuration and restart a busy server just to follow a command example: prepare the management path before its maintenance window.
Identify the process that writes this world#
Record the actual server installation and persistent-data location. A direct installation uses its Pal/Saved tree; an official Pocketpair container can map a host Saved directory there. Use the running service or container definition to trace that mapping. Backing up an unused installation with the same server name does not protect the current game.
Also identify what starts it: systemd, a Windows service, a panel, a container restart policy or a separate watchdog. Pause automatic restarts and updates for this instance during maintenance. Otherwise a successful in-game shutdown may immediately be followed by another process writing the files you are about to copy.
Keep the prior known-good backup available. If shutdown is prompted by suspected corruption, preserve the current files too, so investigation does not depend on a repeatedly overwritten directory.
Ask players to stop changing the world#
Announce the window while there is still time for players to finish. Ask them to stop trading, building and moving items, then disconnect. An administrator performing the save can remain connected without making further gameplay changes. This reduces the gap between the state you intend to retain and the state saved before exit.
Pocketpair requires AdminPassword to be configured before in-game administration. It is separate from the password used to join the server. Authenticate in the game's chat with /AdminPassword followed by your configured password. Keep the real password out of screenshots, shared scripts and public logs.
Enter these commands separately, in order. The English message text is an example you can replace:
/Broadcast Maintenance starting. Please finish actions and disconnect.
/Save
/Shutdown 60 Maintenance shutdown.
After /Save, check the response before entering /Shutdown. Where the deployment exposes save-completion information in its logs, inspect it as well. Do not paste all commands into an unattended batch and let shutdown proceed after an authentication or write error. The countdown is for orderly departure; it is not evidence that a save succeeded or a universal required save duration.
Pocketpair documents /Save for writing world data and /Shutdown for timed shutdown. Treat saving as an explicit operation rather than assuming shutdown includes it. /DoExit is documented as force stop and is unsuitable as the routine replacement for this sequence.
Confirm exit before stopping the host#
Wait for the game process to finish. Check the service or container state and its logs, including whether a supervisor relaunched it. An accepted shutdown request means the request was accepted; it does not mean all writing has ended at that instant.
Do not power off the VPS or close a server window during the countdown. For a container or service with a short stop timeout, request the game-level shutdown first and let it finish before removing or stopping the wrapper. If the process is stuck, retain its logs and, if possible, a diagnostic copy of the current persistent tree before escalating. A copy taken while the process is still writing is not a consistent cold backup. A forced termination may be necessary for an unresponsive process, but it cannot establish that the last gameplay state reached disk.
If your game client has already updated and can no longer join the old server, use the previously prepared management connection. Current Pocketpair documentation marks RCON deprecated and recommends REST. Its separate save and shutdown actions allow this workflow without an in-game session. Configure that access privately in advance; the private REST access guide covers the connection. Opening the administration port to the internet is not needed for maintenance.
Copy the stopped data and check what it contains#
With the writer stopped, archive the whole effective Saved tree, retaining saves and configuration together. Preserve any external launcher, service settings and mod configuration separately. Store the archive outside the live installation, verify it can be opened and keep another copy off the machine. A directory timestamp alone does not show that the intended world is inside it.
Palworld's bIsUseBackupSaveData option creates rolling world-backup history within the save data. It is useful for recovery points, but this is still data on the same storage. It does not protect against deleting the entire directory, losing the volume or copying the wrong installation. Leave enough disk space for both game writes and your independent archives.
If routine save checks fail, use the observation to choose the next action:
| Observation | Check before continuing |
|---|---|
| Administrative command is rejected | Correct instance, configured admin password and current session privileges |
| Save reports a failure | Free space, filesystem errors and whether the service account can write its data |
| Files remain stale after meaningful gameplay and a save request | Effective save location, read-only mounts, write errors and whether another instance was inspected |
| Shutdown is followed by an immediate start | Watchdog, service restart policy or scheduled job |
| Restart loads older progress despite a dated backup | Actual saved content and world identity; retain the copies instead of repeatedly overwriting them |
Verify persistence after a controlled restart#
When the maintenance is complete, start the same instance and join with an established character. Check a specific recent base or inventory change. For recurring maintenance, perform a small reversible change and repeat one save–shutdown–restart cycle before trusting the schedule.
Automated jobs should enforce the same dependencies: a successful save, a completed shutdown, a backup, then a restart. Failed authentication or an unreadable archive should stop the chain and produce a useful error. Replacing these checks with a fixed delay merely makes the failure repeat on schedule.
For a server on your own machine or VPS, Nexardo can bring infrastructure administration into one interface. Define and check the game's save and shutdown order before connecting it to any recurring maintenance process.
