Backups that leave the building

A backup on the same machine as the thing it is backing up protects against exactly one failure: you deleting something by hand. It does nothing about a disk dying, a host suspending the account, a ransomware event, or the far more common case of somebody running the wrong command as root.

Every one of those takes the server and the backups together, and the owner discovers the arrangement was never a backup at the moment they need it to have been.

The three-copy rule, minus the folklore

The version worth remembering is short: two copies on different media, one of them off the machine.

That is not a standard anybody enforces and it is the smallest arrangement that survives the failures that actually happen. A local snapshot for fast restores, plus a copy somewhere the server cannot reach with a delete command, covers the realistic range.

The important word is cannot. A backup on object storage that the server holds full credentials for is deleted by the same compromise that deletes the world, which is a lesson people learn once, and it is the reason this belongs in the same pass as locking down what the server can reach.

Write-only credentials are the whole trick

Most object storage lets you issue a key that can upload but not list or delete. Use one.

The server can push a backup and cannot remove or read the others. An attacker with the box has a write key and nothing else, and your history survives. Restoring requires a different credential that lives on your machine rather than the server.

This single change converts off-box storage from "another place it might also be deleted" into a real boundary, and it costs nothing beyond reading the provider's permissions page once.

What to actually copy

More than the world, and that is where most scripts are wrong.

• The world or save data, obviously.
• Plugin and mod configuration — reconstructing this is slower than reconstructing the world, because nobody remembers the settings.
• The database, dumped transactionally, in the same window as the world. A world from 03:00 and a database from 03:40 will disagree about who owns what.
• The plugin and mod jars themselves, at the versions you are running. When an author's repository disappears, your backup is where that file exists.
• The server configuration and the start script.

Exclude logs, caches and anything regenerable. A backup that takes an hour is a backup that gets skipped, and the same restraint applies to what fills the disk in the first place.

Retention that keeps something useful

Daily copies for a week, weekly for a month, monthly for a few. The shape matters because of how corruption is discovered: not immediately.

A world quietly corrupted on Tuesday and noticed on Saturday needs a copy from before Tuesday. Seven daily backups all containing the same damage is a backup regime that ran perfectly and saved nothing.

Test the restore, or it is not a backup

This is the part everybody skips and the only part that proves anything. Take the oldest backup you would ever actually use, restore it somewhere that is not production, start it, and look at it.

Doing this once teaches you the three things nobody knows until they try: how long it actually takes, which credential you did not have, and whether the archive contains what you assumed. It is also exactly the work of standing up a second instance, so the two habits share a setup, and on an hourly-billed box the cost is a rounding error against what the live server costs.

Write down the wall-clock time. That number is your real recovery time, and it is always longer than the guess.

Automate it and then watch it

A cron job that silently stopped three months ago is the most common backup failure of all, because everything about it looks normal — there is no error, no alert, and the directory still contains old files that look current at a glance.

Check the age of the newest backup, not the existence of the directory. A single daily check that the most recent copy is under 26 hours old catches it, and it belongs with whatever else you are already monitoring.

What restoring actually involves, in order

Most backup advice stops at having the file. The restore is where the time goes, and knowing the shape of it in advance is what makes a bad evening survivable.

The order that works: stop the server first, so nothing is writing while you replace files underneath it. Move the damaged data aside rather than deleting it, because you will want it if the restore turns out to be wrong. Restore into place. Start the server with the players still locked out, and check the things that fail quietly — plugin data, permissions, the database connection — before letting anybody in.

The step that gets skipped is the last one, and it is the one that catches a restore that technically succeeded and quietly lost something. A world that loads is not the same as a world with everybody's inventories, and finding out from a player twenty minutes later is much worse than finding out yourself.

How long a restore takes, which is not how long the copy took

The number worth knowing is not the size of the backup. It is how long it takes to get the data back onto the server and running, and it is frequently an order of magnitude longer than the upload was.

A compressed archive downloaded over a modest connection, decompressed onto a disk that is already busy, is an hour for something that took four minutes to create. If the plan is to restore during an incident with players waiting, that hour is the actual recovery time and it should be measured once rather than discovered.

If it is too long, the fix is a second local copy for speed with the off-site copy as the real insurance. The local one handles the ordinary case and the remote one handles the case where the machine is gone.

The ten-minute version

Push to object storage with a write-only key. Include configs, database and jars, not just the world. Keep a week of dailies and a month of weeklies. Restore one, once, and time it. Alert if the newest copy goes stale.

None of it is interesting and all of it is cheaper than the alternative, which is explaining to a server full of people that everything they built is gone, and that the backups were running the whole time, on the disk that failed.