Palworld Save Location, Backup and Restore Guide

Corrupted saves are not a rare event in Palworld. The server getting OOM-killed, 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's the crux of the migration section below.

Inside:

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 issue a Save over RCON 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.

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. If it differs from the current one, see the next section
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

Migration adds one problem restores don't have: a new machine generates its own <WorldID> on first start, and it won't match the one in your backup.

Which world directory the server loads is decided here:

Pal/Saved/Config/LinuxServer/GameUserSettings.ini

The DedicatedServerName= value is the directory name it looks for under SaveGames/0/. So there are two ways to migrate — pick one:

• Change the config: set DedicatedServerName= to your backup's directory name
• Change the directory: rename your backup directory to the one the new machine generated

Either works. Don't do both — then they don't match, the server decides there is no save, generates a fresh world, and your old one sits untouched right next to it. It looks exactly like a lost save when it's really just an unfound one.

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/; change one side or the other.

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.

keepworlds.com/consoleRunning

BackupsBack Up Now

Taken	Size	Type	Actions
2 hours ago	412.6 MB	Auto	Restore
4 hours ago	410.2 MB	Auto	Restore
6 hours ago	398.1 MB	Manual	Restore

Only the 3 most recent backups are listed.

A dedicated Palworld server from KeepWorlds 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.