Game Server Backups: What to Save and How

Every server owner backs things up eventually. The question is whether you start before or after the incident that teaches you why. The ones who start after can usually tell you the exact date, because it is the date a build they spent months on stopped existing, or the date a plugin update ate every player's inventory, or the date a disk failed at three in the morning and the host's support desk explained, politely, that backups were the customer's responsibility.

This is the unglamorous part of running a server. It is also the part that decides whether a bad day is an inconvenience or the end of the project.

What actually needs backing up

Backing up everything is wasteful and slow, and slow backups get skipped. Backing up too little is worse. Work out what falls into which category and be deliberate about it.

The data that cannot be recreated

World and save data. The obvious one. Terrain, structures, chests, entities — whatever your game persists about the state of the world. This is usually your largest directory and the one nobody can rebuild.

Player data. Depending on the game this lives in a world folder, a separate directory, or a database. Inventories, positions, statistics, permissions, ranks, balances. Losing player data while keeping the world is arguably worse than losing both, because everyone logs in to a world they recognise and finds themselves stripped.

Configuration. Your server properties, permission files, plugin or mod configs, whitelist and ban lists, MOTD, spawn settings. Individually small. Collectively representing weeks of fiddling that you will not remember how to reproduce. Configuration compresses to almost nothing, so there is no excuse for leaving it out.

Plugin and mod data directories. This is the one people miss. Land claims, economy balances, quest progress, shop stock, ticket histories — plugin state usually lives in the plugin's own folder, not in the world. A backup that captures the world and not this leaves you with intact terrain where nobody owns their own base.

Custom content you made. Schematics, resource packs, scripts, custom maps. If it exists only on the server, it needs backing up.

What you can skip

The game server binary and the mods or plugins themselves. These are downloadable. Keep a text file listing exact versions of everything, and that list is worth more than the JARs — it lets you rebuild identically and it is a few kilobytes. Version matters enormously on restore, so write down the specific build number, not just the name. If you run Paper, Purpur or Fabric, the exact build you were on is part of your recovery information.

Logs. Useful for a short window when investigating an incident, worthless a month later, and large. Keep recent ones, let old ones rotate away.

Caches, temporary files and crash dumps. Regenerated automatically. Excluding these often cuts backup size substantially.

Anything you could redownload in ten minutes. If it exists on the internet, back up the pointer, not the payload.

Copying files while the server runs will bite you

Here is the failure that produces backups which look fine and are not.

A running server holds files open and writes to them continuously. Region files, player files, databases — all being modified while your copy job walks the directory. Your backup tool reads file A at the start of the run and file B at the end. In between, the server wrote something touching both. Now A and B disagree with each other, and the archive contains a state that never actually existed.

Sometimes this is harmless. Sometimes you get a world that loads with a corrupt chunk, or a player database that will not open, or a chest that contains items still recorded as being in someone's inventory. The nastiest version is a backup that appears complete, sits in your rotation for months, and fails only on the day you need it.

What to do instead

Stop the server, back up, start it. The simplest correct answer. A brief scheduled restart in the small hours is not a hardship and it flushes everything to disk cleanly. Many owners restart daily anyway.

Flush and pause writes. Some games and server software let you force everything to disk and temporarily suspend world saving. Minecraft-family servers have commands for exactly this: save everything, disable autosave, copy, re-enable. This is the standard approach and it works well, provided you always re-enable saving — a script that fails partway through and leaves autosave off is its own disaster.

Use a filesystem snapshot. If your host offers it, a snapshot captures the whole filesystem at one instant, which sidesteps the inconsistency problem entirely. You copy from the snapshot at your leisure. Not everyone has this available, but if you do, use it.

Back up databases with the database's own tools. Covered further down, because this is where people most often get it wrong.

Whatever you pick, script it so it always happens the same way. A backup procedure that depends on you remembering the steps is a backup procedure that will be performed incorrectly the one time it matters.

How often, and the question that decides it

Frequency arguments go in circles until you reframe them. Do not ask how often to back up. Ask how much progress your players can lose before they stop playing.

That number is your interval. Everything else follows.

A creative or build-focused server where people work on projects across long sessions cannot afford to lose much — an hour of careful building is a real loss and people will not simply do it again. A server where sessions are short and progress resets regularly can tolerate far more. The answer differs by server, and it differs by what your players are actually doing.

Some rules of thumb that survive contact with reality:

More frequent backups near events. Before a plugin update, before a version upgrade, before a large change to your configuration, before a big build event. Take one manually. These are the moments something breaks, and a backup from twelve hours ago is much less useful than one from ten minutes ago.

Back up before anything you would describe as an experiment. If you are about to try something and you are slightly unsure, that feeling is the signal.

Do not confuse a scheduled wipe with a backup strategy. Games with regular wipe cycles create a false sense of safety, because losing data is already part of the rhythm. It is not the same thing. A wipe on a small Rust server is announced, expected and planned around; players clear their schedule for it. An unplanned loss two days after wipe destroys everything they built in the window they cared most about. Games like Rust and 7 Days to Die need backups exactly as much as persistent ones — arguably more, because the value of a given day's progress is concentrated rather than spread out.

Keep more frequent recent backups and fewer old ones. This is retention, and it deserves its own section.

Get the backup off the machine

A backup on the same server as the original is not a backup. It is a copy, and it protects you against exactly one class of problem: you deleting something you shouldn't have.

It does not protect you against disk failure, because both copies live on the disk. It does not protect you against the host suspending or losing your account, because both go together. It does not protect you against ransomware or an attacker with access, because anyone who can reach the live data can usually reach the backup sitting beside it. It does not protect you against an accidental wipe of the whole instance.

Those are the scenarios that actually end servers.

So the rule: at least one copy somewhere else. Somewhere else means a different machine, ideally with different credentials, ideally at a different provider. Object storage, a second box, a machine at your house, an external drive you plug in weekly. The method is less interesting than the separation.

Some practical notes. Pulling backups from a separate machine is safer than pushing from the server, because it means a compromised server cannot reach in and delete your archives. If your remote copy uses credentials stored on the game server, those credentials should be able to write new files and not delete old ones. Storage that supports write-once or versioned objects is worth using if it is available to you, and if you are already weighing hosting spend, offsite storage is a small line item compared to what it protects — the breakdown of hosting costs puts it in context.

If you are running a server on a shoestring or on hardware at home, the offsite requirement is not a luxury you skip because the setup is casual. Free and self-hosted setups fail as readily as paid ones — arguably more, and the free Minecraft server route is precisely where losing everything is easiest, because there is often nobody else keeping a copy.

Retention and rotation

Keeping every backup forever is not viable, and it is not useful either. Old backups get large, and a backup from six months ago restores a server nobody recognises.

But keeping only the most recent one is dangerous for a specific reason: some damage is silent. Corruption creeps in. A griefer works quietly over a week. A plugin misconfiguration slowly mangles data. If you only keep yesterday's copy, and the problem started a fortnight ago, every backup you have contains it.

The standard shape is a tapering schedule. Keep several of the most recent backups — a day or two's worth at your normal interval. Keep one per day for a week or two. Keep one per week for a month or two. Keep one per month for as long as you find it reasonable. You end up with fine-grained coverage of the recent past and coarse coverage stretching back, which matches how you will actually use them.

Two things to get right in the rotation itself. First, it must be automatic; manual pruning gets forgotten until the disk is full and the backup job starts failing silently. Second, monitor that it is running. A backup script that has been erroring for three weeks is worse than no backup script, because you believed you were covered. Have it report success somewhere you will notice — a Discord webhook, an email, anything you actually read.

Test the restore, because nobody does

This is the step everyone skips, and it is the one that determines whether any of the previous sections mattered.

You do not have backups. You have files you believe are backups. The two are different until you have proved otherwise, and the proof is restoring one and watching the server come up.

Reasons a backup that exists still fails on the day: it was taken while the server was running and is internally inconsistent. It silently excluded a directory you assumed was included. The archive is corrupt because the disk was full when it was written. The compression is fine but the world was already damaged when it was captured. You cannot remember the plugin versions and the restored world will not load on the current ones. The transfer from remote storage takes far longer than you expected and your server is offline throughout. The encryption key is on the machine that died.

Every one of those is common. Every one of them is discovered at the worst possible moment unless you look first.

How to actually test

Spin up a second instance somewhere — a local install on your own computer works fine. Restore your most recent backup into it. Start it. Log in. Walk to somewhere you know, check a chest, check a claim, check that a player's inventory and rank are right. Check plugin data, because that is what partial backups drop.

Time it while you do it. Knowing that a full restore takes forty minutes changes how you communicate with your players during an incident, and it is much better to learn that in a calm moment.

Do this when you set the system up, and again whenever something significant changes — a new host, a major version upgrade, a new backup tool. Once or twice a year otherwise. It takes an evening.

One more thing worth testing: restoring a single item rather than everything. Most real incidents are partial. One region file, one player's data, one plugin's folder. If your backup format makes selective extraction painful, you will discover that under pressure. Practise pulling one file out.

After a griefing incident

Something has gone wrong and you are deciding what to do right now. Order matters here.

Stop the damage first. Ban or kick whoever is doing it, or shut the server down if you are unsure of the scope. Do not investigate a live incident on a live server while the culprit is still connected.

Stop your backup schedule before it overwrites good data. This is the step people forget and it is the expensive one. If your rotation only keeps a handful of copies and the incident happened hours ago, the automated schedule is quietly pushing your clean backups out of the window while you read logs. Pause it.

Take a backup of the damaged state. Counterintuitive, but you want it. It is your evidence, and if the restore goes badly you can at least get back to where you were rather than somewhere worse.

Work out when it started. Logs, block records, player reports. The timestamp decides which backup you need, and it is usually earlier than your first guess, because griefing is often noticed well after it began.

Decide between a full rollback and a partial repair. A full rollback is clean and simple but costs every player everything they did since that point, which can turn one person's malice into everyone's grievance. A partial restore — pulling back only the affected region files or player data — preserves the rest but takes longer and is easier to get subtly wrong. For localised damage, partial is usually right. For anything widespread, take the full rollback and tell people plainly.

Tell your players. Explain what happened, what you are restoring to, and what they have lost. People forgive a rollback that is explained. They do not forgive logging in to find their work gone with no message. This applies as much on a busy Garry's Mod or FiveM server as on a small survival world, and how you handle it publicly shapes whether people come back.

The same sequence applies after a bad plugin or mod update, with one addition: roll back the plugin as well as the data, and pin the working version until you have tested the new one somewhere that is not your live server. If the update changed a data format, restoring old data onto the new version may not work at all, which is exactly why that version list matters.

Databases are not flat files

If your server stores data in an actual database — MySQL, MariaDB, PostgreSQL — copying the data directory while it runs is close to guaranteed to produce something unusable. Databases keep state in memory and in write-ahead logs, and a file-level copy of a live database captures a torn state.

Use the database's own dump tool. It produces a consistent snapshot regardless of what is happening at the time, gives you a portable text file, and restores predictably. It is a single command and it belongs in your backup script.

Flat files are more forgiving but not free of risk. Individual files are usually small and self-contained, so a torn copy damages one player's data rather than everything. The trade is that flat-file setups often mean many thousands of small files, which makes backups slow and restores slower.

Two mixed cases worth knowing. Embedded databases — the single-file kind many plugins use by default — are databases, not flat files, and copying them live can produce a file that will not open. Stop the server or use the appropriate tool.

And a server can be both. Many setups keep the world as files and player data in a database, meaning a restore has to bring back two things from the same moment. If your world is from noon and your database from midnight, players get an afternoon's terrain with a midnight inventory, and reconciling that is unpleasant. Back both up in the same job, at the same time, and restore them as a pair.

Games differ in how much of this applies. A Counter-Strike 2 or Left 4 Dead 2 server may have little persistent state beyond configuration and a stats database, making backups almost trivial. A heavily modded survival server has state everywhere. Know which you are before you decide the job is small.

Common questions

How long should I keep backups? Long enough to cover damage you might not notice immediately. A month of coverage, tapering from frequent recent copies to occasional older ones, handles most situations. Extend it if your server has slow-burning risks like long-term griefing or gradual data corruption.

Is my host's backup enough? Treat it as a bonus, not a plan. Host backups are often full-machine images taken on a schedule you do not control, may not be granular enough to pull back one player's data, and disappear along with everything else if your account has a problem with the provider. Keep your own copy as well.

Should I compress and encrypt? Compress, yes — world data compresses well and smaller archives transfer faster. Encrypt if the backups contain player information and are stored somewhere you do not fully control. If you encrypt, store the key somewhere other than the server, and verify you can decrypt an archive as part of your restore test.

Can I back up without any downtime at all? With a filesystem snapshot, effectively yes. With a save-and-pause approach, the server stays up and players may notice nothing beyond a brief moment where new changes are not being written. Full stop-and-copy needs a window, but scheduled at a quiet hour it costs you very little.

How big will backups be? Depends entirely on world size, player count and how much your players explore. Excluding logs, caches and downloadable server files usually cuts the total considerably. Watch the size over the first few weeks rather than guessing, and set your retention to fit the storage you actually have.

Do I need this for a small server with a few friends? Yes, and the setup takes an evening. Small servers lose data the same way large ones do. The difference is that a small server usually has no staff, no redundancy and nobody else keeping a copy, so when it goes, it goes completely. If you plan to grow — to list the server publicly, to attract strangers from a server list, to run something people invest real time in — you want this in place before the players arrive, not after.