How to Set Up Backups for Your Minecraft Server

Why Backups Are Non-Negotiable

Every Minecraft server will experience data loss at some point. Corrupted chunks from a crash, a griefer who slips past your protections, a plugin update that wipes its own config, or an accidental world delete from the panel, these are not hypotheticals, they are certainties given enough time. The difference between a minor inconvenience and a catastrophic loss is whether you have a recent backup. Servers that lose weeks of player progress rarely recover their community. Players leave because they feel their time was wasted, and that trust is nearly impossible to rebuild.

Backups are cheap insurance. A world file that took months of player effort to build fits in a 2-5 GB archive. There is no excuse for not having automated, tested backups running on every server you operate.

What to Back Up

A complete backup includes more than just the world folder. Here is everything you should include:

• World files: The world/, world_nether/, and world_the_end/ directories (or their equivalents if you use Multiverse). These contain all terrain, player builds, and entity data.
• Plugin configurations: The entire plugins/ directory. This includes YAML configs, JSON databases, schematics, and any flat-file storage your plugins use. Recreating plugin configs from scratch is tedious and error-prone.
• Plugin databases: If plugins use MySQL or SQLite, back up the database files or run database dumps. SQLite databases are stored as .db files in plugin folders and are included when you back up the plugins directory. MySQL databases require a separate mysqldump command.
• Server properties and configs: server.properties, bukkit.yml, spigot.yml, paper-global.yml, and paper-world-defaults.yml. These are small files but critical for restoring server behavior.
• Permission data: LuckPerms stores its data in plugins/LuckPerms/ (for flat-file storage) or in a database. Make sure permission groups and player permissions are included.

You do not need to back up plugin jar files themselves, you can always re-download those. Focus on data and configuration.

Pterodactyl Built-In Backups

If your server runs on a Pterodactyl panel (which is standard at most hosting providers including Astroworld Hosting), you have built-in backup functionality. Navigate to your server's Backups tab and click "Create Backup." Pterodactyl compresses your entire server directory into an archive and stores it. You can download backups to your local machine or restore them with a single click.

The key settings are:

• Backup limit: The maximum number of backups the panel stores. When the limit is reached, the oldest backup is deleted automatically. Set this based on your disk quota, 5-10 is common.
• Ignored files: You can exclude files from backups using a .pteroignore file (similar to .gitignore). Exclude compiled plugin jars, log files, and any large files that don't need backing up.

Scheduling Backups with Pterodactyl

Pterodactyl's Schedules feature lets you automate backups. Go to the Schedules tab, create a new schedule, and add a "Create Backup" task. Set the cron expression for your desired frequency:

0 */6 * * *   <-- every 6 hours
0 4 * * *     <-- daily at 4 AM
0 4 * * 0     <-- weekly on Sunday at 4 AM

For active servers with 20+ daily players, back up every 6-12 hours. For smaller servers, daily backups are sufficient. The schedule runs automatically, you don't need to be online or remember to do it manually.

Manual Backup Methods

If you have SSH access to your server (common on VPS or dedicated hosting), you can create backups manually or with custom scripts:

# Stop the server first to avoid corrupted chunks
# Or use save-all and save-off commands via RCON

# Create a compressed archive
tar -czf backup-$(date +%Y%m%d-%H%M).tar.gz \
  world/ world_nether/ world_the_end/ \
  plugins/ server.properties \
  bukkit.yml spigot.yml paper-global.yml

# Move to backup directory
mv backup-*.tar.gz /backups/minecraft/

For a running server, use the Minecraft save-off and save-all commands before creating the archive to prevent chunk corruption. Send these through RCON or the panel console, wait a few seconds for the save to complete, then create the archive, then run save-on to resume auto-saving.

Automated Backup Scripts with Cron

Combine the manual method with a cron job for fully automated backups:

# crontab -e
0 */6 * * * /home/minecraft/backup.sh >> /home/minecraft/backup.log 2>&1

Your backup script should: save the world, create the archive, upload to off-server storage, clean up old local backups, and log the result. A well-written script takes 20 minutes to set up and then runs silently for months.

Off-Server Backup Storage

Backups stored on the same machine as your server are better than nothing, but they don't protect against hardware failure, data center issues, or accidental deletion of the entire server. Send copies of your backups to a separate location:

• Cloud storage: Use rclone to sync backups to Google Drive, Dropbox, or Amazon S3. Rclone supports dozens of cloud providers and can be called from your backup script.
• Separate VPS: Use rsync or scp to copy backups to a different server. This is the most reliable option if you have access to a second machine.
• Local download: Use the Pterodactyl panel's download button to pull backups to your local computer periodically. This is manual but simple.

Testing Restores

A backup that cannot be restored is worthless. Test your backups regularly, at least once a month. The process:

1. Download a recent backup.
2. Set up a test server (locally or on a separate instance).
3. Extract the backup and start the server.
4. Verify that the world loads correctly, plugin configs are intact, player data exists, and economy balances are accurate.

If the restore works, you know your backup process is solid. If it doesn't, you found the problem before a real disaster. Consider using CoreProtect alongside backups for granular block-level rollbacks that don't require a full server restore.

Backup Rotation Strategy

Don't keep every backup forever, disk space fills up fast. A proven rotation scheme:

• Keep the last 7 daily backups.
• Keep 4 weekly backups (one per week, the most recent daily of each week).
• Keep 2 monthly backups (one per month).

This gives you fine-grained recovery for recent events (any day in the past week), reasonable coverage for the past month, and a safety net for older problems. Delete older backups automatically using your backup script or a cleanup cron job. For a server generating 3 GB backups, this rotation uses roughly 40 GB of backup storage, well within most hosting allocations.

Need a server for this? Astroworld Hosting offers NVMe SSD, Pterodactyl panel, and DDoS protection on every plan. See features , plans from €6.39/mo.