Backups & Restore
Each backup snapshots the save unit (Pal/Saved/SaveGames/0/<32-hex GUID>/, containing Level.sav,
LevelMeta.sav, LocalData.sav, WorldOption.sav, and Players/*.sav) plus the server’s INI config
directory. PalCommand also snapshots the INI before every update.
Where this lives in the app
Every server’s Backups tab. A policy line at the top states your current schedule (a scheduled Backup task on the Schedule tab, if you’ve set one up), how many backups are kept, and where they’re stored. Back up now saves the world first, then archives it. If that save fails, the backup is aborted and reported as failed. PalCommand never archives a world it couldn’t flush, and never lets a bad new archive rotate out an older good one. The button stays enabled even while the server is stopped. The table below lists every backup with its date, build ID, size, and file name.
A backup takes the same exclusive hold on the world that restores and migrations use: if one of those is already running, the backup run is skipped (with a note in the event feed) rather than racing it, and while a stopped server is being archived, a Start is refused for those few seconds with a message saying a backup is in progress.
Restoring
Click Restore on any row. This works whether the server is running or stopped; it’s never gated on stopping it yourself first. Confirming it:
- If the server was running, it’s stopped.
- PalCommand snapshots the current world, so a restore is never a one-way trip.
- The chosen backup is restored.
- If PalCommand stopped it in step 1, and that stop succeeded, it’s started back up. A stop that failed never gets paired with a start.
A stopped server just restores directly, no stop/start round-trip. If players are online when you start a restore, the confirm dialog states the count and the same 60-second warning every other restart-causing action carries. When the restore finishes, a report dialog shows how many files were verified, the world’s ID, where the previous world was moved aside to, and, when the archive carried one, where the config was restored from.
Rotation
The table lists backups oldest first, newest last, by the time each was actually created, not by file name. Rotation (the Keep last setting on App settings) only ever counts and deletes archives PalCommand itself wrote for this server. A copy you drop into the backup folder under your own name, an archive left behind by a deleted server that once shared this server’s name, and an archive written by an older version of PalCommand are never counted against Keep last and never deleted by rotation. PalCommand can’t vouch that any of those belong to the server running today, so it leaves them alone; they stay on disk until you remove them yourself.
Automatic backups
Set up a recurring Backup task on the server’s Schedule tab (see Managing Multiple Servers) to have PalCommand back up on a cron schedule without you doing anything.