To back up a running Minecraft server safely: run /save-off, then /save-all flush, copy the world folder, then run /save-on. That sequence stops the server from writing region files mid-copy, which is the main way backups end up corrupted. If the server is stopped, just copy the folder. To restore, stop the server, replace the world folder with the backup, start it again.

That is the whole core of it. The rest of this guide covers which files actually matter, automation that does not wake you up at 3 AM, and the restore scenarios people only think about after losing a world.

Tested on: Minecraft Java Edition 1.21.4, vanilla server jar and Paper on Linux. The same file layout applies to Fabric and NeoForge servers. On a rented server, your host's panel backup button performs the equivalent of this sequence; this guide also explains what that button does so you can verify it.

What actually needs backing up

Everything irreplaceable lives in a handful of places in the server root:

The world folder (world/ by default, name set by level-name in server.properties). This contains region/ (the terrain), entities/, level.dat (world metadata, seed, spawn, game rules), playerdata/ (every player's inventory, position, ender chest), data/ (maps, scoreboards, saved structures), and datapacks/. On vanilla and Fabric servers the Nether and End live inside it as DIM-1/ and DIM1/. Paper splits them into separate world_nether/ and world_the_end/ folders: back up all three.

Config and identity files: server.properties, whitelist.json, ops.json, banned-players.json, banned-ips.json, usercache.json. Small, change rarely, painful to reconstruct. Your whitelist and ops setup lives here.

Mods, plugins, and their configs: the mods/ or plugins/ folder plus config/. Mod jars are re-downloadable, but their exact versions matter for world compatibility, and config folders carry hours of tuning.

Not worth backing up: logs/, crash-reports/, the server jar itself, and libraries/. All regenerable.

Player inventories live in world/playerdata/, not in a separate database. A world backup without playerdata (some selective backup scripts skip it) restores the terrain but wipes every player's inventory back to nothing. Always back up the world folder whole.

Why copying a live world corrupts backups

Minecraft writes terrain in region files, each holding a 32x32 chunk grid. The server buffers changes in memory and flushes them to disk continuously. If you copy a region file in the middle of a write, the copy gets half-old, half-new data; Minecraft may refuse to load it or silently regenerate the affected chunks, which players experience as a crater where their base was.

The save commands exist for exactly this:

save-off    stops the server writing region files (autosave paused)
save-all flush    forces everything still in memory onto disk, waits until done
    ...copy the world folder now...
save-on    resumes normal autosaving

save-all flush differs from plain save-all in that it blocks until the data is physically written rather than merely scheduled. For a backup, always use flush. Players can stay online through the whole sequence; they will not notice anything except a possible brief stutter on the flush.

A minimal automated backup script

On a self-hosted Linux server with the console accessible via screen or tmux, this is a complete working nightly backup:

#!/bin/bash
SERVER_DIR=/opt/minecraft
BACKUP_DIR=/opt/backups
STAMP=$(date +%F_%H-%M)

screen -S mc -X stuff "save-off\nsave-all flush\n"
sleep 10
tar -czf "$BACKUP_DIR/world_$STAMP.tar.gz" -C "$SERVER_DIR" world server.properties whitelist.json ops.json
screen -S mc -X stuff "save-on\n"

find "$BACKUP_DIR" -name 'world_*.tar.gz' -mtime +14 -delete

Run it from cron at a quiet hour. The sleep 10 gives the flush time to finish on a large world; raise it for worlds over a few GB. The last line keeps two weeks of dailies and deletes older ones, which prevents the classic failure of the backup disk filling up and every backup after that silently failing.

Two rules that matter more than the script itself: keep at least one backup off the machine (a copy on the same disk dies with the disk; sync to another machine, object storage, or even a scheduled download to your PC), and test a restore once before you need it. A backup you have never restored is a hope, not a backup.

Backups on a rented server

Every host we cover in our hosting comparison offers panel backups, but the details differ in ways that matter:

  • Scheduled vs manual. Check whether backups run automatically or only when you press the button. If manual, set a calendar reminder or use the host's API if they have one.
  • Retention and slots. Many budget plans keep 1 to 3 backup slots. A new backup overwrites the oldest, so a problem you notice four days later may already be unrecoverable. Download important milestones locally.
  • What is included. Some panel backups cover only the world folder, not mods and configs. Verify by downloading one and looking inside the archive.

The RAM tier you rent has no effect on backups, but disk space does: a server at 95% disk cannot create a backup archive. Our server RAM calculator includes typical disk allocations per plan tier when comparing hosts.

Restoring: the part people get wrong

Full world restore. Stop the server. Move the current broken world folder aside (rename it, do not delete it yet: it may have salvageable playerdata newer than the backup). Extract the backup so the world folder sits exactly where the old one was, same name. Start the server. Players will lose everything since the backup timestamp, so announce the rollback window honestly.

Restoring a single player. If one player's data corrupted (a crash during teleport is a known cause), you do not need a full rollback: stop the server, take just world/playerdata/<their-uuid>.dat from the backup, replace the live file, start the server. Find the UUID in usercache.json by searching for their name.

Restoring a region. Recovering one griefed or corrupted area from backup means replacing specific .mca files in world/region/. The region a chunk belongs to is its coordinates divided by 512, rounded down; the F3 screen shows the block coordinates in-game. Replace the matching r.X.Z.mca from backup with the server stopped. Everything inside that region rolls back, including chests.

Version mismatch warning. Restoring a 1.21.4 world onto a 1.21.4 server is always fine. Loading an old backup on a newer server version upgrades the world irreversibly on first load; downgrading a world to an older server version is unsupported and usually fails. Keep a note of the exact server version with each backup; this is the same version discipline that applies to updating mods between versions.

FAQ

How do I back up a Minecraft server without stopping it? Run /save-off, then /save-all flush, copy the world folder, then /save-on. The copy is consistent because the server stops writing region files between save-off and save-on.

What files do I need to back up on a Minecraft server? The world folder (on Paper also world_nether and world_the_end), server.properties, whitelist.json, ops.json, the banned-lists, and your mods or plugins folder with config. Player inventories are inside the world folder under playerdata.

How often should a Minecraft server be backed up? Daily for an active survival server, plus a manual backup before anything risky: version upgrades, adding or removing mods, big terraforming projects. Keep at least two weeks of history and one off-machine copy.

Can I restore just one player or one area from a backup? Yes. One player: replace their UUID .dat file in world/playerdata from the backup. One area: replace the matching region .mca file in world/region. Both with the server stopped.

Why did my restored world lose chunks or show craters? The backup was taken while the server was writing region files, without the save-off/flush sequence. Those backups are partially corrupted at creation time. Going forward, always pause saving during the copy.


Updated for Minecraft 1.21.4 on June 11, 2026. When a new version ships, paths and commands are re-checked and this log is updated.