Minecraft Server Backups: Guide & Restore 2026

Reliable Minecraft server backups follow three steps: a consistent hot backup sequence via RCON (save-off → save-all flush → copy → save-on), daily automation and at least one offsite copy on EU or German storage. Doing this protects your world from data loss caused by hardware failure, misconfiguration or ransomware.

Quick checklist:

• Enable automatic backups in the control panel or via cron/Docker sidecar
• Check your retention rules: keep a sufficient number of daily copies
• Test a restore before you need it
• Check that the backup destination is in the EU/Germany (GDPR compliance)

For self-hosted servers, the Docker sidecar itzg/mc-backup is the recommended solution. For rented servers, a host panel with automatic, versioned backups requires the least maintenance.

Key takeaways

Reliable Minecraft server backups require daily automated backups, the correct RCON sequence for consistent copies and at least one encrypted offsite copy in the EU.

Table of contents

• Which files must be included in a Minecraft server backup?
• Which methods and tools are suitable for automated backups?
• How do you run safe hot backups with RCON?
• How do you set up itzg/mc-backup with Docker Compose?
• How do you restore a backup reliably?
• How often should you create backups and how long should you keep them?
• Why aren't snapshots enough on their own?
• Which setup is recommended for servers in Germany?
• The configuration I recommend for community servers
• Nexthosting takes care of the backup infrastructure for you
• Sources

Which files must be included in a Minecraft server backup?

If you only back up the world folders, you still lose half your work when disaster strikes. A complete backup includes more than just the region files.

World folders (highest priority):

• world/, world_nether/, world_the_end/ including the subfolders region/, playerdata/, entities/, data/ and level.dat
• On Paper servers, the Nether and End are often separate folders; check the actual directory structure

Server configuration and identity:

• server.properties, whitelist.json, ops.json, banned-players.json, banned-ips.json, usercache.json

Mods, plugins and configurations:

• Back up plugins/, mods/ and config/ completely; matching versions are essential here, since a plugin update can change the configuration structure

Databases and permissions:

• Export MySQL/MariaDB databases with mysqldump before the backup runs
• Export LuckPerms or PermissionsEx data (in-game command or direct file export)

What you can leave out:

• logs/, crash-reports/ and the server JAR itself are not strictly necessary. However, document the server version you use (e.g. paper-1.21.4-build123.jar) so you can download it again if needed.

Pro tip: Put a backup-manifest.txt in the backup archive: server version, date, and a list of active plugins with version numbers. This saves a lot of time when restoring.

Which methods and tools are suitable for automated backups?

There are four proven approaches. Which one fits depends on your setup.

Docker sidecar with itzg/mc-backup

The itzg/mc-backup container runs as a sidecar next to the Minecraft container, coordinates backups via RCON and supports tar, rsync and rclone as backup methods. PRE/POST hook variables allow database dumps before the actual backup. It works well for container setups, but requires basic Docker knowledge and careful volume configuration.

Spigot/Paper plugin “Server Backup”

The Spigot plugin “Server Backup” offers multithreaded backups with support for Dropbox, FTP and Google Drive as destinations, as well as dynamic region backups to save storage. It is easy to install, but check carefully whether the plugin also backs up playerdata/, plugins/ and configuration files completely. Panel buttons are not always complete.

rclone and restic

rclone transfers files to cloud backends such as Dropbox, S3-compatible object storage or WebDAV. Restic adds client-side encryption, deduplication and integrity checking. The two tools can be combined: restic backs up locally, rclone transports to the EU destination. For GDPR-compliant offsite backups to Germany or the EU, this is the most flexible option.

Host panel backups

Many hosting providers offer automatic, versioned backups directly in the control panel. This is the most convenient route: no infrastructure of your own, and often accessible via API. Check the retention depth, GDPR compliance and whether the backup endpoint is located in Germany or the EU.

How do you run safe hot backups with RCON?

If you copy the server while it is running without stopping write operations, you risk corrupt .mca files. The correct sequence is: save-off → save-all flush → copy → save-on.

1. Send save-off: rcon-cli save-off disables automatic saving. The server no longer writes new chunks to disk.
2. Wait for save-all flush: rcon-cli save-all flush physically writes all pending data to disk. This command blocks until the write operation is complete. For large worlds this can take 10–30 seconds; include a sleep 5 buffer.
3. Create the archive: tar -czf /backups/world_$(date +%Y%m%d_%H%M%S).tar.gz /srv/minecraft/world/ creates a timestamped archive. The timestamp in the file name prevents existing backups from being overwritten.
4. Re-enable save-on: rcon-cli save-on re-enables automatic saving. The server keeps running without interruption.
5. Rotate old backups: find /backups -name "world_*.tar.gz" -mtime +14 -delete deletes copies older than 14 days and prevents drives from filling up.

Mind the access permissions: the backup script should run with only the minimum required permissions. Create a dedicated backup user that can write only to the source directory and the backup destination.

Pro tip: For very large worlds (over 5 GB), increase the sleep buffer after save-all flush to 15–30 seconds and check the return value of rcon-cli save-all flush to confirm the command has actually finished before you start copying.

How do you set up itzg/mc-backup with Docker Compose?

The sidecar approach cleanly separates backup logic from the game server. A minimal Compose setup consists of three services: the Minecraft server itself, the backup sidecar and an optional restore init container.

Important environment variables:

• BACKUP_INTERVAL: interval between backups, e.g. 24h for daily or 6h for every six hours
• RCON_HOST: hostname of the Minecraft container, e.g. mc; the sidecar coordinates save-off/save-all/save-on automatically
• INITIAL_DELAY: wait time after container start before the first backup runs; a sensible value is 2m so the Minecraft server has fully started
• BACKUP_NAME / NAME_WITH_VERSION: file name of the archive; with NAME_WITH_VERSION=true the server version is automatically embedded in the file name
• BACKUP_METHOD: tar for simple archives, rsync for incremental copies, rclone for direct cloud uploads

Volume configuration:

The Minecraft server's data volume is mounted read-only in the sidecar. The backup volume is writable only for the sidecar. This way, the sidecar cannot accidentally modify the game world.

PRE/POST hooks:

With PRE_BACKUP_SCRIPT you can run a database dump before the backup. POST_BACKUP_SCRIPT is suited for notifications or upload confirmations.

Pro tip: rclone credentials do not belong in the Compose file. Use Docker secrets or a host-side keyring (e.g. pass or secret-tool) to manage API keys and passwords securely.

How do you restore a backup reliably?

A restore under pressure is not a good time to experiment. Practice the process beforehand on a test instance.

1. Stop the server: Shut the Minecraft server down completely before you touch anything.
2. Rename the existing world, don't delete it: mv world world_broken_$(date +%Y%m%d) keeps the broken version as a fallback. Deleting is final; renaming gives you a second chance.
3. Extract the backup: tar -xzf /backups/world_20260115_020000.tar.gz -C /srv/minecraft/ restores the world to the correct path. Check the file permissions afterward.
4. Start the server and check the logs: Start the server and watch latest.log for chunk errors or missing database connections.
5. Verify player inventories and progress: Log in and check your inventory, spawn point and achievements.

Selective restore of individual player data:

For individual playerdata/UUID.dat files, you need the player's UUID (available via usercache.json). Copy only the affected file from the archive without overwriting the entire world.

Restic workflow:

restic snapshots lists all available snapshots with their IDs. restic restore SNAPSHOT_ID --target /srv/minecraft/ restores the selected state. With restic check you verify the integrity of the repository before the restore.

Verification checklist after the restore:

• Server starts without errors in the logs
• Player inventories and progress are correct
• No chunk errors when entering known areas
• Database connections (MySQL/MariaDB) work
• Optional: compare the SHA256 checksum of the archive against the stored manifest

Pro tip: Never restore directly on the live server if you are not sure. Start a second instance on a different port, load the backup there and check everything at your leisure.

How often should you create backups and how long should you keep them?

For active survival servers, the rule is: automated daily, and manual before every major change. A server update, a new plugin or a big building project are good reasons for a manual backup.

This tiered retention follows the principle also described in industry recommendations for backup strategies: daily incremental copies, weekly full backups and monthly archive copies.

Automation and monitoring:

• Set up a cron job or systemd timer for daily backups
• Call a healthcheck endpoint (e.g. via curl to Healthchecks.io) after every successful backup
• On failure: email or Discord notification
• Perform a full restore on a test instance every month

Pro tip: An untested backup is not a backup. Schedule the monthly restore test as a fixed appointment, not as an optional task.

Why aren't snapshots enough on their own?

Snapshots are point-in-time images on the same storage and do not reliably protect against hardware failure or ransomware. Backups, on the other hand, are independent copies in a different location. This is not a minor difference but the decisive point in a real data loss scenario.

There is also a common misunderstanding: Mojang development snapshots (that is, pre-release versions of the game) are something entirely different from storage snapshots. Automated snapshot pinners that download new server JARs every day manage versions but do not back up player data.

Recommended strategy:

• Snapshots for short-term rollbacks (e.g. after a failed plugin update)
• Encrypted offsite backups for resilience against hardware failure, ransomware and loss of a site
• 3-2-1 rule: 3 copies, on 2 different media types, with 1 offsite

Which setup is recommended for servers in Germany?

The choice depends on whether you host your server yourself or rent it.

Stack A: Rented game server

• Nexthosting game server with automatic, versioned backups and download access via the control panel
• Backup region: check and confirm Germany/EU
• No maintenance effort of your own; restore via the panel in a few clicks.

Stack B: Self-hosted Docker server

• itzg/mc-backup as a sidecar with BACKUP_METHOD=rclone
• rclone destination: S3-compatible EU object storage (e.g. Hetzner Object Storage, Backblaze S3 EU region) or your own Nextcloud/on-premises
• restic for encryption and integrity checking of the backup repository
• For more control and your own Docker environments, a Nexthosting VPS Pro is a good fit

GDPR note:

Player data (UUID, IP addresses, inventories) is personal data under the GDPR. Choose Germany or the EU as the backup destination. Encrypt backups both in transit (TLS) and at rest (restic, VeraCrypt or similar). With cloud services, check whether a data processing agreement is in place.

The configuration I recommend for community servers

Most community servers fail not because of a lack of backup knowledge, but because of a lack of consistency. A perfect backup script that stops running after three weeks because nobody noticed the error is worthless.

My recommendation for small to medium communities: combine automated offsite backups with occasional manual snapshots before risky changes. If you run a rented server, you are better off with a host panel than with self-built infrastructure. The maintenance effort of Docker sidecar setups is real and underestimated. If you cannot or do not want to shoulder it, you should not take it on.

Budget plays a role, but not the biggest one. Even inexpensive EU object storage costs only a few euros per month for typical Minecraft world sizes. The real investment is time: for the setup, for monthly restore tests and for monitoring. If you cannot afford that, you are better served by a managed offering such as Nexthosting, which includes backups as part of the plan.

One last point that is often overlooked: don't just test whether the backup exists, but whether the server actually starts cleanly afterward. Chunk corruption sometimes only shows up when entering certain areas, not at server startup.

Nexthosting takes care of the backup infrastructure for you

If you don't want to run your own backup stack, Nexthosting gives you automatic, versioned backups directly in the control panel, German server locations and simple restores by click or API. No cron job, no rclone setup, no manual monitoring.

Nexthosting Minecraft servers run on NVMe SSDs with DDoS protection and are operated in Germany. Backups are included in the plan and can be retrieved automatically via API. For operators who need more control, VPS options with full root access are available. Set up your Minecraft server at Nexthosting and save yourself the effort of maintaining your own backup infrastructure.

Sources

• Snapshot vs. Backup: Essential insights for effective data protection
• Provides a side-car container to backup itzg/minecraft-server server data
• How to Back Up and Restore a Minecraft Server (26.2) · SyntaxMine
• Server Backup / Ingame / Dropbox / FTP Backup 1.18