Palworld server backups and world resets

A Palworld server's whole world is one folder: Pal/Saved/SaveGames/0/<WorldID>/. Back that folder up - after a forced save or with the server stopped - together with Pal/Saved/Config/LinuxServer/ and the ban list, and you can rebuild the server from nothing. Restoring is the same copy in reverse with the server stopped. Resetting the world is either deleting that folder (everyone starts over) or pointing the server at a new one (the old world stays on disk). The game's own bIsUseBackupSaveData copies are useful but sit on the same disk as the save, so they are not backups in the sense that matters. The rest of this post is the detail: what each file holds, how to get a consistent copy from a running server, how to restore, and how to reset without throwing away things you wanted to keep.

What is in a Palworld world folder#

The dedicated server keeps each world in its own folder under Pal/Saved/SaveGames/0/, named with a 32-character hex ID. The server loads the one named in GameUserSettings.ini as DedicatedServerName.

Outside the world folder there are three more things worth keeping:

• Pal/Saved/Config/LinuxServer/PalWorldSettings.ini - all your game settings. (WindowsServer instead of LinuxServer on Windows.)
• Pal/Saved/Config/LinuxServer/GameUserSettings.ini - which world to load.
• Pal/Saved/SaveGames/banlist.txt - the server's ban list, if you have banned anyone.

Level.sav is the important one and the fragile one. It is a single compressed file that holds almost everything, which makes the world easy to copy and makes corruption total: there is no recovering half of a damaged Level.sav. That one property drives every recommendation below. Palworld server memory explains why the same file grows over a server's life.

Getting a consistent copy#

Palworld writes the world on a timer set by AutoSaveSpan in PalWorldSettings.ini. Between saves, recent changes exist only in memory. A copy taken while the server is running is the state at the last save, and a copy taken during a save can catch a half-written file. Two ways to get a good one:

Stop the server, then copy. The simplest and safest. A clean stop writes the world before exit, so the files on disk are complete and current. For a nightly backup at an hour nobody plays, this is the right method.

Force a save, wait, then copy. When you cannot stop the server, issue a save first and give it time to finish. In game or over RCON the command is Save; over the REST API it is a POST to /v1/api/save:

$ curl -X POST -u admin:YOUR_ADMIN_PASSWORD http://203.0.113.10:8212/v1/api/save

The REST API needs RESTAPIEnabled=True and listens on RESTAPIPort, 8212 by default; the username is admin and the password is your AdminPassword. On a large world the save takes several seconds, so wait at least thirty before the copy starts. Palworld admin commands and RCON covers both interfaces.

The built-in backups: what bIsUseBackupSaveData does#

bIsUseBackupSaveData=True in PalWorldSettings.ini makes the server keep rolling copies of the world in the backup folder inside the world folder, with timestamped subfolders. How many it keeps and how often it makes them has changed between game versions, so look in the folder on your own server rather than relying on a number from a guide.

These copies are worth having on. They are the quickest way to undo a corrupt save or a bad evening - a griefer, an accidental release of a whole palbox, a base lost to a raid nobody wanted - because the file is already on the server and restoring is a copy within one folder.

They are not a backup, for the reasons backups that actually restore goes through in general:

• They live on the same disk as the thing they protect. A failed disk, a deleted server or a mistake with the file manager takes them too.
• They rotate. A problem you notice after a few days may already have been copied over every one of them.
• They are as old as the rotation, which may be minutes, not the day before an update when you actually want to go back.

Use them as the first line of defence and keep real backups somewhere else.

A backup routine that holds up#

A sensible routine for a group server:

1. A daily backup at an hour nobody plays. Stop or save first, then back up the world folder, the config folder and the ban list.
2. A manual backup before every game update. Palworld updates have changed the save format more than once. If an update goes wrong, you want the save from before it, with a server version that can still read it.
3. A manual backup before any big change - new mods, a settings overhaul, a host save fix, a world move.
4. Keep at least a week. Problems are not always noticed the same day.
5. Restore one occasionally. On a spare server, or locally. A backup nobody has restored is a hypothesis.

On a panel, this is a schedule rather than a chore. On RE:NODE, the Schedules tab takes a cron expression and runs ordered tasks with delays - a console command, a backup, a power action - so the daily routine can be "broadcast a warning, wait, Save, wait, back up, restart". Backups are stored off the machine they protect, restore with one button, can be downloaded, and can be locked so rotation never deletes the one taken before a big update. Scheduled tasks worth having has more examples.

Schedule: nightly backup and restart       cron: 0 5 * * *  1. command   Broadcast Restart_in_5_minutes  2. wait      240 s  3. command   Save  4. wait      60 s  5. backup  6. power     restart

Older builds of the dedicated server treated spaces in Broadcast messages badly, which is why underscores are common in examples. Current builds handle spaces better; test on yours.

Restoring a world#

Whether the copy comes from your own backup or from the game's backup folder, the procedure is the same.

1. Stop the server. Not restart - stop, and wait until it is fully down.
2. Move the current world folder aside instead of deleting it. Rename it to <WorldID>.broken or download it. If the restore turns out to be the wrong one, you still have what you started with.
3. Put the backup in place as Pal/Saved/SaveGames/0/<WorldID>/, with the same folder name DedicatedServerName points to.
4. From the game's own backups, copy the contents of the timestamped subfolder (Level.sav and the rest) into the world folder over the current files.
5. Start the server and check the console. Then join and look at something recent you remember, to confirm you are where you think you are.

If a restore loads but players are missing their characters, their Players/*.sav files did not come with it; restore the whole folder rather than Level.sav alone. If the server generates a new world, the folder name or DedicatedServerName does not match.

Resetting the world completely#

Every long-running server eventually wants a fresh start - the world is explored, the save is huge, the group is bored, or a new update added a region you want to experience from the beginning. There are two clean ways to reset.

Delete the world. Stop the server, back up the world folder (you will want it later, if only for nostalgia), delete it, and start. With DedicatedServerName pointing at a folder that no longer exists, or emptied, the server creates a new world with a new ID. Check GameUserSettings.ini after the first start; the server writes the new ID there.

Keep the old world and switch. Stop the server, clear DedicatedServerName or set it to something that does not exist, and start. A new world is generated and the old one sits untouched in its folder. To switch back later, put its ID back. This is the better option on a server with enough disk, because it makes a reset reversible for as long as you keep the folder.

What a full reset keeps and loses:

There is no supported way to carry characters into a new world. Character level, inventory and pals live in Level.sav, not only in the per-player files, so copying Players/ into a new world does not bring anyone's progress along. Tell players that before the reset, not after.

Partial resets#

Sometimes the problem is one guild, one player or one abandoned base, not the world. Palworld's tools for partial resets are limited, so pick the right one.

• Abandoned guilds. AutoResetGuildNoOnlinePlayers=True with AutoResetGuildTimeNoOnlinePlayers in hours makes the server delete the bases of guilds with nobody online for that long. It is the cleanest way to keep a public server's save from filling with bases nobody will return to. Choose a generous time - a week rather than three days - and announce it.
• One player starting over. Deleting that player's Players/<id>.sav with the server stopped resets them to character creation. Their guild's bases remain; items and pals that belonged to them may be left in odd states. Back up first.
• Clearing ground clutter. Lower DropItemMaxNum and DropItemAliveMaxHours so dropped items expire sooner. It does not reset anything, but it removes one source of slow decline.
• A soft reset of one area. Not possible with vanilla tools. Save editors exist, but editing Level.sav by hand is the fastest way to corrupt it; do it only on a copy and only if you have a tested backup.

Planning resets on a public server#

On a server with a regular community, a reset is an event rather than an accident. A few things make it go well:

• Announce it at least a week ahead, with the date and time, and post it where people will see it. Announcing maintenance and downtime covers the wording.
• Tie resets to big updates when you can. A major content update is the moment most players want a fresh start anyway.
• Keep the old world folder for a while after a reset, for appeals ("I had a legendary pal in my palbox") and for the inevitable "can we go back".
• Change settings at the reset, not between resets. Rate changes on a live world make earlier progress look cheap or wasted; a reset is the clean point to adjust.

Troubleshooting#

The restore loaded the wrong world. DedicatedServerName points at a different folder. Check GameUserSettings.ini and the folder name.

Restored, and the world is back to how it was before the restore. The server was running when you copied the files, and its next save overwrote them. Stop, restore again, then start.

The server will not load the backup after an update. The save format changed and the backup predates it, or the server is older than the save. Match the server version to the save.

Backups are huge. Level.sav has grown and the game's backup folder holds several copies of it. Exclude backup/ from your own backups if space is tight; your backups replace it.

A reset kept the old world. The server loaded it because DedicatedServerName still names its folder. Clear the value or move the folder.

Players lost characters after a restore but bases are there. Only Level.sav was restored. Restore the Players folder from the same backup.

FAQ#

Where are Palworld server save files?

In Pal/Saved/SaveGames/0/<WorldID>/ inside the server install, one folder per world. Level.sav in that folder is the world itself; Players/ holds one file per character.

Does Palworld back up automatically?

With bIsUseBackupSaveData=True, the server keeps rolling copies in a backup folder inside the world folder. They protect against a bad save but sit on the same disk, so keep separate backups too.

Can I reset the world but keep everyone's characters?

Not with supported tools. Character progress is stored in Level.sav along with the world. A new world means everyone starts at level one.

How do I reset just one player?

Stop the server and delete that player's file from Players/. They will create a new character on next join. Back up first, because their items and pals can end up in an inconsistent state.

How often should I back up a Palworld server?

Daily at a quiet hour, plus before every game update and every major change. Keep at least a week of backups, because problems are not always noticed the same day.