Minecraft server backup: a plan that survives a bad day

A Minecraft server backup has to do one thing: give you back a working world, with player data and plugin configs, after the disk dies, a plugin corrupts a region file, a staff member runs //set air on spawn, or the host closes your account. Most owners have "a backup" that is one zip on the same disk as the server, made by hand three weeks ago. That covers the staff mistake and nothing else.

The fix is not a specific plugin. It is a plan (three copies, two media, one off-site), a way of copying that does not corrupt chunks, a retention rule so the disk does not fill, and a restore you have actually done. This guide gives you each of those, with the currently maintained tools and what off-site storage really costs.

The 3-2-1 rule, translated for a Minecraft server

On our list the median online server has 12 players and 36 percent have five or fewer. At that size a lost world is not a statistic; it is the end of the server, because the eight people who built for three months will not start again. The plan below costs under a dollar a month for a typical world.

What to back up, and what to skip

Skip logs/, cache/, libraries/, versions/ and the server jar itself. They are re-downloadable and often larger than the world. A world that is 4 GB with logs is usually 800 MB without them.

Plugins and mods that are actually maintained

Check the update date before you trust a backup tool with your only copy. As of September 2026:

There is no vanilla /backup command. The only built-in commands are save-all, save-off and save-on, which is why every tool above, and the script below, is built around them.

A DriveBackupV2 config that backs up the world and plugin folders every hour, keeps 20 remote copies and 3 local ones, looks like this:

# plugins/DriveBackupV2/config.yml (the keys that matter)
delay: 60
keep-count: 20
local-keep-count: 3
zip-compression: 1
local-save-directory: "backups"
remote-save-directory: "backups"
backup-list:
  - path: "world"
    format: "world-%FORMAT TIMESTAMP%.zip"
    create: true
  - path: "world_nether"
    format: "nether-%FORMAT TIMESTAMP%.zip"
    create: true
  - path: "plugins"
    format: "plugins-%FORMAT TIMESTAMP%.zip"
    create: true
googledrive:
  enabled: true

Then /drivebackup linkaccount googledrive to authorize, /drivebackup test googledrive to confirm the upload path, and /drivebackup backup to run one now. /drivebackup nextbackup tells you when the next automatic one runs. Adjust format to match the plugin's documented placeholders for your version; the plugin ships an example config with the exact syntax.

The script approach: save-off, copy, save-on

A script on the host is the most robust option because it does not depend on the server being healthy, it works on any server software, and it can back up databases too. The one rule: stop the server writing chunks while you copy. The save commands exist for exactly this. save-off "disables the server writing to the level files" and queues changes; save-all flush writes everything to disk immediately; save-on resumes normal saving.

1. Run the server inside screen or tmux (or with RCON enabled) so the script can send console commands. The example uses a screen session named mc.
2. Install restic on the host. It deduplicates by default, so hourly snapshots of a 2 GB world cost megabytes, not gigabytes, and every repository is encrypted with the password you set at restic init.
3. Create the repository once, pointed at your off-site bucket, and put the credentials in a file only root can read.
4. Schedule the script with cron or a systemd timer. Hourly during the day and a longer retention for the nightly is a good default.

#!/bin/bash
# /opt/mc/backup.sh  (run by cron every hour)
set -e
export RESTIC_REPOSITORY="s3:https://s3.us-west-004.backblazeb2.com/my-mc-backups"
export RESTIC_PASSWORD_FILE="/root/.restic-pass"
export AWS_ACCESS_KEY_ID="..." AWS_SECRET_ACCESS_KEY="..."

say() { screen -S mc -X stuff "$1\r"; }

say "save-off"
say "save-all flush"
sleep 15
restic backup /opt/mc/server/world /opt/mc/server/world_nether \
  /opt/mc/server/world_the_end /opt/mc/server/plugins \
  /opt/mc/server/server.properties /opt/mc/server/config \
  --exclude "*.log" --tag hourly
say "save-on"

restic forget --keep-hourly 24 --keep-daily 7 --keep-weekly 5 --keep-monthly 12 --prune

The forget line is restic's retention policy: it keeps the last 24 hourly, 7 daily, 5 weekly and 12 monthly snapshots and prunes the rest. If the server also uses MySQL, add mysqldump --single-transaction luckperms > /opt/mc/dumps/luckperms.sql before the restic backup line and include the dumps folder.

Off-site storage and what it costs

Prices from the providers' own pricing pages in September 2026. A typical small server world with plugins is 1 to 5 GB; with deduplication, a month of snapshots is usually two to three times that.

For a season reset or a big plugin migration, take a manual full snapshot first and tag it (--tag pre-reset). Our new season guide covers what else to keep from the old map.

Test the restore, on purpose

Every backup plan looks fine until the day it is needed. Once a month, do this on a spare folder or a cheap test VPS:

• Restore the latest snapshot somewhere new: restic restore latest --target /opt/mc/restore-test, or download DriveBackupV2's newest zips and unzip them.
• Start a server from it on a different port with the same jar. It should boot with no "region file corrupt" lines in the log.
• Log in and check your inventory, a claim, your LuckPerms rank and a shop. Those four touch playerdata, claim data, permissions storage and the economy.
• Time it. Write down how long the restore took. That number is your real recovery time, and it tells you whether a 60 GB backup set is worth trimming.
• Check the dates in your remote bucket. A schedule that silently stopped in July is the most common backup failure of all.

What host backups do and do not cover

Most hosts run a panel with a Backups tab. Pterodactyl, the panel many hosts use, stores those either on the same node's disk or in an S3 bucket the host configures, and the host sets how many backups each server may keep. Useful, with limits you should know:

• They live with the host. Local-driver backups sit on the same node; if the node's disk fails, so do they. S3-driver backups survive the node but not the account.
• Slots are few. Two or three slots is common. That is a rollback tool, not a history.
• They copy everything. Logs and cache included, so each slot is larger and slower than it needs to be. Some panels let you set an ignore list; use it.
• They do not stop saving. Panels vary on whether they pause world saving first. If yours does not, a backup taken mid-save can hold a torn region file. Take panel backups during a restart window or right after save-all flush.
• They end with the account. Miss a payment, get suspended, or watch the host close, and the backups go too. That is the copy 3-2-1 says must exist somewhere else.

Use the panel backups for quick rollbacks and keep the off-site copy for everything else. Then make sure players can find a server that will still exist next year: list it, keep the description current, and claim it from its server page so the listing stays yours through a move between hosts.

Quick questions