Palworld Backup: Can Your World Be Saved?

A Palworld backup only counts as a verified recovery path once an isolated copy starts, the right players load their existing characters, and the world, guild, Pals and game rules match the chosen backup state. After that, saving followed by a restart has to work. A successful download message or a visible base is not enough.

This guide walks you through a provider-neutral restore test: for self-hosted dedicated servers, rented servers and groups who want to assess their backups independently of their provider. You don't need a SupremeTier account for this. The active world stays untouched during the test. We work with an existing archive and a separate test target.

Sources checked as of: October 29, 2026. The official server documentation we retrieved shows documentation version 1.0.4; this is not a statement about your installed server version. The procedure below is an editorially developed test plan. It does not report on an actual world rescue or on our own Palworld server test.

Missing data: preserve the current state

You log in and end up in character creation even though your base is still standing? Then don't create a new character for now while you diagnose this. End the connection attempt and note which account, which platform and which server address you were connected with. Save error messages and existing archives before someone accidentally overwrites the supposedly wrong state.

During an acute incident, further saves can push out the last good state. The responsible admins should therefore decide how to halt and preserve the affected server in a controlled way. This guide does not grant anyone access to other people's servers. For the following exercise you don't need to touch the active instance: use an existing, separately stored copy.

Avoid the knee-jerk combination of deleting the world, restarting and then dropping individual files into it. That quickly turns a single error pattern into a mix of several states. A cleanly documented failed attempt on a throwaway copy tells you more than five undocumented repair attempts on your only data.

What exactly should your backup recover?

Define the desired state before you unpack anything. “The world is back” can mean that the landscape loads. For your group, recovery probably means more: your own characters have their progress, the right guild owns the bases, important Pals are where you expect them, and the rules match your game night.

Write down a short target state. It has to refer to the point in time of the backup. A Pal you only caught afterwards must not be counted as a restore error. Conversely, a particularly recent build can reveal that you are accidentally checking the active world or a later state.

A useful reference includes, for example, a known base and its location, two named structures, a chest with selected items, the progress of a regular member and that of a guild leader. Add specific Pals with recognizable traits. These are your comparison points, not an invitation to publicly document private player names or account IDs.

Example, explicitly fictional: Your group makes a backup on Tuesday before a rebuild. The checklist includes the old workshop, the guild membership of two testers and three particularly important Pals. The new roof structure from Wednesday must be missing from this backup. Only this time reference makes the observation meaningful.

Three outcomes instead of a premature green checkmark

• Passed: All mandatory points defined in advance are confirmed, including reconnecting after saving and restarting. The result applies to exactly this archive, this environment and the accounts tested.
• Failed: At least one mandatory point demonstrably deviates, such as a missing character, a wrong guild or a save state that wasn't retained.
• Not tested: A required piece of evidence is missing, for instance because a member couldn't take part. That is not a passed point and not yet proof of a damaged backup.

A partial test can be valuable. Still, label it as a partial test.

“World and two of five characters checked” is more honest and more helpful than “backup works”.

Which data belongs together

The official documentation describes the server configuration separately from launch arguments and admin commands. For a restore test, this separation is crucial: a world archive doesn't automatically describe how the server was started or which settings a hosting panel writes at startup.

Use the following structure as a guide for a typical dedicated server. It is not a universal file manifest for every platform and version. Determine the actual paths from your installation and the exported archive; we do not claim that the exact mapping of individual game progress to internal files is an officially fully documented format.

server-directory/
  Pal/Saved/
    SaveGames/                  ← entire relevant save data
    Config/
      WindowsServer/            ← for Windows dedicated servers
      LinuxServer/              ← for Linux dedicated servers
        PalWorldSettings.ini    ← example: effective configuration
  Mods/                         ← if your installation uses mods
  Startup and operation notes   ← document separately

In many dedicated server backups you will find names like Level.sav, LevelMeta.sav and a Players folder inside a world directory. Use these names for orientation, not as license to weed things out: “I have Level.sav, so everything is included” is not a reliable completeness check. Keep the entire associated save set and its directory structure.

The official configuration page lists Pal/Saved/Config/WindowsServer/PalWorldSettings.ini and Pal/Saved/Config/LinuxServer/PalWorldSettings.ini respectively. Changes to DefaultPalWorldSettings.ini alone do not change the effective settings. Source: Pocketpair – Configuration.

What belongs in your inventory list

Credentials belong in protected storage, not in the shared, published checklist. An archive with configuration files may contain passwords. Only share it with the people who need it for the restore.

What kind of backup do you actually have?

In-game backup generations

Pocketpair documents bIsUseBackupSaveData as the switch for world backups and a backup folder in the save directory. That does not guarantee that your provider's archives include this folder, that settings are included or that an independent external copy exists. Check what is actually there. Source: Pocketpair – World backups.

Export from a hosting panel

A panel can report “Backup successful” and still only back up a defined part of the server. Read the displayed scope and any exclusions. Ask specifically for an exportable archive and a separate restore target. A menu item called “Restore” doesn't tell you whether it only overwrites the active instance.

Also check whether you can reuse the backup without access to the same panel account. An easy-to-find entry inside an account you can't reach won't help you in that moment. A separately stored copy and documented access responsibilities reduce this dependency.

File copy, snapshot or your own backup job

A file copy taken while writes are in progress can contain files from different moments. Even a technically consistent file system snapshot is not automatically a provably consistent save state. So record how the existing backup was created: controlled shutdown, documented backup mechanism or unknown.

An unknown origin is something to look into, not an automatic death sentence. Assess it through the isolated test. For future backups, you should agree on a documented consistent process instead of spontaneously halting the active world based on this guide.

Preparation and the way back

Set up three separate areas: original archive, working copy and test results. The original is never opened by the game. Only unpack a copy into a new, empty folder. Store logs and later test states separately so the application can neither overwrite the original nor convert it to a new format.

Give the backup a unique identifier. Note the file size, timestamps with time zone, origin and – if available – the logged completion of the backup job. Don't confuse the download time with the backup time. An archive downloaded today may contain last week's state.

A checksum helps you recognize identical files. It proves neither complete content nor a healthy save state. The following commands only read the specified file; replace the example path with your locally exported archive.

# macOS, example path; does not perform a restore
shasum -a 256 '/pfad/zur/palworld-sicherung.zip'

# Windows PowerShell, example path
Get-FileHash -Algorithm SHA256 -LiteralPath 'D:\Backups\palworld-sicherung.zip'

Compare the hash values after a transfer. Also check with your archive tool whether the entire archive can be unpacked without errors. A matching hash only proves that the same bytes are present; an archive that was already damaged stays damaged after an error-free transfer.

The way back is fixed before the test begins

For the exercise, the way back is: shut down the test instance properly, keep the test results, don't reuse the working copy you used and, if needed, create a fresh copy from the unchanged original. Nobody copies test progress back into the active world.

To that end, note the path of the original archive, its hash, the test target path and the person who ends the attempt. A second person should be able to tell from this information which data is protected. If that isn't clear, don't start the test yet.

Isolate the test environment

“We'll call the server TEST” is not enough. The separation has to apply to files, network and automation. The test instance needs its own storage location without any shared mounted live directories. For containers, check the volumes that are actually mounted; for hosting panels, check the target instance and the storage behind the file manager.

A different port doesn't protect you from a shared save directory either. Conversely, a cleanly separated directory can still collide with live ports. Document both. Keep the test instance out of any public listing and restrict access to the agreed testers, for example with firewall rules and a separate test password.

Pocketpair distinguishes the listener port set via -port from the public port setting. PublicPort or -publicport alone do not change the actual listener. If you start a second instance, you need to check the actual port bindings, including any additionally enabled admin services. Source: Pocketpair – Launch arguments.

Four questions that must be answered with yes before starting

1. Is it ruled out that the test process writes to the active world or the original archive?
2. Is it clear which address and instance the testers will use?
3. Are automatic updates, restart jobs, synchronization and backup rotation on the test target understood and configured so they don't silently alter the attempt?
4. Can the responsible person shut down the test instance properly without touching other instances?

If your provider doesn't allow a separate restore, you can start by checking the archive and settings. For the in-game test you then need a permitted separate target. That doesn't have to be a new paid server: a suitable environment of your own can be enough. Without sufficient resources or permitted access, this part explicitly remains open.

The restore test step by step

Step 1: Define the test scope

Choose exactly one archive and one target point in time. Write down which characters and guilds will be checked and which content is essential. Testing only the admin does not automatically test the rest of the group's characters. For a complete group sign-off, all affected characters must be checked; for large groups, a limited sample must be labeled as such.

Also define which deviations are allowed in the test. A different server name, a test password and separate ports make sense. A different XP rate or different death penalty, on the other hand, are not mere technical deviations. Keep allowed differences as a short list so they don't later disappear under “it'll be fine”.

Step 2: Keep the environment as similar as possible

Start with a server environment that matches the backup state and is verifiably available. Document the server and client version, operating system and extensions used. “Latest version” is no substitute for a specific version number. Also, an earlier build is not necessarily available through every distribution channel.

Don't combine the first restore test with an operating system change, a platform change and a mod update. Otherwise a failure can hardly be attributed to a single difference. If an identical environment can't be set up, describe the attempt as a restore under changed conditions. It may succeed, but it doesn't prove the same thing.

Step 3: Only populate the stopped test instance

Check the target identifier again before copying. The test instance must be shut down; if the situation is unclear, a panel status alone should be confirmed through the available process or operational status. Don't remove or replace any live data. If a fresh test server created its own files first, store them separately and avoid an uncontrolled mix with the archive.

Provide the complete associated save set from a single backup state. If the archive keeps several generations, choose one in a traceable way. Don't mix a seemingly matching world file with player files from a different day. Identical file names don't prove that their internal relationships match either.

Transfer the required configuration and the documented startup conditions. Keep in mind that a panel may generate settings from its interface. So after the first test start, check again which values are actually being used. Store allowed test deviations separately from the original instead of rewriting its configuration.

Step 4: Watch the startup, don't repair anything yet

Start the test instance once and save the startup log. Watch for loading errors, repeated crashes, missing dependencies and the actual data path. A “Server running” message is only the beginning. The right world, character assignment and saving are still open.

If a new empty world is created, end the attempt and check the path, directory level and selected world ID. A common structural issue is an extra nested archive folder. But that doesn't mean renaming is a universal fix: first determine which path this installation actually loads.

Step 5: Connect with the existing accounts

The testers initially use the same accounts and platforms as in the backed-up state. The question is: “Does my existing character load?” Not: “Can any user join?” A new test account can check reachability, but it can't provide evidence of an existing character.

If character creation appears unexpectedly, abort for that person. Document the result without immediately creating a new character, switching guilds or renaming player files. A changed account, a different platform, the wrong world state and missing data are different hypotheses; investigate them one after another.

Step 6: Sign off world, characters, guild and Pals separately

First go to your reference locations. Then check personal progression: expected level, selected unlocks, equipment and inventory. You don't have to count every item if your sign-off requires less. What matters is that a deliberate sample isn't later presented as a complete inventory audit.

Next, check the guild name or internal assignment, membership, roles and usability of the intended bases. A visible base that nobody has the expected permissions for has not been successfully restored for the group. Don't rebuild it for the test and don't hastily join a newly created guild; that would hide the original deviation.

Check Pals in the various places you use: party, Palbox and base assignment. Compare important traits rather than just a total count. If you use other storage or transfer features, add them as a separate check. A server-side world backup is not presented here as a guarantee for arbitrary platform- or account-bound transfer data.

Step 7: Check rules and write capability

Compare relevant game rules with the target sheet and the effective configuration. Choose harmless observations. Don't deliberately get a character killed or lose rare Pals just to demonstrate a setting. Some rules can initially be confirmed for the sign-off through the configuration and startup log; state it when a behavioral check is missing.

Now make a small, recognizable change on the test copy only, for example an uncritical item in a documented test chest. Note the before and after. Don't use an item whose loss would make the comparison messy. This is your first check of whether the restored state can also continue to be written.

Step 8: Save, shut down properly, restart

For authorized admins, Pocketpair documents /Save for saving the world and /Shutdown [Seconds] [MessageText] for shutting down. The commands are run in-game after logging in as admin. /DoExit is described as a forced shutdown and is therefore no substitute for the normal procedure of this test. Source: Pocketpair – Admin commands.

Use the controlled method intended for your test instance. Check the response and that the process has actually ended. Start the same test instance again, reconnect and check both the reference points and your small test change. Only now do you have evidence covering loading and saving again.

Checklist to fill in

Copy the table into your notes or print it out. Enter specific observations, not blanket checkmarks. “Not tested” stays visible and prevents an overall “passed” verdict as long as a mandatory point is open.

Add the test date, responsible person, available logs and the limits of the test. For every deviation, state the expected and observed state. If the archive can't be dated with certainty, write exactly that; a time guessed after the fact is not reliable evidence.

Error patterns: narrow things down instead of throwing files together

The world is there, but my character is missing

First check the test address, account, platform and world ID. Then check the completeness of the save set and whether the backup generation matches. Set up a new attempt from a fresh working copy for each hypothesis. A restart without a documented change usually yields no new information.

File names alone are not a reliable guide to mapping accounts. Don't blindly rename player files after a visible Steam ID. Specialized tools for editing internal IDs can alter relationships; they belong in a separately documented repair attempt and are not part of this safe standard procedure.

Characters are there, but the guild or Pals don't match

Compare the actual backup time and all components of the archive. Distinguish between “not visible”, “not accessible” and “demonstrably not included”. Check whether only one person is affected or several. This distinction helps separate an assignment problem from a wrong generation.

Don't try to artificially turn the sign-off green with new guild invitations or by replacing missing Pals. Such a repair may be wanted later, but it changes the conclusion: you then have a partially reconstructed state, not an unchanged restore of the tested backup.

After the second start, everything is different again

Check write permissions, free storage, the data path that was started, and any restore and synchronization automation. Determine whether the server really saved or was aborted during shutdown. Save the logs of the first and second start; a single screenshot of the running instance isn't enough for a diagnosis.

If your test change is missing, the initial result is “save persistence not proven”. Only a concrete finding justifies a cause such as missing write permissions. Keep this distinction in wording when talking to your provider, too.

The server no longer starts with mods

Note mod versions, dependencies and the original server platform. Pocketpair warns of crashes and corrupted saves caused by mods; the current documentation also describes a separate mod configuration outside the save folders. Source: Pocketpair – Server mods.

Starting without mods can help narrow things down, but it doesn't prove that a mod-dependent world can be restored. Use another throwaway copy for this and don't overwrite the previous test. Don't update all extensions at once and then declare a successful start proof of unchanged content.

The archive can't be fully unpacked

End the in-game test right here. Check the available file size, download completion and, if applicable, the hash of an independently existing copy. Downloading again can fix a transfer error; it doesn't automatically repair a damaged source archive. Keep the problematic file separately for diagnosis.

What a passed test proves – and what it doesn't

A passed test shows that the tested backup was able to restore the agreed content under the documented conditions. It does not guarantee that every older generation is healthy, that all untested characters work or that a future update will load the same state without errors.

Repeat the test after significant changes to the backup process and, with reasonable lead time, before a planned risky migration. Choose the frequency based on the value of your progress and your available resources. A general guarantee in minutes or a blanket optimal interval would not be credible here.

In a real test, measure separately: obtaining the archive, unpacking, setting up the environment, starting the world and checking together. That way you can see whether most of the time goes into the download or into missing access. Only enter times you observed yourself. An advertised fast restore is not a measurement of your large world.

From the test to a real restore

A passed attempt is a basis for decisions, not an automatic order to roll back the active world. Before a real intervention, agree on timing, responsible people, the accepted loss of playtime and the way back. Tell everyone involved which backup state will become authoritative.

Before the actual rollback, keep a separate copy of the current state, including configuration and operation notes. Describe exactly how this preserved state can be put back in place if the real restore fails. Without a usable way back, the successful test copy must not lull you into a false sense of security.

The real intervention then needs its own sign-off. Use the checklist again and pay particular attention to characters, guild and save persistence. Meanwhile, the group shouldn't already be making new progress in an uncoordinated way. A mix of a test world that was played on and an older live state is no safe substitute for a planned switchover.

Terms that help with recovery

Backup state: The state an archive actually represents. It is not the same as the time it was downloaded.

Restore test: Loading a backup in a controlled way in a separate environment, including specific functional checks.

Consistency: The associated components describe a mutually compatible state. The fact that each individual file can be opened doesn't yet prove this relationship.

Checksum: A fingerprint of file contents. Identical SHA-256 values are strong proof of identity for the compared files, but say nothing about whether they are playable.

Way back: The predefined option to end an attempt or, before a real intervention, to return to the preserved starting state.

Accepted data loss: The progress between the backup state and the incident that a group knowingly accepts when rolling back. In operations planning, this is often described as a recovery point or RPO.

FAQ

Is it enough if the panel shows the backup as successful?

No. The message initially only confirms that the backup job defined there has completed. Which files are included and whether your characters and world come back playable is something you have to check separately. Download, archive check and in-game test each provide different evidence.

Do I have to overwrite my active server for the test?

No. This procedure requires a separate instance with its own storage location. If your panel only has a restore function for the active world, don't use it for an exercise. Without a separate target, the in-game test remains open.

Can I just add the missing character from another backup?

That is a targeted repair with possible dependencies on world and guild data. For the first reliable test, use a single coherent backup state. A later single-file repair attempt needs its own copies, a traceable mapping and a new complete sign-off of the affected relationships.

Does a PC backup automatically work on another platform?

A successful restore in the same environment does not imply automatic transferability across platforms. A platform or account change can have different requirements for files and identity. Treat a migration as a separate project and check the support currently documented for it.

How can I tell whether the right state was really loaded?

Compare known changes before and after the backup time. Use at least one world reference and one personal progress reference. Server name and file date alone can mislead you; concrete in-game references are more meaningful.

Is a backup in the same server directory sufficient?

It can help with a single save error. It does not provide an independent copy against the loss of the entire storage or lost access to the instance. Keep at least one required restore state outside the active storage and check whether you can actually retrieve it again.

What if no test member has time?

Check the archive, contents, configuration and preparation in advance. Mark character login as not tested and schedule the missing part separately. An admin start doesn't replace testing with the existing accounts.

What is the most important statement at the end?

Not “We have backups”, but: “We tested this backup in this environment. These characters and this content work, including after a restart. These points are still open. The original and our way back are preserved.” That way your group knows what it can actually rely on.

Sources and review status

Review status: The information on configuration, launch parameters, admin commands and mods comes from Pocketpair's official Palworld server documentation, read on October 29, 2026 (documentation version 1.0.4). The test procedure is an editorially developed plan; we did not perform a restore on a real game world for it. In detail:

• Effective configuration file, world backups via bIsUseBackupSaveData and the backup folder: Pocketpair – Configuration.
• Launch parameters -port and -publicport: Pocketpair – Launch arguments.
• /Save, /Shutdown and /DoExit: Pocketpair – Admin commands.
• Server mods, separate mod configuration and risk to saves: Pocketpair – Server mods.
• Checksum on Windows with Get-FileHash: Microsoft – Get-FileHash.