A backup you have never restored is only a rumour. That one sentence is the whole discipline, and most servers learn it the hard way, on the day a world corrupts or a plugin update eats a config and the backup turns out to have been silently failing for a month. This post covers what to back up, how often, where to keep it, the difference between host-side snapshots and plugin-based backups, and the one habit that separates a real backup from a hopeful one, which is actually testing a restore.

This is part of the wider job in running a Minecraft SMP, where keeping tested backups running is one of the standing chores rather than a one-off setup step.

What to back up

Three things, in rough order of how much it hurts to lose them.

The world folders come first, because they hold everything players have built and every change they have made. On a typical server that is the overworld, the nether and the end, each in its own folder, and if you run extra worlds like a resource world you want those too, or at least a clear decision that losing them is fine.

Plugin data and configs come next, and people forget them constantly. Land claims, permissions, economy balances, homes and warps all live in plugin data folders, not in the world, so a backup of the world alone can restore the map and still lose every claim and rank on it.

The whole server is the clean option: the entire server directory, jar, configs, plugins, worlds and all. It is larger, but it is the version you can drop onto a fresh machine and have running with nothing missing. For most owners a full server backup on a sensible schedule, plus more frequent world-only backups in between, is the right shape.

How often

Match the frequency to how much work you are willing to lose. A busy SMP where people build for hours every evening wants frequent backups, so a bad event costs minutes rather than a whole session. A quiet server that changes little can back up less often without much risk.

A common and sane pattern is frequent automatic backups of the world during the day, a full backup once a day, and a longer retention chain so you can go back further than yesterday. The retention matters as much as the frequency, because some problems are not noticed immediately. A corrupted region or a griefing incident might be discovered days later, and if every backup you hold is from after it happened, you have faithfully backed up the damage.

Keep a copy off the machine

A backup that lives on the same machine as the server protects you against exactly one thing: deleting or corrupting a file while the hardware keeps working. It does nothing if the disk dies, the machine is lost, or the whole box goes away. The fix is an off-site copy, meaning a backup stored on a separate machine, ideally in a separate place.

A backup on the same disk as the live world is barely a backup at all. Pull at least one copy off the server, to another host, a storage box, or an object store you control, so that losing the server does not also lose your way of rebuilding it. We follow the same principle with our own infrastructure, and the reasoning behind reserved, non-shared hardware in our stack is part of why the underlying disks are RAID 1 in the first place, though disk redundancy is not a backup either and should never be mistaken for one.

Host-side snapshots versus plugin-based backups

There are two broad ways to take the backup, and they are complementary rather than rivals.

Host-side snapshots are taken below Minecraft, by the panel or the platform, of the files or the volume. They capture everything on disk without caring what a plugin is or how it stores data, they can be scheduled outside the server process, and they are the natural home for the full-server and off-site copies. The one caution is consistency: a snapshot taken while the server is mid-write can catch a world in an inconsistent state, so the better tools either quiesce writes or lean on the server saving cleanly first. Our panel makes this easy by taking scheduled backups you can set once and forget, so the full-server copy keeps happening without you thinking about it. That is the natural home for your main backup routine.

Plugin-based backups run inside the server, so they can flush the world to disk first with a save, then archive a clean copy, and they can be convenient for quick, frequent world captures. The trade is that they run in the server process and cost some resources while they work, and they only know about what the server knows about. On our panel you generally will not need one, because the scheduled panel backups already cover the full-server copy. If you self-host elsewhere, a backup plugin is the way to get the same result from inside the server, flushing the world with a save and then archiving and uploading a clean copy on a schedule.

CoreProtect is a rollback tool, not a backup

This one catches people out, so it is worth stating plainly. CoreProtect logs block changes and lets you roll back specific edits, which is brilliant for undoing griefing: you can reverse what one player did in an area over a time window without touching anyone else's work. It is one of the most useful plugins on an SMP for exactly that.

It is not a backup. CoreProtect records changes to blocks, it does not hold a restorable copy of your world, your plugin data or your configs. If the world file corrupts, if the disk dies, or if you need the whole server back, CoreProtect cannot give it to you. Run it for what it is good at, undoing grief in seconds, and run real backups alongside it for everything else. Treating a rollback log as your disaster plan is how people discover, too late, that the two are not the same thing.

Test the restore

Everything above is setup. This is the discipline. A backup proves itself only when you restore it, and until you have actually pulled a backup and stood a working server up from it, you do not know that it works. Automated backups fail silently all the time: a path changes, a disk fills, credentials expire, and the job keeps reporting success while writing nothing useful. The only way to know is to try.

Set a reminder to restore a backup onto a spare server or a local machine every so often, confirm the world loads, the claims are there and the configs are right, then throw it away. It converts your backups from a rumour into something you can rely on the day you actually need them, which is never a convenient day and never the day to be finding out.

If you want backups handled on hardware built for it, browse our game hosting and we will help you get a tested backup routine running from day one.