Palworld Save Location, Backup and Restore

Corrupted saves are not a rare event in Palworld. The server getting killed for running out of memory (what memory does over uptime), the machine losing power, or a crash landing mid-write can all leave a world that ran for months unable to load. And the game ships no rollback of its own — a broken save is just broken.

That makes backups matter more here than in most games. This covers where the save lives, what a complete backup contains, and the right order to restore in.

Where the save actually is

From the server install directory (~/palworld if you followed the setup guide):

Pal/Saved/SaveGames/0/<WorldID>/

<WorldID> is a 32-character hex string generated the first time the server starts. That directory name is not decoration — it decides which world the server loads, which is step 4 of restoring below. Every player's computer also files their map progress (explored areas, fast travel points) under that same ID.

Inside:

Solo and co-op worlds

Everything above is the dedicated server's copy. A world you play alone, host from your own game, or join by invite code is saved on the host's PC instead. On the Steam version for Windows, press Win+R, paste %LOCALAPPDATA%\Pal\Saved\SaveGames and hit Enter: inside is a numeric folder named after your Steam ID, and one level further in, each folder is a world holding Level.sav and a Players/ directory. Xbox and Game Pass copies store saves in a different container format, so this path doesn't apply to them.

The backup rules below hold here too: quit the game first, then copy the whole world folder. Moving that world onto a dedicated server takes one extra fix to the host's character, which the co-op to dedicated server save converter does in your browser.

What a complete backup contains

The whole <WorldID>/ directory. Every file in it.

This is the core of the article, because the usual failure isn't skipping backups — it's taking incomplete ones. Plenty of guides mention only Level.sav, so plenty of people's backups contain exactly that one file.

Restoring from a Level.sav-only backup doesn't leave you slightly short. Everyone comes back as a brand new character. The world is there, the bases are there, the Pals are there — but those bases belong to player UIDs that no longer exist, and nobody can get their character back. Levels, stats, inventory, all gone, while the world looks perfectly intact. A half backup is worse than none, because you thought you were covered.

Copy Players/ too.

Backing up while the server is running

You get a half-written save.

The server autosaves on a timer, Level.sav is a few hundred MB, and that write is not atomic. Copy at the wrong moment and you get the first half of the new file and the second half of the old one. Most of the time that won't load; occasionally it loads into a world that is subtly wrong.

There's only one correct sequence:

# 1. Stop the server
# 2. Copy the entire <WorldID>/ directory
# 3. Start the server

Thirty seconds of downtime for a backup you can actually trust is a trade that settles itself the day a save breaks.

If you truly can't take the downtime, the fallback is to force a save through the official REST API (POST /v1/api/save — enabling and authenticating is in the REST API guide) and copy immediately after it completes — but that only lowers the odds of catching a write, it doesn't remove them. Don't treat it as equivalent to stopping the server. The old advice to send Save over RCON is out of date; RCON is deprecated.

What the server's own backups are

bIsUseBackupSaveData in PalWorldSettings.ini defaults to True, and with it on the server keeps a set of timestamped copies of the save inside the world directory. Two things it's good for and one thing not to count on:

• If a save gets corrupted during an autosave, the most recent copy is a faster way back than digging out your own backup
• Don't turn it off to save RAM; all that does is remove a way back on the day it crashes
• It lives on the same disk, on the same machine, as the server. A dead disk or a lost machine takes it too. A real backup has to be copied elsewhere

Restoring

Do it in this order, because getting it wrong costs you the player data:

1. Stop the server. Swap files under a running server and the copy in its memory overwrites yours at the next autosave
2. Copy the current save out first, even the one you believe is broken. Restores can go wrong too, and that's your only way back
3. Replace the existing <WorldID>/ directory with the one from your backup
4. Check the directory name. The server loads the directory named by DedicatedServerName= in Pal/Saved/Config/LinuxServer/GameUserSettings.ini (WindowsServer on Windows). If your backup's directory name differs, change that value to match it — don't rename the directory. The name is the world ID players' map progress is filed under, so renaming it still loads the world but leaves everyone with a blank map. Change both and they stop matching, and the server generates a fresh world next to yours
5. Start the server and confirm both bases and characters are there

Step 2 is the one people skip and the one they regret.

Moving a world to another machine

A move is the same complete copy with one guaranteed catch: a new machine generates its own <WorldID> on first start, so the directory-name check in step 4 always applies. Matching versions, the settings that don't live in the save, and what your players have to re-enter are in moving a Palworld server to another host. If the world you're moving came from co-op rather than a dedicated server, the host's character needs one extra fix first — the co-op to dedicated server save converter does it in your browser.

Common questions

Is backing up Level.sav enough?

No. Players/ holds each player's character data; without it, everyone comes back as a new character after a restore. Copy the whole <WorldID>/ directory.

Can I copy the save without stopping the server?

Not safely. The autosave write isn't atomic, and copying mid-write gets you half a file. Thirty seconds of downtime for a backup you can trust is worth it.

After restoring, the server made a brand-new world. Is the old save gone?

Almost certainly not — the directory name just doesn't match. DedicatedServerName= in GameUserSettings.ini has to equal the directory name under SaveGames/0/; point it at your old save's directory rather than renaming the directory.

Why this is the part people skip

Backups sit behind everything you'd rather do today, by their nature: no immediate payoff, all of the value on a day you can't see coming.

The real problem isn't laziness, it's that it depends on you remembering. A routine that needs a weekly manual run, a server stop, and a few hundred MB copied is a routine that gets run three times. And save corruption has a habit of arriving months in, long after the backups quietly stopped.

With Palworld server hosting from KeepWorlds, the server backs up on a schedule and keeps the last several copies — the whole world directory, Players/ included — so restoring is picking one from a list. If you want to know which settings drive world size, see every option explained.