For Creators & Hosts

How to Back Up a Minecraft Server (and Restore It): Manual, Automatic, Aternos and Hosts

Copy the right folders, automate it, keep a copy off the machine, and prove the restore works before you need it.

Every server owner has the same bad morning: a crash, a corrupted chunk, a griefer, or a host that vanished, and the world's gone. Here's how to back up a Minecraft server so that morning is a ten-minute annoyance instead of the end of the world.

The short version: stop the server and copy the whole server folder, or on a running Java server run save-off, then save-all flush, copy the files, then save-on. Put that on a schedule, keep a copy somewhere that isn't the same machine, and restore one now and then to check it actually works. If you're about to update, my guide to updating a Minecraft server has the back-up-first checklist.

Versions here are as of November 2026: the latest Java Edition release is 26.3.

What to back up (and what to skip)

Copy the whole server folder. Not just world. The world is the part you'll cry over, but the rest is what makes the server yours:

What can go: logs, crash reports, and old server jars you've replaced. That's my judgment rather than a rule, and if you've got the space, copying everything is easier than deciding.

The 26.1 layout change

Since Java 26.1, the default dimensions live inside the world folder under dimensions/: the Overworld at dimensions/minecraft/overworld, the Nether at dimensions/minecraft/the_nether, the End at dimensions/minecraft/the_end. Player data moved into a players subfolder. Older worlds keep the Nether in DIM-1 and the End in DIM1. Either way, back up the whole world folder and you get every dimension. Don't hand-pick subfolders.

Manual backup on a Java server

Stop and copy (the cleanest)

Run /stop, which saves the world, then copy the whole server directory to another drive or location. Put the date in the name, like server-2026-11-09, so you can tell copies apart. It's boring and it's the most reliable method there is. If your friends can live without the server for a minute, use it.

While the server is running

Run these in the server console (they need permission level 4, and they only work on a dedicated server):

  1. save-off: stops the server writing to the level files and queues changes. Player, advancement and stat files still get written, and the setting resets when the server restarts.
  2. save-all flush: writes every player and chunk to disk right now. The server freezes for a moment. Plain save-all isn't enough, because it saves players right away but only marks chunks to be saved over time.
  3. Copy the files.
  4. save-on: turns normal saving back on. Don't forget this one.

Because those player files can change mid-copy, stop-and-copy is still cleaner when you can manage it.

Bedrock Dedicated Server

Bedrock has its own version of the same dance, and it needs cheats on for /save:

  1. save hold pauses writing to the world files and queues changes.
  2. save query tells you whether it's ready. Once it succeeds, it returns the list of files to copy. Run it again if it isn't ready yet.
  3. Copy those files.
  4. save resume turns writing back on.

For a full copy, grab the worlds folder, server.properties, allowlist.json, permissions.json and any custom behavior_packs and resource_packs. Setup details are in how to make a Minecraft Bedrock server.

Automatic backups

A simple cron script on Linux

A backup you have to remember is a backup you'll skip. On Linux, the Minecraft Wiki's server startup script shows the pattern: save-off, save, wait a few seconds, archive the world, save-on, with cron running it on a timer (its example runs every half hour). Here's a stripped-down version of my own, five lines in a shell script, in this order. It assumes the server runs inside a screen session called mc, and the paths are examples you'll need to change:

  1. screen -S mc -p 0 -X stuff "save-off$(printf '\r')"
  2. screen -S mc -p 0 -X stuff "save-all flush$(printf '\r')"
  3. sleep 15
  4. tar -czf /home/mc/backups/server-$(date +%Y-%m-%d_%H%M).tar.gz -C /home/mc/server .
  5. screen -S mc -p 0 -X stuff "save-on$(printf '\r')"

Put #!/bin/bash on top and make it executable, then add a line with crontab -e, for example 0 4 * * * /home/mc/backup.sh for 4 a.m. every day. Run it by hand once and open the archive before you trust it. Read any script you find online before running it, mine included.

A backup plugin: DriveBackupV2

If you're on Paper or Spigot and don't want to script, DriveBackupV2 is the one plugin I'd point you at. Per its Modrinth page, it uploads backups to Google Drive, OneDrive, Dropbox, (S)FTP or S3-compatible storage, runs on a schedule (hourly by default), and deletes old backups past a count you set. Drop it in plugins, restart, and link an account with /drivebackup linkaccount googledrive.

Check its version list before installing. Its listings only go up to Paper 26.1.x, and its description text still mentions older versions, so make sure it lists the version you run. Never replace plugin jars on a running server. New to plugins? How to install Minecraft server plugins walks through it, and the best server plugins roundup has more.

Aternos backups

Aternos backups go to your own Google Drive, so you have to link one first. Then add the backup service to each server with the + button on its backups page, and hit Create Backup. Friends with shared access and the Backups permission can link their own services.

If the host is new to you, I covered it in is Aternos safe.

Realms and paid hosts

Realms keeps backups on its end. Check your Realm's settings in-game to see what's there, and don't treat those as your only copy. If you're weighing Realms against running your own, start with my Realms price guide.

On a paid host's panel, there's usually a backup button somewhere. Find it, and check two things: whether backups count against your storage, and whether they live on the same machine as the server. If they do, they won't help when that machine goes down.

Where to keep copies, and how many

This part is just my advice. Don't keep your only backup on the same disk as the server. If that disk dies, you lose both. Keep at least one copy somewhere else entirely: another machine, cloud storage, an external drive. As for how many, I keep a handful of recent ones plus a couple of older ones. The recent ones cover a crash, and the older ones cover the problem you only noticed last week, like a griefed build or a slowly corrupting chunk. If you only ever keep the newest, a bad backup replaces a good one.

How to restore (and test it)

  1. Stop the server.
  2. Move the current world folder aside and rename it. Don't delete it yet.
  3. Copy the backed-up world folder(s) in, with the same names they had. On Paper, restore the Nether and End folders too.
  4. Start the server and check the world: a build you know, a chest, a trip through the Nether.

On Bedrock, copy the world folder into worlds and set level-name in server.properties to match, including letter case. On Aternos, use Restore.

A backup you've never restored is a guess. Once in a while, restore one onto a spare folder or a second machine and join it. That's how you find out the script was archiving the wrong path, before the day it matters.

The routine, in one breath

Copy the whole folder, flush before you copy on a running server, automate it, keep one copy off the machine, and restore one now and then. If you haven't got the server yet, start with how to make a Minecraft server.

Hosting somewhere new

Folly is a standalone multiplayer voxel game for PC, free with no purchases required, and it's coming soon in early access. Player-hosted servers are planned for early access. That's a plan, not something you can do today. Details are on the hosting and creators page.