Short answer
Back up the world folder plus server.properties, ops.json and whitelist.json, on a schedule you will keep. Verify a restore once, early, because a backup you have never restored is a hypothesis rather than a plan.
A Minecraft world is a folder of small files being written continuously, and the failures that matter are sudden: a bad plugin, a griefed spawn, a disk that filled, a machine that rebooted mid-write. The only answer to all four is a copy you can put back.
What makes backups fail is rarely the copying. It is backing up an incomplete set, or backing up to the same disk that fails. This guide covers what to copy, how often, where to put it, and how to prove the result.
Before you start
- File access to the server folder
- Space elsewhere for the copies: another disk, or off the machine
- Ten minutes to verify one restore
1. Decide what counts as the server
The world folder is the world. The small files beside it are the server: the rules, the access list, the operators and, if you use them, the plugin configurations. A backup of the world alone restores your map and gives you a server with no players on the whitelist and no plugins configured.
Copy the world folder and those files together. Everything else the server writes, logs and caches, can be regenerated and does not need to be in the archive.
world/ the map, player data, inventories, statistics
server.properties rules, view distance, whitelist switch
ops.json operators
whitelist.json who may join
banned-players.json moderation, if you use it
plugins/ only if you use plugins, and only their configuration folders2. Copy it while the server is stopped, or use a plugin that handles a live server
Copying a live world is copying files that are being written. Chunk files are small enough that a copy usually succeeds and usually ends up subtly inconsistent, which is worse than an obvious failure because you find out during the restore.
So there are two honest options: stop the server, copy, start it; or use a plugin or tool that takes a consistent snapshot while the server runs, which is what the backup panels on hosting services do.
cd /opt/mc
tar -czf backup-$(date +%F-%H%M).tar.gz world server.properties ops.json whitelist.json
tar -tzf backup-$(date +%F-%H%M).tar.gz | headCompress-Archive -Path .\world,.\server.properties,.\ops.json -DestinationPath .\backup.zip3. Choose a schedule and a place
The schedule follows how fast the world changes. A survival world that is played daily should be backed up daily; one touched once a month does not need the same. A weekly archive kept alongside a daily one gives you a longer history for a few extra files.
The place matters more than the schedule. Keep copies on storage that is not the server's own disk: another disk on the machine, a network share, or an external service. One copy, in one place, is one failure away from no copy.
- Daily: a played world. One file per day, kept for two weeks.
- Weekly: an archive of the weekly, kept for a year.
- Before every change: a version upgrade, a plugin install, a big world edit. This is the one that saves you.
4. Verify the copy, and once verify the restore
Two different checks, and the second is the one people skip. Checking the copy means opening an archive and confirming it contains level.dat and the region folder. Checking the restore means actually restoring it somewhere and starting the server against it.
Do the restore test in the first week, on a scratch directory, with nothing to lose. A backup you have never restored is a hypothesis, and this is the cheapest test you will ever run.
tar -tzf backup-2026-10-15-0200.tar.gz | grep -E "level.dat|region/" | head
ls -lh backup-*.tar.gz5. Know what a backup cannot do
A backup restores to a point in time. It does not merge worlds, undo a single player's actions, or recover a world that was damaged before the first backup existed. It is a recovery tool for sudden failures, not a history.
For the case where you need the world as it was an hour ago rather than yesterday, take a copy before anything risky rather than after. That is the habit that makes backups useful, and it costs one command.
Good to know
- Restoring a backup is the other half, and it is the one worth reading before you need it, in an evening rather than at midnight.
- Compressed archives shrink a lot: region files compress well, so a 2 GB world is often a few hundred megabytes zipped. Small archives are suspicious, not reassuring.
- Test the copy by opening it, not by trusting the log. A backup job that reports success while writing an empty file is a common and quiet failure.
- A backup schedule you do not check is an assumption. Look at the list of backups occasionally and confirm the newest one has a plausible size.
Common questions
What does a Minecraft server backup need to include?
The world folder, which holds the map, player data and inventories, plus server.properties, ops.json and whitelist.json. Plugin configuration folders if you use plugins. Logs and caches can be left out.
How often should I back up my server?
As often as the world changes and before anything risky. Daily for a world played every day, and always immediately before a version upgrade, a plugin change or a large edit.
Can I back up a running server?
Not reliably with a plain file copy, because chunks are being written while you read them. Use a backup tool or plugin that takes a consistent snapshot, or stop the server for the copy.
Where should backups be stored?
Somewhere other than the server's own disk. A second disk, a network share or an external backup service. Archives stored beside the world are lost in exactly the failure they exist for.
How do I know a backup works?
By restoring it. Extract an archive somewhere scratch, point a server at it, and start it. Five minutes in the first week, and you stop treating backups as a hope.
Sources
Official documentation this guide was checked against.
Rather not run this on your own machine? PufferHost gives every player a free Minecraft server with 3 GB of RAM and 10 slots. Create a free server.