Backups That Actually Restore

Published 29 September 2026 · JoinGG

A backup is not a backup until you have restored it. Most game server backups fail for four reasons: they were copied while the world was being written, they sit on the same disk as the server, they live only inside a panel you can lose, or the retention window is shorter than the time it takes to notice the corruption.

Almost every server owner has backups. Ask how many have restored one in the last six months and the room goes quiet. A job that exits zero every night proves a job ran, not that the bytes it wrote can become a working server with your players' progress intact.

The failures are rarely dramatic. People lose worlds because a region file was half-written when the tarball started, because the only copy sat on the volume that just went read-only, or because they found out on day nine that a plugin had been corrupting inventories since day one and the oldest snapshot was 48 hours old. What follows is what actually breaks, and what a routine looks like when it is built for a bad day. It applies equally to one box and to a network near the top of the live Minecraft server list.

Torn saves: what happens when you copy a world mid-write

Start here, because this failure produces the most convincing-looking backups. The archive is the right size. It extracts cleanly. It contains every file you expected. Then the server boots and throws Chunk file at 4,-2 is missing or corrupt, with a hole where your spawn town used to be.

Minecraft stores terrain in region files under region/r.x.z.mca. Each holds up to 1,024 chunks, and it is not a flat list of blocks. The first 4 KiB is a header table mapping every chunk to an offset and a length in 4 KiB sectors. When the server saves a chunk that has grown, it allocates new sectors at the end of the file, writes the data there, then rewrites the header entry to point at the new location. Those are two separate writes. Copy between them and the header points at a sector holding whatever was there before, or nothing. The file is intact; the internal pointer is a lie.

The same bug exists everywhere with different filenames. Rust writes a new .sav in the server identity directory and only rotates it into place once complete, so grabbing the newest file at the wrong moment yields a truncated save. 7 Days to Die writes region data in .7rg files plus a separate players.xml, and those two disagree easily if the copy takes 90 seconds and someone logged out at second 40. Source-engine servers hold far less persistent state, but any Garry's Mod gamemode with an SQLite file has the same window.

Three things make this worse than it sounds. It is silent, so nothing in the backup log hints at it. It is intermittent, so a test restore that catches a quiet moment passes and hands you false confidence. And the damage is usually partial: one lost chunk, not a lost world, so it can sit undetected for weeks until somebody walks into it. By then it is in every snapshot you own. The fix is not to copy faster. It is to make sure no write is in flight while you copy.

How to quiesce each engine before a snapshot

Quiescing means telling the game to finish what it is writing and then stop writing, for as short a time as you can manage. Every engine that persists a world has a version of this, and almost all are reachable over RCON, so you can script it.

Minecraft: save-off, flush, copy, save-on

The order matters. save-off stops the auto-save loop from starting new writes; save-all flush blocks until every dirty chunk has reached disk, rather than queueing the work and returning immediately the way a bare save-all does on some builds.

• mcrcon -H 127.0.0.1 -P 25575 -p SECRET "save-off" "save-all flush"

• Take the snapshot or start the copy.

• mcrcon -H 127.0.0.1 -P 25575 -p SECRET "save-on"

Always run save-on from a trap or a finally block. A script that dies between step one and step three leaves auto-save disabled, and the next crash costs everything since the last manual save. In the servers I have watched, that mistake has killed more worlds than torn files have. If you are still choosing a jar, the comparison of Paper, Purpur and Fabric as server software covers which builds give you these flush semantics.

Rust, 7 Days to Die and the rest

For Rust, issue server.save over RCON and wait for the console confirmation before touching files. The default server.saveinterval is 300 seconds, so snapshotting without forcing a save can silently cost five minutes of building on top of the tearing risk. Fold this into your wipe routine, since the pre-wipe archive is the one people ask for later; it is worth reading how a wipe schedule affects a small player base before deciding what to keep from each cycle. The variation in cycle length across the Rust server list is exactly why generic advice does not fit.

7 Days to Die exposes saveworld over telnet, by default on port 8081. Send it, wait for the acknowledgement, then archive Saves/<World>/<GameName>/. The 7 Days to Die server list is full of long-running blood-moon worlds where one lost horde night is a real complaint.

Snapshot rather than copy

Quiescing costs a pause, and copying 40 GB at 200 MB/s takes over three minutes. Holding saves off that long on a busy server is a visible stutter and a real risk. Filesystem snapshots collapse it: flush, snapshot, resume, then archive at leisure from the frozen snapshot while the live server runs normally. The pause drops from minutes to under a second on ZFS, btrfs or LVM. On a plain ext4 volume with no snapshot layer, the next best option is a hardlink-based rsync into staging during a short pause, then compressing from staging.

Where the backup lives, and a 3-2-1 plan for $15 a month

An hourly backup on the same disk as the server is worth less than a weekly backup somewhere else. That is uncomfortable, because same-disk backups are the ones that are trivially easy to set up.

Everything that destroys the server data destroys a same-volume backup with it: filesystem corruption, a failing NVMe, an rm -rf with a stray slash, ransomware that walks the mount, a host reclaiming the volume after a suspension. The only failure it protects against is the narrow case where the files are fine and only their contents are wrong. Keep the local copy for that fast rollback; just do not count it as your backup.

The subtler trap is the panel-only backup. Pterodactyl and most panels built on it default to a local backup driver writing to the same wings node your server runs on. The UI gives it its own tab and its own retention setting, so it feels like off-box storage. It is not. Lose the node and you lose both. There is an S3 driver, it works, and switching takes ten minutes.

Losing access is worse than losing hardware. A billing dispute, an expired card or a moderation action locks your panel, and the backups sit behind that same login. The rule that follows is short: at least one copy must be reachable with credentials that are not your host's credentials. If a host change is already on your roadmap, the guide to migrating a game server between hosts exercises the same data in a planned rather than an emergency context.

What 3-2-1 costs on a small server

Three copies, two kinds of storage, one off-site. Dismissed as enterprise overkill for a hobby server, it just needs translating into single-digit dollars.

• Copy one — the live data. This counts. It is the one you use for the fast rollback case.

• Copy two — a local rolling snapshot. Six hourly restore points on the same box, as ZFS or btrfs snapshots or a deduplicated repository in a second directory. Cost: disk space. Purpose: undo a bad plugin install in 90 seconds without touching the network.

• Copy three — object storage you own. A restic or borg repository in Backblaze B2 or Cloudflare R2, written nightly, holding the daily and weekly tiers. At roughly $6 per TB per month, 80 GB of deduplicated history costs about $0.50.

Direction matters as much as destination. If the server pushes with a key stored on the server, anything that compromises the server can delete the backups. Use pull-based transfers from a machine you control, or scope the push credential to write-only and turn on object versioning, which both B2 and R2 support for cents. Encrypt client-side too, which restic and borg do by default, and store the passphrase somewhere that is not the server. Hosting economics shift quickly, so check current pricing against what game server hosting actually costs in 2026 before committing.

How long should you keep backups?

Retention is where most schedules quietly fail, and the arithmetic is easy to get wrong in a way that looks generous.

Take a very common setup: hourly backups, keep the last seven. That sounds like a lot of backups. It is seven hours of history. If a plugin started writing bad inventory data at 02:00 on Monday and a player reports it on Wednesday afternoon, every snapshot you own contains the damage. You have seven copies of a broken world, produced by a job that ran perfectly for 60 hours.

Interval controls how much progress you lose. Depth controls whether you can reach back far enough to find a clean copy. They are separate problems needing separate answers, and depth should be driven by detection lag, which on a game server is measured in days. Corruption is found when someone walks into a broken chunk. Griefing is found when the victim logs in. A bad config is found when someone notices their balance is wrong.

A tiered scheme solves it. For a single game server:

• 6 hourly — the routine case of a bad restart or a plugin you just installed.

• 7 daily — a week, which catches most griefing reports.

• 4 weekly — a month, which catches slow corruption and the plugin that has been subtly wrong since an update.

• 3 monthly — optional and cheap if your tool deduplicates. Useful for wipe-cycle games and maps you might revive.

That is 17 restore points spanning 28 days, and it costs less storage than 48 hourly snapshots reaching back two days, because deduplicating tools store each unique block once. After the first full copy of a 40 GB world, a daily increment on a moderately active server usually lands between 300 MB and 2 GB, so a month of history often fits in 60 to 80 GB.

One more rule: prune on a schedule independent of the backup schedule. If pruning runs inside the same script and that script fails halfway, you can delete old copies without having written a new one. Make the prune step refuse to run when the newest snapshot is older than the expected interval.

Databases need different handling from world files

Any server with an economy, a claims plugin, a punishment system or a roleplay framework keeps its real state in SQL, not on the filesystem. Copying /var/lib/mysql while MySQL is running produces a database that may or may not start, and that is the polite outcome.

Use a logical dump and make it transactional. For InnoDB, which is what you almost certainly have, that is mysqldump --single-transaction --quick --routines --events --databases mydb > mydb.sql. The --single-transaction flag opens a consistent snapshot so the dump reflects one moment without locking writers out for its duration. Drop it and the dump reads tables one after another, so a player who buys something between the read of the balance table and the read of the inventory table appears in your backup holding both the money and the item. --quick streams rows instead of buffering a whole table in memory, which matters past a few million rows. Note that --single-transaction buys nothing on MyISAM tables, which some older plugins still create.

The harder problem is skew. The database and the world are independent stores and they only agree if you capture them together. Snapshot the world at 03:00 and dump SQL at 03:40, and a restore rewinds blocks to 03:00 while balances stay at 03:40. Players keep purchases whose items were rolled back, and chests refill. On a FiveM roleplay server running ESX or QBCore the equivalent is a vehicle that exists in owned_vehicles but was never delivered. Run the dump inside the same quiesce window as the world flush, or log the skew and treat the earlier time as authoritative.

Verify the dump by restoring it, not by looking at its size. A mysqldump that hits a permissions error partway through still leaves a large, plausible file that stops mid-table. The cheap check is a nightly import into a scratch database plus row counts on your three most important tables. If your economy table had 4,180 rows yesterday and the import produces 61, you want to know on Tuesday rather than during an outage.

The restore drill nobody runs

Everything above is theory until you have taken a real archive and turned it back into a running server. Do it on a staging instance, ideally on a different box, so the drill also proves your archive is portable and not secretly dependent on something in the live filesystem.

1. Pick a backup you did not just create. Take the oldest in your daily tier. If that one restores, the recent ones almost certainly will.

1. Restore to an empty directory on a different port. Change server-port, disable the query port if it clashes, and change the RCON password so a stale script cannot talk to the wrong instance.

1. Cut its outward connections before booting. Turn off master-list and voting-site registration, disable Discord webhooks and scheduled announcements, and stop any plugin that messages players. A staging instance announcing a fake restart to your community is its own incident.

1. Boot it and read the whole log, not just the last line. Look for missing-chunk warnings, plugin exceptions on load, and database connection errors.

1. Log in as yourself, not as a fresh test account, because a fresh account has nothing to compare. Check inventory, position, permissions group and balance. Then check a long-time player's account, with their knowledge.

1. Visit three places that matter: spawn, the largest build you know of, and a chunk generated recently. Chunk damage is spatial, so sampling one location proves almost nothing.

1. Write down the wall-clock time from the moment you decided to restore to the moment you could have let players in.

That last number is your recovery time objective, and until you measure it you are guessing. Owners routinely underestimate it, and the difference goes on finding a credential, remembering which flags the start script used, or waiting on a download they had never timed. The first drill is slow; the second is usually much faster, because the drill itself tells you what to write down.

Run one after any change that touches data: a new plugin, a version upgrade, a host migration, a new backup tool. Quarterly is a reasonable floor otherwise. Pair it with your availability checks so you are watching both halves of the problem — the guide to game server monitoring and uptime covers detection, and the drill covers recovery. Checking Minecraft population history or the network-wide statistics across every tracked game will also tell you which hours a drill costs you least.

What to keep, what to exclude, and how to verify it

Backing up everything is not thoroughness. It is a way to make restores slow and storage bills silly. Exclude anything regenerable or redownloadable: logs/ and crash-reports/, cache/, libraries/, the server jar, and any web tile directory a map renderer produced. That last one is the big win. A fully rendered Dynmap or BlueMap tile set on a well-explored world runs 10 to 25 GB, every byte regenerable from the world you are already backing up. Keep a plain text file recording the exact build number instead of the jar, so a restore reproduces the same version rather than the latest one. Block-logging databases such as CoreProtect deserve a middle path: valuable for rollbacks, often larger than the world, and fine on weekly retention.

Compression on a 40 GB world

Compression is where the wall-clock time goes. On a modest four-core box the practical numbers look like this:

Moving from gzip to zstd is the cheapest win available: every core is used, the file is smaller, and it decompresses several times faster, which is the number that matters during a restore. Going past level 3 buys a few percent of size for a large multiple of time, because world data is mostly packed NBT block arrays that do not reward the effort.

A backup matrix with verification attached

Use this as a starting configuration and scale the intervals to activity, not to disk size. A server with 80 concurrent players at peak loses far more human effort per hour than a six-player private world. The verification column is the part most people skip, and it is the part that turns the table from a wish list into a system.

Add one automated check that has nothing to do with the backup tool: alert when an archive's size deviates more than about 30 percent from the trailing median for that job. A backup that wrote 240 bytes and exited zero is the most dangerous artifact in this article, because it sits in your retention tier looking exactly like a real one until the day you need it. If you are building a server from scratch and want the file layout in front of you first, the walkthrough on running a Minecraft server without paying for hosting shows which directories end up mattering.

Frequently asked questions

How often should I back up a game server?

Match the interval to how much play you are willing to ask people to repeat. Hourly is right for a busy survival or roleplay server where an hour of lost progress is annoying but survivable. Every six hours is fine for a small private world. Wipe-cycle games need less: a snapshot at wipe plus daily copies covers almost every real incident.

Is the backup button in my host panel enough?

Only if you know where it writes. Panel backups that land on the same node as the server share every failure that node can have, and they disappear with your account if billing or moderation locks you out. Point the panel at S3-compatible storage you own, or keep one independent copy pulled from outside the host.

Do I have to stop the server to take a safe backup?

No, but you do have to stop writes for a moment. Flush and pause world saving over RCON, take a filesystem snapshot, then resume saving. The pause lasts a second or two instead of the several minutes a full copy would take, and the snapshot you archive afterwards is internally consistent.

What is a realistic restore time for a 40 GB world?

From object storage over a 1 Gbit link, plan for roughly 6 to 10 minutes of download, 3 to 6 minutes of decompression, and 5 minutes of configuration and boot. Call it 20 minutes if nothing surprises you. On a 100 Mbit uplink the download alone is closer to an hour, which is why a nearby warm copy matters.

How many restore points do I actually need?

Enough to cover the gap between when damage happens and when someone notices it. Corruption and griefing are often reported days late. Six hourly, seven daily and four weekly points give you 17 restore targets spanning 28 days, and they cost less storage than 48 hourly snapshots that only reach back two days.

Should I back up plugin databases separately from the world?

Yes, and you should capture them in the same window as the world files. Economy balances, claims and inventories live in SQL while the blocks live on disk. If the dump is 40 minutes newer than the world snapshot, restoring both gives players items they already spent and chests that refilled themselves.

Where to go from here

Pick one thing and do it today. If you have never restored a backup, that is the thing: take your oldest daily snapshot, put it on a second port, boot it, and time yourself. Everything else is a guess until that number exists. After that, work down in order of how much it would hurt to skip. Get one copy off your host's infrastructure. Add a weekly tier. Quiesce before you copy. Dump databases transactionally in the same window as the world.

JoinGG tracks 11,561 listed servers across 31 games with servers currently online, polling hourly and keeping seven days of history. Some of those listings go dark permanently after a data loss rather than after a decision. If you run one of them, browse the full server list to see who you are competing with for players, and if you are not listed yet you can add your server to the index in a couple of minutes. Both are more pleasant tasks than rebuilding a world from memory.

Related reading

• Rust player counts and server population trends — useful for picking a low-traffic maintenance window.

• Garry's Mod servers ranked by live player count — gamemodes with SQLite state that needs the same care.

• What makes a server listing trustworthy — uptime and continuity read as credibility signals.

JoinGG indexes public game servers and publishes hourly player-count measurements. Figures cited in this article reflect measurements taken on 9 September 2026.