What has to be in the backup
Two things, for every game covered here: the save or world file itself, and the configuration that recreates the server around it. Everything else — the server binary and launcher scripts — is replaceable. Mods and plugins are re-downloadable too, but their own configuration and stored data are not, so those travel with the backup. Save data is not replaceable at all. Here is where each one lives, from each game's own documentation.
| Game | Save data | Config that recreates it |
|---|---|---|
| Minecraft | The world folders — with a level-name of world that is world, world_nether and world_the_end; Vanilla keeps the other two dimensions inside world/ instead. | server.properties, plus the whole plugins (or mods) folder — the jars are re-downloadable, their configuration and stored data are not. |
| Rust | Everything under the folder named by +server.identity. | server.cfg inside that folder's cfg/ subfolder. |
| ARK: Survival Evolved | ShooterGame/Saved/SavedArks, where the map's .ark file and tribe data live. | GameUserSettings.ini and Game.ini under ShooterGame/Saved/Config/LinuxServer/ on Linux or ShooterGame\Saved\Config\WindowsServer\ on Windows. |
| Valheim | The worlds_local folder under the save path (IronGate/Valheim by default, or wherever -savedir points). | adminlist.txt, bannedlist.txt and permittedlist.txt sit in the save path itself, next to the worlds_local folder rather than inside it. |
| Palworld | The save data generated under Pal/Saved once the server has run at least once. | PalWorldSettings.ini under Pal/Saved/Config/LinuxServer/ on Linux or Pal\Saved\Config\WindowsServer\ on Windows. |
| Terraria | The .wld file in the Worlds folder. | serverconfig.txt (port, password, max players, message of the day) and banlist.txt. Load a restored world with -world <path to .wld>; -worldname only names a world that -autocreate is about to generate, it does not load an existing one. |
| Factorio | The save file in the saves folder; map settings are baked into it. | server-settings.json and server-adminlist.json — the save will not start a server without the first. Keep the mods folder next to them if you run any. |
| Project Zomboid | The server's folder under Zomboid/Saves/Multiplayer/, named after the server (servertest by default). | servertest.ini and the matching _SandboxVars.lua, _spawnpoints.lua and _spawnregions.lua files in Zomboid/Server/. |
If the reason you are copying any of this is to carry it to a different host rather than archive it, that is a related but different job with its own cut-over steps — see moving a server without losing the world.
How often, and what a few games already do for you
A weekly copy is the floor for a casual server. A server people are actively building on deserves a copy before anything risky happens, which the rest of this guide walks through. A handful of these games also keep their own short save history, and it is worth turning on rather than reinventing:
- Valheim. The dedicated server keeps its own backup history:
-backupssets how many copies to keep (4 by default),-backupshortsets the interval for the first one (2 hours by default), and-backuplongsets the interval for the rest (12 hours by default).-saveintervalcontrols how often the world itself saves, every 30 minutes by default. - ARK: Survival Evolved.
-MaxNumOfSaveBackups=<integer>sets how many save backups the server keeps — 20 by default, taken roughly every two hours. Set it to 0 if you already back up some other way. - Palworld. Setting
bIsUseBackupSaveDatato true makes the server keep a backup folder inside the save directory on a fixed schedule: five copies every 30 seconds, six every 10 minutes, twelve every hour, seven every day. The docs note it adds disk activity.
None of that replaces a copy stored somewhere other than the server itself. A built-in save history protects you from a bad write; it does nothing if the disk, the host or the account goes away.
The mechanism itself is simple and the same for every game on this list: stop the server, archive the save and config folder into a single dated file (a name like 2026-09-07-backup.zip is enough to tell copies apart later), then pull that archive to a machine that is not the server itself over SFTP or scp. Before you trust it, compare the file count and total size of the archive against the source folder on both ends — a transfer that was cut short usually shows up right there, before you ever need to rely on the copy.
The only test that proves a backup restores
A file you have not opened is not a backup, it is a hope. The test that actually counts: take the copy, load it — on a second server, or locally if the game supports single-player — and go look at the parts that cannot be regenerated. For a base-building game that means your main build, stored items and any tamed or bred creatures. For Minecraft it means spawn and anything built near it. For Terraria and Factorio it means opening the world and checking that the date or progress shown is the one you expect, not an older save that got copied by mistake. If the copy opens and shows what you expect, it restores. If you have never done this, you do not actually know your backup works, no matter how many copies you are holding.
Before you update the game
PaperMC's own update guidance calls backing up "the most important step, and yet the most frequently skipped," and names what to take: the world folders, server configuration files, and plugin configuration files and jars. The same order of operations holds well past Minecraft — stop the server cleanly, copy the save and config while nothing is writing to them, then update. Do not touch a running server's files mid-session; a copy taken while the world is still being written to can look complete and fail to load.
Before you change mods, plugins or add-ons
A mod or plugin that changes what it stores inside the save file is one of the most common ways a good backup turns into a useless one — you find out it did not carry over cleanly only after the world has already moved past the last copy that still matches. Before you add, remove or update anything that touches the world: copy the save and config, write down the exact versions you are running, and apply the change on a private or test copy first if you can before you touch the live server. If something breaks, you go back to a version you know worked instead of guessing which change caused it.
Before a wipe or a fresh start
A wipe is the wrong moment to discover your last backup is months old. On Rust, force wipes land on a set schedule and plugins need to be rechecked the same day — see the wipe day checklist for that routine specifically. For every other game, the same principle applies to any fresh start: take one final, verified copy of the world before you delete or overwrite anything, and keep that copy somewhere outside the server itself. That one habit is the difference between "we're starting fresh" and "we lost everything by accident."
Per-game hosting notes live on the Minecraft, Rust, ARK, Valheim, Palworld and Terraria availability pages.