How to back up and restore a Minecraft server without corrupting your world

A safe Minecraft server backup includes the world folders, plugin data, server configuration, allowlists, permissions, and any external database data needed to rebuild the server. Capture it after a clean save, keep multiple versions, store a copy off the live machine, and test a restore.

A green “backup complete” message proves that files were copied. It does not prove that you can recover.

What to include

For a conventional Paper server, preserve:

• Every world directory, including separate Nether and End folders where applicable.
• plugins/, including plugin configuration and local databases.
• server.properties, Paper configuration, permissions, operators, bans, and whitelist files.
• The server JAR version or a record of its exact build.
• Startup arguments and the Java version.
• External MariaDB or MySQL databases used by plugins.

Backing up only world/ can preserve terrain while losing inventories, permission configuration, economy data, maps, and moderation history.

Make a consistent backup

The safest general procedure is:

1. Tell players about the maintenance window.
2. Run save-all flush if supported by your server version.
3. Stop the server cleanly and wait for the process to exit.
4. Copy or snapshot the complete server data set.
5. Start the server and check the startup log.

Some backup systems coordinate live snapshots safely, but ordinary file copies can catch a region file or plugin database between writes. If you do not know whether the tool coordinates writes, stop first.

Keep more than one recovery point

A single rolling backup can be overwritten after corruption, griefing, or a bad plugin change. Keep several generations across different intervals, for example recent hourly copies, daily copies, and a smaller set of weekly copies.

Retention should match how quickly you notice problems. If players may discover griefing two weeks later, seven daily copies are not enough.

Store a copy off the machine

A backup beside the live world protects against a mistaken file edit but not disk failure, account compromise, or loss of the host. Follow the basic 3-2-1 idea where practical: live data, another copy, and an off-site copy on separate infrastructure.

gummies.cloud uses two layers: a saved VM snapshot for fast node rollback and scheduled off-site server backups for failures that affect the underlying machine. The expected pricing page states the included storage allowance.

Restore without making the incident worse

1. Stop the server and preserve the broken state separately.
2. Confirm the backup date and the server, plugin, and Java versions it expects.
3. Restore into a temporary directory or test instance first.
4. Start it and inspect logs/latest.log.
5. Join and check player inventory, dimensions, claims, permissions, and plugin data.
6. Only then replace the production data or switch traffic.

Never downgrade a world after it has been opened by a newer Minecraft version unless the server software explicitly supports that path. Paper warns operators to back up before updates because plugin problems or accidents may require restoration.

Test restores on a schedule

A quarterly restore drill is better than discovering a missing database during an emergency. Record how long recovery takes and which credentials or external services it requires. A backup that depends on one person's memory is not an operating procedure.

Sources and review

Reviewed July 15, 2026 against PaperMC's update and backup guidance and the Minecraft Wiki server-maintenance tutorial. Product backup claims were checked against the current gummies.cloud pricing and gummysnacks capability sources.