Backups: The Habit That Saves Your Game Server
World files are the only copy of hundreds of hours of play. Here is what to back up, how often, and how to restore without making a bad situation worse.
Galaxy Nexus Team
Galaxy Nexus Hosting
A game server is the sum of its world files. The plugin config took an afternoon, the whitelist took a week, and the world itself is months of player time. All of it lives in a few directories on one disk, and disks fail, updates corrupt, and rollbacks happen. Backups are not insurance against disaster; they are the tool that makes a bad weekend into a ten-minute restore. This guide covers what to back up, how often, and how to restore without making things worse.
What to Back Up
Backing up "everything" is safe but wasteful. These are the minimum directories that contain the irreplaceable data:
- World folders (
world/,world_nether/,world_the_end/for Minecraft): the actual play data. - Player data and whitelist:
whitelist.json,ops.json,banned-players.json, and player data folders. - Server configuration:
server.properties,bukkit.yml,spigot.yml. Two hours of tuning you do not want to redo. - Plugin data:
plugins/holds both jars and their data directories. Back up everything underplugins/; the jars are replaceable, the data is not. - Modpack/mod lists: for modded servers, a manifest of exact mod versions, so reinstalling reproduces the same setup.
You do not need to back up the entire game binary or system files. Reinstall those. Back up the data.
How Often Depends on How Much You Would Lose
There is no universal cadence, only a tradeoff: the fresher the backup, the less loss on restore, at the cost of more frequent writes. A practical table:
| Server type | Cadence | Reasoning | |---|---|---| | Public server, active community | Every 4-8 hours | A rollback costs at most half a play session | | Small private group | Daily | Downtime beats lost progress for most groups | | Modded or long-term world | Daily plus pre-change manual | One bad update wipes more than one bad day | | Before any change (update, plugin install, reset) | Manual, always | The rollback path is why you are backing up |
Back up before the experiment, not after
Plugin updates, generator changes, and forced chunk resets are the moments corruption actually happens. Take a manual backup immediately before any change, even if the schedule says otherwise. It costs 30 seconds and makes every experiment reversible.
Retention: Keep More Than One
A single backup protects you from a crash. It does not protect you from a corrupt backup, and corruption is usually discovered days later, not minutes. Keep at least:
- Daily backups for the last 7 days, so a problem noticed on Saturday can be rolled back to Friday.
- A weekly snapshot for a month, because some bugs only surface after a week.
- One monthly snapshot kept permanently, as the recovery point for a long-lived world.
When storage is cheap, delete nothing older than a month. When it is not, the weekly and monthly tiers above are the minimum that still gives you a usable history.
Restoring Without Making It Worse
The most common restore mistake is overwriting the live world with a backup while the server is running, or before verifying the backup is intact. Restore in this order:
- Stop the server before touching world files. A running server will overwrite chunks you are trying to replace.
- Rename the current world directory (for example
world_broken) instead of deleting it. If the backup turns out to be bad, the original is still there. - Restore the backup into place with the correct folder name.
- Start the server and verify: spawn, a chunk you know, player inventories.
- Only after a successful check, delete the
world_brokendirectory.
A backup you have never restored is a guess
Do a restore drill once: copy a backup to a spare slot, start the server against it, and confirm the world loads and a player can join. Five minutes of practice turns a future panic into a routine job.
Partial Writes and Why Snapshots Are Safer
A backup taken while the server is writing chunks can capture half-written files: the archive reads a file mid-write, and you now have a backup that is corrupt in a way that shows up only on restore. Where your panel offers snapshot-style backups (filesystem-level, not in-game saves), prefer them, or take backups during quiet periods. Tools that stop saving briefly, or panels that coordinate with the save process, avoid this entirely. Whatever you use, the verify step in the restore drill above is what catches it before you need it.
Take a Copy Off-Site
A backup on the same disk as the server protects against file corruption but not against hardware failure. At least once a month, download a copy of the latest backup to your own machine or a second storage location. Your community's history should not depend on a single motherboard.
The habit to build is small: a scheduled backup every few hours, a manual one before every change, one monthly copy somewhere else. Do that, and the first question when something breaks is never "how much did we lose?". It is "which backup do we restore first?".