How to Back Up a Minecraft Server (and Restore It)

Never copy a Java server's world folder while the server is running, because the server is constantly writing chunk data to disk and you'll eventually grab a region file mid-write and corrupt it. The safe sequence is four steps: run /save-off to pause writing, /save-all flush to force everything to disk, copy the folders while writes are paused, then /save-on to resume. That dance is the whole trick to a live backup, and the rest of this is knowing what to copy and proving you can put it back. If you're still standing up the box itself, setting up a Paper server comes first; backups are the thing you bolt on the day after.

The commands and folder layout here are the same across drops — backups are a version-agnostic mechanic — so nothing below changes between 26.1, 26.2 "Chaos Cubed" and the newest drop, 26.3 "Wilderness Bound."

Why a live copy corrupts the world

A running server doesn't hold the world neatly in memory and write it out on shutdown. It's writing chunks to disk continuously, in the background, the whole time players are online. Your world lives in region files — .mca files in the Anvil format, each holding a 32x32 area of chunks, named r.X.Z.mca. If your backup tool reads one of those at the exact moment the server is halfway through writing it, you copy a file that's internally inconsistent, and that's a corrupt chunk in your archive.

Region files are the fragile part of the whole setup. They're the files that go bad from forced shutdowns, power loss, running out of disk space mid-save, and from being copied live. The upside of that granularity is that when only a few chunks are bad, you can sometimes drop in just the affected r.X.Z.mca file from a backup instead of rolling back the entire world.

So the goal of the backup sequence isn't to stop the server — it's to make the on-disk copy hold still and be complete for the few seconds it takes to read it.

The safe live-backup sequence

Run these from the server console or in-game as an op:

1. /save-off — the server replies Automatic saving is now disabled and stops writing world and level files. From here, every change queues up in memory instead of going to disk.
2. /save-all flush — you'll see Saving the game (this may take a moment!) and then Saved the game. This forces every queued chunk and player straight to disk right now, so the on-disk copy is complete and consistent.
3. Copy or archive the world folders while writing is paused — tar, zip, rsync, whatever your stack already uses. The point is the files aren't moving under you.
4. /save-on — Automatic saving is now enabled, and the server resumes normal writing.

The step people skip is the last one. If you leave saving off and the server crashes, every change since /save-off is gone, because it only ever lived in memory and never reached disk. Always run /save-on, and don't leave a long gap between the copy and re-enabling it.

One caveat worth scheduling around: save-all flush briefly freezes the server while it writes. On a small world nobody notices, but on a very large one the pause is real, and heavy flushes have occasionally tripped watchdog timeouts. Run automated backups during your quietest hours, not at peak. If your server is already prone to freezing, a server that keeps crashing needs that fixed first — backing up an unstable box just archives the instability.

What to actually back up

The world is only part of it. A backup that's just world/ will restore your terrain and lose every land claim, home, shop, balance, and rank your players cared about, because none of that is in the world.

Back up all of this:

• Every dimension folder. Paper, Spigot, and CraftBukkit split the dimensions into three separate top-level folders at the server root: world/ (Overworld), world_nether/ (Nether), and world_the_end/ (The End). Each has its own region/ folder of .mca files. This is different from single-player, which nests the Nether and End inside the main world — so people who learned on single-player back up world/ and silently lose the other two. Grab all three.
• The entire plugins/ folder, subfolders and all. Each plugin keeps its own config and data in a subfolder — land claims, homes, shops, economy balances, and permissions all live in there, not in the world. The .jar files alone are useless without the data beside them.
• server.properties, plus bukkit.yml, spigot.yml, the Paper config, ops.json, whitelist.json, and banned-players.json if you want a clean rebuild rather than re-typing settings.
• Any external database. If a plugin stores its data in MySQL or SQLite rather than a flat file, that database is part of the backup. Archiving plugins/ won't capture a MySQL instance running elsewhere — dump it separately.

What's inside a world folder

You don't need to manage these by hand, but it helps to know what you're copying:

• level.dat — global world state: seed, time, gamerules, spawn point.
• level.dat_old — an automatic backup of level.dat the server makes each time the world loads. If level.dat itself goes bad, this is your first thing to try.
• session.lock — a lock file that stops two processes writing the same world at once.
• region/ (the .mca chunk terrain), plus entities/, poi/, playerdata/ (one UUID.dat per player), stats/, advancements/, and data/.

A note on layout drift: newer vanilla can nest dimensions under dimensions/minecraft/<dim>/, and very old worlds used DIM-1/DIM1. The three-folder split above is the Paper/Spigot layout the audience here runs, but if your folders look different, copy the whole server directory and you can't miss anything.

Automating it

Doing the four-step dance by hand once is fine; doing it every night is not. Two common routes:

A host-level cron job. Schedule a script that sends save-off and save-all to the server console, archives the folders with a dated filename, then sends save-on. The dated filename matters — world-2026-08-09.tar.gz, not backup.tar.gz you overwrite every run. One overwritten file isn't a backup; it's a single restore point that's only as good as last night, and if last night's run captured a corruption, you've now overwritten the good copy with the bad one.

A backup plugin. Something like DriveBackupV2 runs on an interval from inside the server — the default is every 60 minutes via its delay config key — and can upload straight to Google Drive, OneDrive, or (S)FTP. After editing its config.yml you reload with /drivebackup reloadconfig. Treat the specific keys as an example and check the plugin's own docs, since plugin commands shift between releases. The advantage is it handles the save pause and the offsite upload in one job.

Whichever you pick, keep multiple timestamped archives so you've got several restore points to fall back through, not just the most recent one.

Keep a copy off the box

A backup sitting on the same disk as the live world dies with that disk. When the drive fails or the host has a bad day, you lose the original and the backup in the same moment, which means you had no backup at all.

Get at least one copy off the server: rsync or scp the archive to a second machine you control, or let your backup plugin upload to Drive or FTP. Cloud storage you control is fine. The rule is just that the backup and the thing it's backing up shouldn't share a single point of failure.

Test the restore before you need it

An untested backup is not a backup — it's a hopeful guess that you'll find out is wrong at the worst possible time. The only way to know an archive is good is to bring it back up and watch it run.

Restore onto a separate test server, never your live world:

1. Stop the test server fully. A clean stop flushes everything and releases session.lock.
2. Move aside or delete its current world/, world_nether/, world_the_end/, and plugins/ folders.
3. Copy the backup's folders and server.properties into place.
4. Start it and confirm it boots, the world looks right, and player data and claims are intact.

Match the backup to a compatible server version, because restoring across major drops can fail or silently upgrade your chunk format. Record the server jar and version alongside each archive so you know what to restore onto. Do this once a month and you'll never discover a broken backup during an actual emergency.

FAQ

What's the difference between /save-all and /save-all flush?

Plain /save-all schedules a save and lets the server write it out over the next few ticks, which is gentler but means the files may still be settling when your copy starts. Adding flush forces every queued chunk and player to disk immediately and blocks until it's done, so the moment it returns Saved the game the on-disk copy is guaranteed complete. For backups you want flush — the brief freeze is the price of a consistent copy.

Can I restore just a few corrupted chunks instead of the whole world?

Often, yes. Because each r.X.Z.mca region file holds a fixed 32x32 patch of chunks, you can stop the server, swap a single bad region file for the same-named one from a backup, and start back up — everyone keeps the progress they made everywhere else. Figure out which region a coordinate falls in (divide the chunk coords by 32), and you only roll back the broken area instead of the entire map.

My host panel shows different console messages than these strings. Did it not work?

Probably it worked fine. The vanilla strings (Automatic saving is now disabled, Saved the game, and so on) are well attested, but Multicraft, other panels, and some Paper builds add prefixes, reword, or suppress them. Judge by behavior, not wording: after /save-all flush the disk write finishes, and after /save-on saving resumes. If the commands run without an "unknown command" error, trust that over the exact text in the log.

Should I keep the server running while I copy, or just stop it?

If you can take the downtime, a full stop is the simplest safe backup there is — stopping flushes everything and releases session.lock, so the folders are guaranteed quiet and you can copy them freely. The save-off/save-all flush/save-on sequence exists for when you can't afford to kick everyone off a busy public server. Pick by whether the downtime costs you more than the few seconds of flush pause does, and remember that smooth uptime is part of what keeps your community around to vote you up the monthly rankings.