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

Why backups matter more than you think

Servers lose data in boring ways: a crash during a save, a bad plugin update, a griefer, a mistyped command, a failing disk. A backup you can actually restore turns every one of these from a disaster into a minor annoyance. The key words are can actually restore. A backup you have never tested is a hope, not a backup.

What to back up

• The world folders (world, world_nether and world_the_end on most setups).
• The plugins folder, including every plugin's config and data folders.
• server.properties and the other config files in the server folder (bukkit.yml, spigot.yml, paper configs).
• Databases used by plugins. If you use MySQL or MariaDB, dump it separately. File-based databases (SQLite, or H2 used by some permission plugins) live in the plugin folders and should be copied while the server is stopped.

You can skip the server jar and the logs. The jar is easy to download again, and logs can be large and add nothing to a restore.

Copying a live world safely

Copying world files while the server is writing to them can produce a backup that is damaged. These console commands pause saving and flush everything to disk first. Run them in order, copy the files, then turn saving back on:

save-off
save-all flush

tar -czf backup-$(date +%F-%H%M).tar.gz world world_nether world_the_end plugins server.properties

save-on

Always run save-on afterwards. If you forget, the server stops saving the world.

Automate it

A backup you have to remember will be skipped on the day you need it. Pick one route:

• Your host's backup tool, if it has one. Check how often it runs, how many copies it keeps and whether you can download them.
• A backup plugin that runs on a schedule and prunes old copies. Choose one that is maintained for your Minecraft version.
• A scheduled script on the machine (cron on Linux) that runs the commands above through your server's console or RCON, then deletes copies older than a set number of days.

Keep copies somewhere else

If the backups live on the same disk as the server, one disk failure or one hacked account takes both. Follow the simple 3-2-1 idea: three copies, on two kinds of storage, with one off site. In practice that means the live server, a local backup folder, and a copy uploaded to cloud storage or another machine every day. Encrypt or protect the off-site copy, because a world backup contains player data.

How long to keep them

• Hourly or every few hours for the last day, if players build a lot.
• Daily for a week or two.
• Weekly for a month or two.

Keeping some older copies matters because griefing and corruption are often noticed days later.

Restoring, and testing it

Do a practice restore on a spare folder or machine at least once, and again after big changes. That is how you find out the backup is missing a folder, or that the instructions in your head are wrong, while it is still safe to find out.

1. Stop the server completely.
2. Move the damaged world folder out of the way (rename it rather than delete it).
3. Extract the backup's world folder into the server folder.
4. Start the server and check the console for errors, then join and look around.

Frequently asked questions