Minecraft server backups: what, how and how often

The short answer: copy the whole server folder except logs and caches, plus dumps of any external databases. Take the copy with the server stopped or after save-off and save-all flush, on a schedule, and always before updates. How often depends on how much player progress you can afford to lose.

What to back up#

You can skip logs, cache, libraries, versions and plugins/.paper-remapped — Paper recreates them. Before moving to 26.x, put a copy aside and keep it for a long time: Paper warns that once a world is upgraded to 26.1, you can't downgrade.

The 3-2-1 rule#

The classic backup rule: 3 copies of your data, on 2 different media or storage systems, 1 of them somewhere else. For a Minecraft server that means the live files, recent archives on the same machine for quick rollbacks, and a copy on another machine or in cloud storage.

A copy on the same disk saves you from a griefer or a bad update, but not from a dead disk, a hacked VPS or a host closing your account. So at least one copy must live elsewhere — and must not be deleted automatically whenever the local one is.

How to back up without corrupted chunks#

The server keeps writing chunks to disk. Copy a world “on the fly” and the archive may catch a half-written region file — restore it and part of the world may come back damaged. There are two reliable ways.

Stop the server. Shut down, copy, start. Couldn't be simpler, and it fits nicely into a nightly restart. Copy without stopping. Console commands (operator level 4):

save-off          # stop writing the world; changes are queued in memory
save-all flush    # write all chunks and players to disk right now
# … copy the files …
save-on           # resume writing the world

save-all flush freezes the server for a moment — that's expected. What matters is not forgetting save-on: while writing is off, the world isn't saved, and a crash loses everything unsaved. After a restart the server saves the world on its own again. Player, advancement and statistics files are still written during save-off.

Automation: a script and cron#

Manual backups last until the first time someone forgets. On a VPS, a short script and cron are enough. The example below assumes the server runs in a tmux session called mc: the script sends console commands with tmux send-keys. Replace the paths and database name with yours.

#!/bin/bash
# backup.sh — back up a Minecraft server without stopping it
set -euo pipefail

SERVER=/srv/minecraft          # server folder
DEST=/backups/minecraft        # where backups go
STAMP=$(date +%F_%H-%M)
mkdir -p "$DEST"

# the server runs in a tmux session called "mc"
tmux send-keys -t mc "save-off" Enter
trap 'tmux send-keys -t mc "save-on" Enter' EXIT   # turn saving back on even if the script fails
tmux send-keys -t mc "save-all flush" Enter
sleep 30                       # give the server time to finish writing chunks

# tar exit code 1 means "file changed as we read it": a warning, not an error
tar -czf "$DEST/server-$STAMP.tar.gz" -C "$SERVER" \
  --exclude=./logs --exclude=./cache --exclude=./libraries --exclude=./versions . || [ $? -eq 1 ]

tmux send-keys -t mc "save-on" Enter
trap - EXIT

# plugin MySQL databases (DGuard's dossiers too); credentials live in ~/.my.cnf
mysqldump --single-transaction --databases minecraft > "$DEST/db-$STAMP.sql"

# keep 14 days locally, ship a copy to another machine
find "$DEST" -type f -mtime +14 -delete
rsync -a "$DEST/" backup@backup.example.com:/backups/minecraft/

--single-transaction makes mysqldump take a consistent snapshot of InnoDB tables without locking them for your plugins. rsync runs without --delete on purpose: if someone wipes the local archives, the remote copy survives. Make the script executable (chmod +x) and add it to cron (crontab -e):

# every day at 05:00
0 5 * * * /srv/minecraft/backup.sh >> $HOME/mc-backup.log 2>&1

Build the date in the script, not in the cron line: there an unescaped % turns into a newline. Game hosts usually have built-in backups in their panel — turn on the schedule and find out where the copies are stored; if they sit on the same machine, download a fresh one to your side every week.

How often to back up#

• On a schedule — at least daily for a live server, more often for a busy one. The rule of thumb is simple: how many hours of player progress can you afford to lose?
• Before anything risky — updating Paper or the Minecraft version, installing or updating plugins, big config changes, a wipe or an event.
• With rotation — keep copies from several points in time, not just the latest one: Paper recommends having backups from multiple times. Corruption or griefing is often noticed days later, when yesterday's copy already contains the problem.

Restoring and testing#

1. 1

   Stop the server

   Never restore files under a running server: it will overwrite them with its own data.

2. 2

   Set the current files aside

   Don't delete — rename the server folder (say, to minecraft.broken) in case you need something from it.

3. 3

   Unpack the archive

   mkdir /srv/minecraft && tar -xzf server-<date>.tar.gz -C /srv/minecraft

4. 4

   Load the databases

   A dump made with --databases creates the databases itself: mysql < db-<date>.sql.

5. 5

   Start and check

   Join the game: are the builds, inventories, claims and permissions there? Watch the console for plugin errors.

A backup you've never restored is a hope, not a backup. Once a month, unpack a fresh archive onto a test server in a separate folder on a different port. tar -tzf <archive> > /dev/null is a quick integrity check.

Undoing griefing without restoring the world#

Restoring the whole world from a backup rolls back every player's progress because of one griefer. That's what a block logger is for: CoreProtect records who broke, placed or took what, and rolls back a single player's actions: /co rollback u:<name> t:1h r:20. Keep backups for disasters: world corruption, a failed update, a lost VPS. Other measures are in grief protection.

You'll roll back less often if you catch the people who wreck the world with cheats. DGuard checks Nuker, FastBreak and Scaffold along with every other cheat in the comparison. A plugin anticheat can't see X-ray — Paper's anti-X-ray handles that, see X-ray protection.

FAQ#