Backups that actually restore

The hardest lesson in operations: a backup you've never restored is not a backup. It's a hope.

This article is the minimum viable backup strategy for a Minecraft server. It's also general enough that the principles apply to most game servers. You can read it in five minutes. Setting it up takes an hour. It will save you the worst day of your hosting life.

The principle: 3-2-1

Standard rule of backups:

• 3 copies of your data.
• 2 different storage types.
• 1 off-site copy.

For a Minecraft server, that translates to:For a Minecraft server, that translates to:

• The live world (copy 1, on the server's disk).
• A snapshot on the same host but a different disk or volume (copy 2).
• A nightly upload to an external location: cloud storage, a different machine, anywhere not in the same building or account (copy 3).

The point is to survive every common failure: a corrupted save, a wiped disk, a deleted server, a host going bankrupt.

What to back up

For a Minecraft server, back up:

server.jar              (or the appropriate Paper / Forge jar)
server.properties
ops.json
whitelist.json
banned-players.json
banned-ips.json
eula.txt
plugins/                or mods/
config/                 (for modded)
world/
world_nether/
world_the_end/

Don't back up:

• logs/ (rotate separately, useful for forensics but not for restore).
• cache/ (regenerates).
• crash-reports/ (kept separately for diagnosis).

Some people back up plugins and mods separately from the world, on a different schedule. This is fine and recommended for any server with frequent world saves but rare plugin changes.

How often

This is the most-debated question. Honest answer: as often as the cost of losing that much time is greater than the cost of storing the backup.

For a typical paid server with active players:

Tier	Frequency	Retention	Total snapshots
Hot	Hourly during peak	24 hours	24
Daily	Once a day	30 days	30
Weekly	Sundays	12 weeks	12
Monthly	First of month	6 to 12 months	6 to 12

That's about 70 to 80 backup files total, but most are deduplicated by modern backup software, so disk impact is modest.

Storage size

A Minecraft world's size:

• New, 1-month-old world: 100 MB to 1 GB.
• Mature 6-month-old SMP: 5 to 20 GB.
• Long-running heavy server with many explored chunks: 30 to 100 GB.

Most modern backup software supports incremental and deduplicated backups. Tools like restic or borg can store 30 dailies of a 10 GB world in 12 to 15 GB total, not 300 GB, because almost everything between snapshots is unchanged.

Cold backups vs hot backups

A cold backup is taken with the server stopped. The world is fully written to disk, no risk of inconsistent state. The downside: you have to take the server down to back up.

A hot backup is taken with the server running. You either:

• Tell the server to flush to disk (/save-off then /save-all then copy then /save-on in vanilla / Paper).
• Use a filesystem snapshot (ZFS, btrfs, LVM) that captures consistent state in one atomic operation.

Hot backups are essential for production. Cold backups are useful for major version migrations.

The Paper / Spigot script pattern:

/save-off
/save-all
[copy world folder]
/save-on

Modern tooling like Paper's /paperback or various backup plugins automate this.

Off-site is non-negotiable

A backup on the same machine survives:

• An accidental rm -rf world/.
• A corrupted save.

A backup on the same machine does not survive:

• The host's disk failing.
• The hosting provider terminating your account.
• A ransomware attack on your host.
• Your billing card declining and the host suspending the server.

You need an off-site copy. Options:

• Cloud object storage (S3, B2, R2). Cheap, durable, scriptable.
• A different hosting provider. Run a tiny VPS that pulls backups via rsync or rclone.
• Your home machine, if you have one always-on with reasonable internet.

Cost reality check: a 30 GB backup set on Backblaze B2 costs about $0.18 a month. There is no excuse for not having an off-site copy.

Encrypt your off-site backups

Your world file contains:

• Player coordinates (privacy).
• Plugin databases (sometimes with player emails or auth tokens).
• Configuration with API keys (Discord, MoTD signing).
• IPs and player UUIDs.

Encrypt the off-site copy. restic and borg both encrypt by default. rclone has crypt remotes. Use them.

Store the encryption passphrase somewhere safe and somewhere not the same machine that holds the backups. A password manager works.

The restore test

This is the part most admins skip. Once a month, restore a backup to a test location and boot it. Even if you only boot to the loading screen.

Reasons you must test:

• Confirm the backup is complete (not just metadata).
• Confirm your passphrase works.
• Confirm you remember how to do it.
• Catch corruption silently introduced by the backup software.

A restore that fails the first time you need it is the textbook nightmare. Test in advance.

A complete recommended setup

A bare-minimum, no-plugins script

If you don't want plugins, here's a cron-friendly shell pattern for a Paper server with rcon available:

#!/bin/bash
set -e
SERVER_DIR="/opt/minecraft"
BACKUP_DIR="/backups/minecraft"
DATE=$(date +%Y-%m-%d_%H-%M)

# Flush saves
mcrcon -H localhost -p YOURPASS "save-off"
mcrcon -H localhost -p YOURPASS "save-all"
sleep 5

# Take backup
tar czf "$BACKUP_DIR/world-$DATE.tar.gz" -C "$SERVER_DIR" world world_nether world_the_end

# Resume saves
mcrcon -H localhost -p YOURPASS "save-on"

# Prune old daily backups (keep 30)
ls -1t "$BACKUP_DIR"/world-*.tar.gz | tail -n +31 | xargs -r rm

# Optional: sync to off-site
rclone copy "$BACKUP_DIR/world-$DATE.tar.gz" b2:my-bucket-name/minecraft/

Run hourly from cron. Adjust paths and passwords.

When backups go wrong

Worst-case restoration scenarios I've seen, with the fix that would have prevented them:

What broke	The fix that would have prevented it
"My backup is corrupted."	Run integrity checks weekly (restic check, borg check).
"My backup was on the same server, and the server was deleted."	Off-site copy.
"My backup is encrypted and I lost the passphrase."	Store passphrase in a password manager. Print it. Email it to yourself.
"My backup is from before the bug that ate the world."	Longer retention. Keep weekly snapshots for 12 weeks minimum.
"My backup includes the corruption."	Sometimes corruption is silent for days. Keep backups from weeks ago, not just hours.

Conclusion

Backups are not exciting. They are not difficult. They are the difference between a bad afternoon and a destroyed community.

Hourly, daily, weekly. Local and remote. Encrypted. Tested monthly.

If you do nothing else from this article, set up off-site, encrypted, automated backups today.