Palworld Server Backups: Prepare for Updates and Check a Restore

Choose the right workflow before touching files

A planned update and a suspected data-loss incident need different first moves. The steps below are a maintenance rehearsal. If a character or base is already missing, do not treat saving again as a recovery method. Keep evidence of the state you found and work only on copies.

Enable local backup history, but keep a separate copy

The 1.0.4 configuration reference exposes bIsUseBackupSaveData. Enabling it creates a backup directory within the save-data location and adds disk load. On Windows, edit the active Pal/Saved/Config/WindowsServer/PalWorldSettings.ini, not DefaultPalWorldSettings.ini. Preserve the existing file and modify the parameter inside its existing settings structure; the fragment below is not a complete configuration file.

The reference lists five 30-second snapshots, six 10-minute snapshots, twelve hourly snapshots and seven daily snapshots. These are retention tiers, not proof that a particular point is available: inspect the files and timestamps your server actually produced. A setting enabled in an editor is not evidence of a completed backup.

Our recommendation is to keep a dated copy on another device or protected storage as well. History on the same disk cannot protect against losing that disk. Never delete older known-good copies merely because a fresh archive exists. Backups can contain passwords, player identifiers and private server details; restrict access and do not post them in public support threads.

bIsUseBackupSaveData=True

References: Pocketpair: configuration parameters and automatic backup history

Capture a healthy maintenance checkpoint

For this planned-maintenance path, first confirm that the running world is the one you intend to preserve. Note a base landmark, a recognizable Pal and an inventory detail. Keep private build and mod records separately from anything you share publicly.

Pocketpair documents in-game administration through an AdminPassword configured beforehand. Authenticate privately using /AdminPassword followed by your own password. The commands below are entered in the game's chat as an administrator, not in Windows PowerShell. /Info reports server information, /Save writes world data and /Shutdown schedules a stop. The reference distinguishes /DoExit as a forced stop; it is not the routine path here.

1. Tell the group when maintenance starts. Record /Info output, client version, operating system, enabled mods and the active installation directory. Ask players to finish their session.
2. Only while the world is healthy, run /Save. Then issue /Shutdown 60 Maintenance and allow the countdown to complete. Confirm the process has stopped; prevent a service manager or hosting panel from immediately restarting it during the copy.
3. Locate the actual installation's Pal/Saved directory and confirm it contains the world data you were just using. If multiple installations or worlds exist and you cannot identify the active one, stop here; do not guess from a familiar folder name.
4. Copy the entire confirmed Saved directory into a new, uniquely dated folder outside the server installation, preserving its structure. Do not copy over yesterday's backup. Separately retain the mod list, relevant custom configuration outside Saved and the build record. A Saved copy alone does not archive server executables or every mod.
5. Check for copy errors and unexpected empty files or folders. If you create an archive, extract a copy into an empty temporary location and check that the expected folders are present. This checks packaging, not whether the game can load it.
6. Copy the dated package to your separate storage, verify that copy can be read, and keep the original backup untouched during the restore drill.

/Info
/Save
/Shutdown 60 Maintenance

References: Pocketpair: in-game administrator commands · Pocketpair: dedicated-server deployment

The restore drill: prove the copy away from the live world

Use a separate test installation or a host-provided isolated test slot. Keep it off public listings and unavailable to ordinary players. It must not point at the live data directory. Prefer the same known server build and mod set first; a newer executable accepting an older save is a separate compatibility question, not something this guide guarantees.

If you cannot obtain a compatible test environment or isolate its data, retain the backup but label it untested. Do not call a failed cross-version experiment proof that the backup itself is bad. The official deployment page explains installation; the checks here are GamerWin's proposed validation procedure, not an official recovery guarantee.

1. Initialize the test installation if needed, then stop it completely before copying any data. Confirm both its installation path and its intended test address; never restore into the original production path.
2. Move the test installation's disposable Saved folder aside, keeping it recoverable. Place a COPY of the captured Saved folder in the corresponding test location without adding an extra nested Saved directory. Use the host's documented restore mechanism if it manages the paths.
3. Keep the captured source untouched. Review the test copy's settings for public visibility, address conflicts and access restrictions before starting it. Do not expose administration interfaces to make the test easier.
4. Join the test address with the same intended account and platform. Inspect the earlier world checkpoint and character state. A server-started message is insufficient. If you are asked to make a new character, stop and investigate the account, world selection and copied data instead of saving a replacement.
5. On the disposable test world only, make a harmless identifiable change, save, stop cleanly, then restart and reconnect. Record whether that change persists. Keep the modified test files separate from the untouched backup.
6. Record the actual outcome and stop the test instance. If a real production rollback later becomes necessary, preserve the then-current production state first and agree the lost-progress window with the group; do not automatically promote this rehearsal's modified files.

References: Pocketpair: dedicated-server deployment · Pocketpair: in-game administrator commands

Use evidence-based pass and stop conditions

These are acceptance criteria to apply to your own drill, not measured results. Record failures as well as successes. They help distinguish an unreadable archive from a wrong-world selection or a save that loads but cannot retain progress.

Worked planning example: choose the rollback point, not just the newest file

Illustrative scenario, not an observed server incident: your last verified copy is stamped 18:00. Players build until 19:20, and a later update leaves the world unusable. Restoring that 18:00 copy would discard up to 80 minutes of subsequent progress. A newer automatic snapshot is only a candidate until you check that it predates the problem and restores correctly.

For a planned update, take a fresh healthy checkpoint immediately before maintenance to reduce that window. For a discovered loss, preserve all available candidates first. Do not choose solely by file size or overwrite every older copy with the newest one.

Private restore record — fill in your own observations
Capture time and time zone:
Server/client build; platform; mod set:
Confirmed source installation and world:
Separate backup location:
Isolated test address and data directory:
Base / Pal / character checks:
Restart-persistence result:
Failure details or remaining uncertainty:
Keep passwords out of this record.

Before you play

• Healthy maintenance and suspected-loss workflows kept separate.
• Confirmed active data copied while the server was stopped.
• Untouched copy retained outside the live installation and on separate storage.
• Restore checked on isolated data, with character and restart tests recorded.
• Build/mod limits and any untested conditions written down.

Frequently asked questions

Sources & revision notes

Editorial revision: September 16, 2026. Source notes give the scope of each reference; the revision date is not a gameplay test date. Official documentation describes the publisher's system; community sources can contain errors. Use your installed game's own descriptions when they disagree.

1. Pocketpair: configuration parameters and automatic backup history (Official)

   Read September 16, 2026; page labelled 1.0.4. Supports active INI location, bIsUseBackupSaveData, disk-load warning and retention tiers; does not certify a restore.

2. Pocketpair: in-game administrator commands (Official)

   Read September 16, 2026; page labelled 1.0.4. Supports authentication, Info, Save, timed Shutdown and the distinction from force-exit. Commands were not executed against a game server by GamerWin.

3. Pocketpair: dedicated-server deployment (Official)

   Read September 16, 2026; page labelled 1.0.4. Installation context only. Isolation, copy retention and pass/fail criteria are our operational recommendations; no historical-build download or cross-version compatibility is promised.