How to Back Up a Minecraft Server and Prove the Backup Works

Servers lose worlds in boring ways: a failed disk, an update that corrupts chunks, a plugin that rewrites files, a mistaken command run on the wrong world. A backup is the only thing that covers all of them, and the only way to know yours works is to restore it.

What a backup is, and what it is not

A backup is a copy of the server's files from a moment in time that you can put back. It is different from a block log. A rollback plugin such as CoreProtect records what players did to blocks and can reverse it selectively, which is ideal for a griefer. It cannot rebuild a world file that was lost or damaged, and it only knows what it logged. You want both, for different jobs.

What to include

• The world folders. On Paper servers, the Nether and the End are separate folders next to the main world.
• The plugins folder and the configuration files, because losing your settings costs as much time as losing a build.
• Plugin data, including databases. If a plugin stores data in SQLite files they are part of the plugins folder; if it uses MySQL or MariaDB you must back that up separately.
• Your start script and notes on versions, so you can rebuild the same server.

You do not need to back up the server jar, which you can download again, but note which version you were running.

When to run it

How often depends on what you can afford to lose. A busy server might back up every few hours and keep a daily copy for a week and a weekly copy for a month. A quiet one might back up once a day. Run backups when few people are online, and keep several generations, not only the latest, because you may not notice damage for days.

A running server is changing files while you copy them. Plugins that create backups usually pause saves briefly or flush them first, which is a reason to prefer one over copying the folder by hand. If you copy by hand, stop the server first or at least turn off auto-save and save once before copying.

Where to keep it

A backup stored on the same disk as the server is lost with the disk. Keep copies somewhere else: another machine, cloud storage or a file server. DriveBackupV2 is a plugin that creates scheduled backups and uploads them to Google Drive, OneDrive or an SFTP or FTP server, so the copy leaves the machine automatically.

Protect the destination as well. Backups contain your players' data and your configuration, which may include passwords and tokens, so restrict who can read them and rotate any credentials that leak.

Restore it at least once

This is the step people skip, and it is the one that matters. Set up a clean test server, restore the latest backup into it and start it. Check the world loads, your builds are where they should be, plugins start with their data and a player can join. Time how long it takes. Write the steps down so someone else can do it at three in the morning.

Do this again after major changes, such as a new version, a new database or a new host, because those are the changes that break restores.

Decide how long to keep things

Backups multiply. Decide a retention rule, for example hourly for a day, daily for a week and weekly for a month, and delete the rest automatically. Block logs grow too: the CoreProtect documentation notes that purging data in game only removes data older than thirty days, so plan database size.

A short checklist

• Worlds, configuration and plugin data are all included.
• Backups run on a schedule without you.
• At least one copy is off the server's machine.
• Several generations are kept.
• You have restored a backup to a test server and written the steps down.