Game server backup strategy, game by game

A game server backup strategy comes down to four decisions: which folders hold the world and the settings, how to make the game write a clean copy before you take it, how many copies to keep and for how long, and where at least one of them lives that is not the server. For most games the world is one or two folders, a good schedule is a daily backup kept for a week plus a locked copy before every update, and the off-site copy is a download you make yourself once a week. The rest of this post is that, game by game, because the folder that matters in Minecraft is not the one that matters in Palworld, and backing up the wrong one is the most common way a backup turns out to be empty.

The general theory - what makes a copy restorable, the 3-2-1 idea, consistency - is in backups that actually restore. This post is the applied version for game servers: real paths, real save commands, and a retention policy that matches how each kind of game is played.

Three kinds of data on every game server#

Before choosing what to back up it helps to sort the files on a game server into three groups, because they deserve completely different treatment.

1. State - the world, the players' progress, the bases, the economy balances, the permissions database. This changes every minute the server is running, cannot be downloaded again from anywhere, and is the only thing whose loss is permanent. Every backup must contain it.
2. Configuration - server.properties, serverDZ.cfg, PalWorldSettings.ini, plugin configs, admin lists, ban lists. Small, changes rarely, and painful to recreate because nobody remembers the forty values they tuned. Back it up with the state; it costs nothing.
3. Reproducible files - the game binaries, the Steam runtime, Workshop downloads, the Java runtime. Gigabytes, and every byte of it can be fetched again with SteamCMD or the panel's reinstall. Leaving it out keeps backups small and fast.

The trap sits on the line between groups one and three. Mods are reproducible in theory, but only at the version you were running, and a mod author can delete an old release. If your server depends on a mod at a specific version, the mod file belongs in the backup even though it could in principle be downloaded again. The same goes for a custom map: reproducible until the person who made it disappears.

What to back up, game by game#

These are the folders that hold state and configuration for the games most people host. Paths are relative to the server's root unless they start with ~, and several of them move if you pass a save-directory argument at launch, so check the startup line on your own server before trusting a table.

A few of these need explanation.

Minecraft keeps the three dimensions in three folders on Paper and Spigot. Vanilla keeps the Nether and the End inside the main world folder as DIM-1 and DIM1, so a script written for vanilla misses two-thirds of a Paper world. Plugin data lives in plugins/<Plugin>/, and some of it is state - claims, economy balances, LuckPerms groups when stored in the default H2 file. Minecraft world backup and restore covers the save commands and region-level rollback in detail.

Project Zomboid is the one people get wrong most often. The map is in Saves/Multiplayer/<servername>, but player accounts and passwords are in db/<servername>.db. Restore only the map and every player has to register again; restore only the database and they log into a world that does not know them.

7 Days to Die stores saves under the user data folder, which on Linux defaults to ~/.local/share/7DaysToDie/Saves/ unless UserDataFolder or SaveGameFolder in serverconfig.xml points elsewhere. A random-gen world also has a generated map in GeneratedWorlds/ - small in config terms, but it took ten minutes or more to generate, and the save is useless without it.

DayZ writes its persistence into the mission folder. storage_1 holds the world objects, players and vehicles; the number is the instance id set in serverDZ.cfg. The economy files beside it (types.xml, events.xml) are configuration, and they are exactly what you edit, so they change more than you would think.

Counter-Strike 2 and other match-based shooters have nothing to lose but configuration. Their "backup" is a copy of cfg/ and the plugin folders, ideally in a git repository, and a daily snapshot of an unchanging folder is just disk usage.

Getting a consistent copy: save first, then copy#

Most games hold the world in memory and write it to disk on a timer. A file copy taken while the game is halfway through writing gives you a world that looks complete and fails to load. The fix is the same in every game: ask the server to write everything out, wait for it to finish, then take the copy.

On a panel, the Schedules tab is the right place for this. RE:NODE's schedules run ordered tasks with delays - a console command, a backup, a power action - so the sequence is a save command, a wait of thirty to sixty seconds for the write to finish on a big world, then the backup task. Scheduled tasks worth having has the cron lines and the full nightly sequence.

Task 1  command  say Backup in 1 minute - expect a short pauseTask 2  command  save-off              (delay 60 s)Task 3  command  save-all flush        (delay 5 s)Task 4  backup                         (delay 45 s)Task 5  command  save-on               (delay 120 s)

For a game without a save command, the safe options are a stop, a backup and a start, or accepting that the copy is from the last autosave. DayZ falls into the second group: a copy of storage_1 taken a few minutes after a scheduled persistence write is fine in practice. Stopping the server before a backup is never wrong - it is just inconvenient, which is why it usually lives inside the nightly restart window.

How many backups to keep, and for how long#

Retention depends on how the game is played, not on how much disk is free. Three patterns cover nearly every server.

Persistent worlds

Survival and sandbox servers - Minecraft SMP, Valheim, Palworld, Project Zomboid, 7 Days to Die without wipes, Factorio, Satisfactory - accumulate value every day and are never reset. A sensible rotation is:

• Daily backups kept for seven days. This covers griefing noticed a few days late and a corrupted chunk that went unnoticed until someone walked into it.
• Weekly backups kept for four weeks. Panel backup slots rarely stretch this far, which is what the download is for (next section).
• Locked backups before every game update, every mod change and every world-edit operation, kept until you are certain the change worked - usually a week.

Wipe-cycle servers

Rust, DayZ servers that wipe on a cycle, and anything with seasons. A backup older than the last wipe is worth nothing to the live server. Keep dailies within the current cycle, and one archived copy of the final state before each wipe if you want to show it off later or settle a dispute. The interesting configuration - plugin settings, loot tables, the economy - is what survives a wipe and what you most need to version.

Match servers

Counter-Strike 2, Team Fortress 2, Insurgency: Sandstorm and similar. Keep configuration in version control and back up the plugin databases (SourceMod's sourcemod-local.sq3 if you use SQLite for admins or stats). A daily full backup is wasted slots.

On RE:NODE every game plan includes two backup slots, and a backup can be locked so rotation never deletes it. Two slots is enough for "last night" and "before the update", which is the pair that matters most; anything longer lives in your downloads.

The off-site copy, and why the panel is not enough#

Panel backups on RE:NODE are stored off the machine they protect, which takes care of a failed disk. They do not take care of everything:

• Deleting the server deletes its backups, locked ones included. A cancelled plan, an unpaid invoice that ran its course, or a mistaken delete removes the copies along with the server.
• Slots are finite. A daily schedule overwrites last week's copy, which is the one you want if the problem started six days ago.
• Credentials are a single point of failure. Anyone with full access to the panel account can delete both the server and every backup in it. That is a reason for two-factor on your panel account and for subusers with least privilege, and a reason to hold one copy somewhere no panel login reaches.

The practical answer for most small servers is a weekly download. Backups can be downloaded from the panel as an archive; put it on a machine you own or a storage account with versioning, named by date. For a larger community, automate it: a scheduled job on a home machine or a cheap VDS that pulls the world folder over SFTP.

# Weekly pull of a Valheim world over SFTP, run from your own machine$ sftp -P 2022 user.abc123@panel.example:/worlds_local/Midgard.* \    ~/backups/valheim/$(date +%F)/

The exact host, port and username are on the server's SFTP details in the panel; SFTP and the file manager covers where to find them. Pull from a copy, not the live file, if you can - the backup archive you download is consistent, whereas a live .db mid-save is not.

Size, frequency and what it costs#

Backup size decides whether a schedule is practical. Rough sizes for long-lived worlds, excluding binaries:

Two things follow. Small worlds (Valheim, Terraria, Factorio) can be backed up hourly without anybody noticing. Large ones (a Minecraft world with a pre-generated 10,000-block border, a busy Zomboid map) take long enough to archive that hourly is unkind to the disk and the game, and daily during a quiet hour is the right cadence. Excluding what you do not need matters most here: a Minecraft backup that includes a Dynmap or BlueMap tile cache can be five times the size of the world it maps. How much storage a game server needs has the disk-sizing side of this, including the headroom backups need while they are being built.

Excluding folders on a Pterodactyl-based panel uses an ignore file called .pteroignore in the server root, written like a .gitignore (it is an upstream Pterodactyl feature, so ask your host if you are unsure it is honoured):

# rebuilt on demand, no need to back them upplugins/dynmap/web/tiles/bluemap/web/maps/logs/crash-reports/cache/*.log.gz

Test it once by taking a backup and checking its size against the folder sizes in the file manager. An ignore rule that accidentally matches the world folder is a silent disaster.

Restoring: the order that does not make it worse#

When the day comes, the restore is where most of the damage happens, because people act quickly on a server that is still running.

1. Stop the server. A restore over a running world is overwritten at the next autosave.
2. Take a backup of the broken state and lock it. You may need something from it later - a build made after the last good backup, or evidence of who did the damage.
3. Restore the whole backup, or extract only the world folder if you changed configuration since and want to keep it. On RE:NODE the panel restores a backup with a button; for a partial restore, download the archive and upload the folder you need through the file manager, which unpacks archives in place.
4. Check versions match. A world from before a game update loads in the new version almost always; a world from after an update rarely loads in the old one. If you are rolling back the game itself, see version pinning and rollbacks.
5. Start and read the log for the line that says which world was loaded. A server that cannot find the world usually generates a fresh one with the same name and looks perfectly healthy.
6. Tell players what time the world was restored to, so they know what they lost.

Then, at some quiet point, rehearse it. Testing a restore before you need it is a thirty-minute drill, and it is how you find out that the backup never had the db folder in it.

Common gaps, game by game#

The backups that fail on the day usually fail for one of these reasons:

• The world was elsewhere. A save-directory flag at launch (-savedir on Valheim, UserDataFolder on 7 Days to Die, -cachedir on Project Zomboid) moved the world out of the folder being backed up.
• The database was not a file. Plugins and frameworks that keep state in a database - FiveM frameworks through oxmysql, Minecraft plugins configured for an external database - need a dump of that database too. On a panel, the database slot is separate from the file backup; database backups and restores covers taking a dump.
• The server name changed. Zomboid and Don't Starve Together key their folders on a name. Rename the server and it starts writing to a new, empty folder while the backup schedule keeps archiving the old one.
• The backup ran during a save. No save command in the schedule, or a delay too short for a large world.
• Workshop content updated. The world refers to a mod version that no longer exists on the Workshop. Keep a copy of the mod files with the save for anything you cannot afford to lose.
• Built-in backups mistaken for real ones. Valheim's -backups, Minecraft backup plugins and 7 Days to Die's own backup folder sit on the same disk as the world. They protect against a corrupt save, not against a deleted server.

FAQ#

How often should I back up a game server?

Daily for a persistent world, at an hour nobody plays, plus a manual backup before every update or mod change. Hourly is worth it only for small worlds where losing an hour of an evening's play would cause real upset, and only if the backup takes seconds.

Do I need to stop the server to back it up?

Not if the game has a save command. Run it, wait for the write to finish, then copy. For games without one, stopping is the only way to guarantee a consistent copy, which is why many people fold the backup into the nightly restart.

Is it worth backing up the game files themselves?

Usually not. They come back with a reinstall or a SteamCMD update. The exception is when you depend on an exact version - a modded server pinned to an old build - in which case keep one copy of the working install, separately from the daily world backups.

What is the difference between a panel backup and a download?

A panel backup lives with your account and disappears if the server is deleted. A download is a copy you hold yourself, outside the panel's reach. You want both: the panel backup for a quick restore, the download for the day the panel copy is gone.

Why does my restored world look brand new?

The server could not find the world under the name it was told to load and generated a fresh one. Check the world or server name in the startup settings against the folder or file you restored, including capital letters, then restart.