Backing up a Minecraft server before an update

The reason this is not optional

Minecraft converts a world forward when a newer version opens it, and there is no reverse. Region files, entity storage and player data are rewritten in place. The moment the server finishes starting, the old world is gone.

So the backup is not insurance against a mistake. It is the only path back to the version you were on, and if you skip it there is no version of "undo".

Stop the server first

The server writes region files continuously. Copying them while it runs gives you a copy containing half-written chunks, and that corruption often does not surface until somebody walks into that part of the map weeks later.

Stop it properly:

# Whatever your setup uses. The point is a clean shutdown, not a kill.
systemctl stop minecraft

If you genuinely cannot stop it, freeze the writes instead:

save-off
save-all

Copy while it is frozen, then save-on afterwards. Forgetting save-on means the server silently stops saving, which is a far worse outcome than the downtime you avoided.

Back up all of it, not just the world

A world with no configuration is not a server. Take everything that carries state:

tar -czf ~/backups/mc-$(date +%F-%H%M).tar.gz \
  world world_nether world_the_end \
  plugins \
  server.properties \
  bukkit.yml spigot.yml paper-global.yml paper-world-defaults.yml \
  ops.json whitelist.json banned-players.json banned-ips.json \
  permissions.yml

For a modded server, swap plugins for mods and config.

What people forget, in order of how much it hurts:

• Plugin and mod configuration. Weeks of tuning, in files nobody thinks of as data.
• Permissions. Usually its own file or database, and losing it locks out your staff.
• Player data. Inside the world folder for vanilla, but some plugins keep their own.
• Databases. If a plugin uses MySQL, the tarball above contains none of it. Dump it separately.

Restore the backup before you trust it

This is the step that separates a backup from a file, and it is the step everyone skips.

mkdir -p /tmp/restore-test
tar -xzf ~/backups/mc-2026-07-27-0130.tar.gz -C /tmp/restore-test

# Start a server on the OLD version, pointed at the restored world.
cd /tmp/restore-test
java -jar paper-old.jar nogui

Let it start, join it, look around spawn, check that a plugin you configured behaves as configured. Then stop it and delete the test.

If that works, you have a way back. If it does not, you have found out now, with your live server still intact, rather than at two in the morning with players waiting.

Keep more than one

One backup is a single point of failure, and the most common real disaster is not the update going wrong but noticing three days later that it did.

A workable rotation for a small server:

• Before every update, a named backup kept until the update is proven.
• Nightly, kept for a week.
• Weekly, kept for a month.
• One copy off the machine. A backup on the same disk as the server does not survive the disk.

That last one is the difference between an incident and losing the server.

Automating the nightly

#!/usr/bin/env bash
set -euo pipefail

SERVER=/opt/minecraft
DEST=/var/backups/minecraft
KEEP_DAYS=7

mkdir -p "$DEST"
systemctl stop minecraft

tar -czf "$DEST/world-$(date +%F).tar.gz" -C "$SERVER" \
  world world_nether world_the_end plugins server.properties

systemctl start minecraft

# Delete old archives only after a successful new one, so a failing backup never
# eats the last good copy.
find "$DEST" -name 'world-*.tar.gz' -mtime "+$KEEP_DAYS" -delete

set -e at the top is doing real work: without it, a failing tar would still reach the find line and delete the backups it failed to replace.

After the update

Keep the pre-update backup until the server has run a week under real load. Update problems are rarely immediate. They surface when somebody visits a chunk nobody had loaded since the conversion, or when a weekly task runs for the first time on the new version.

See upgrading a server for the order the rest of the update should go in.