Backups that work, upgrades that do not break.

Why this matters more than performance

Performance problems are annoying. Data loss ends the server. The two events that cause most losses are an upgrade that a plugin could not survive and a restore that turned out to be incomplete. Both are avoidable with a small amount of preparation.

The goal is not a perfect backup system. It is a copy you can restore, on a schedule you will actually keep, stored somewhere other than the disk the server uses.

What to back up

• The world folders: world/, world_nether/ and world_the_end/ if they exist.
• plugins/: the JARs and, more importantly, the config folders that hold each plugin's settings and data.
• server.properties: small file, large consequences if lost.
• Server configs: Paper's config/ folder if present, plus bukkit.yml, spigot.yml and paper-global.yml.
• Player data: ops.json, whitelist.json, banned-*.json, and usercache.json for reference.
• The server JAR and its exact version: so you can roll back to the same build.

How often, and where

A workable default is a daily backup plus a manual backup before any change to the server JAR, plugins or a Minecraft version. Keep several generations rather than one file, because a corruption that happens before your backup runs will be copied into the next one.

Follow the 3-2-1 idea in a simplified form: at least three copies, on two kinds of storage, with one copy off the machine. In practice that can be a local folder, a second drive and an upload to cloud storage.

• Local copy: fast to restore, useless if the disk dies.
• Second drive: survives a disk failure, not a fire or theft.
• Off-site copy: survives most disasters, slower to download.

Stop the server, or let the backup tool trigger a save first, before copying world files. A copy of a world that is being written can contain a half-finished region file.

Prove the backup works

Once a month, restore a backup to a temporary folder and start a server from it on a different port. Join it, check the spawn, open a chest and walk a few chunks. Then stop it and delete the copy.

C:\Minecraft\Survival            normal server
C:\Minecraft\Survival-restore    copy used for a restore test

Testing on the same port while the real server is running will fail with a bind error. Change server-port in the test copy so the two can run side by side, or stop the real server first.

Planning an upgrade

An "upgrade" can mean a new Minecraft version, a new Paper build or a new plugin version. Treat all three the same way: find out what changed, confirm support, back up, test.

1. Read the release notes. Look for breaking changes, config changes and removed features.
2. Check every plugin. A plugin without a build for the new Minecraft version is a reason to wait.
3. Check Java. Newer Minecraft and Paper versions can require a newer runtime.
4. Back up everything from the "what to back up" list, not just the world.
5. Test on a copy if the server has players who care about the world.

Do not upgrade on the day a new version is released. Plugin authors need time to publish compatible builds, and the first server releases often have fixes within days.

Step-by-step upgrade

1. Announce and stop. Warn players, run stop and wait for the process to exit.
2. Back up. Copy worlds, plugins/, configs and the old JAR to a dated folder.
3. Replace the server JAR. Keep the old one. Download the new build for the target version.
4. Update plugins. Replace only plugins that have a compatible build. Remove ones that do not.
5. Start and watch. Read the console until Done. Note any plugin that fails to enable.
6. Test in game. Check spawn, inventories, plugin commands and a few chunks in each dimension.
7. Keep the old backup for at least a week after the upgrade looks healthy.

Rolling back

If the new version fails, stop the server and restore the old JAR, old plugins and the world from the backup taken before the upgrade. Do not try to downgrade a world that has already been opened by a newer version unless you understand the risk: newer versions can write data an older version cannot read.

This is why the backup must be taken before the first start on the new version. Once the new server has generated or converted chunks, the old copy is the only safe rollback.

World format and version changes

Minecraft upgrades the world format when a newer version opens an older world. That conversion is usually one-way. Going forward is supported; going back is not.

• Keep a copy of the pre-upgrade world until you are sure you will not go back.
• Do not open the world with a newer version "just to look" and then return to the old one.
• Test the conversion on a copy when moving across major versions.

Plugins can also change their data format between versions. Restoring an old world with new plugin data, or the reverse, can produce errors. Restore the world and plugins together as a set.

Automating it

FerNode can take backups from its dashboard, which is enough for many small servers. Whatever tool you use, make sure it:

• Runs while the world is saved, or stops the server first.
• Keeps more than one generation.
• Writes to a location outside the server folder.
• Reports failures instead of failing silently.

Check the backup folder after the first run. A scheduler that has been "working" for a month while writing to a full disk is worse than no scheduler, because it creates false confidence.

The short version

Back up worlds, plugins and configs together, keep several generations, store one copy off the machine and test a restore. Before an upgrade, confirm plugin and Java support, back up, replace the JAR and plugins, then test before inviting players. Keep the old backup until the new version has proven itself.

Tools and a restore drill

The tool matters less than the habit. Any of these can work if it produces a complete, restorable copy:

• FerNode's backup feature for a small server on your own PC.
• A manual ZIP of the world and plugins/ while the server is stopped.
• The host panel's scheduler on a managed server, with off-site copies enabled.
• rsync or restic on a VPS, sending snapshots to separate storage.

Run this restore drill once and write down how long it took:

1. Copy the latest backup to a new folder.
2. Confirm level.dat exists in each world folder and that region files are present and non-zero.
3. Start a server from the copy on a spare port.
4. Join, check spawn, open a chest and walk across a few chunks.
5. Stop the test server and delete the copy.

If the drill fails, the backup was never real. Find out now, while the live server is still healthy, rather than during an outage. A backup that has never been restored is only a hope.