A simple backup routine that will save your server

Most people set up backups after they lose something. A world that took months to build, a config that took a weekend to get right, and then one bad update or one corrupt save wipes it out. This is the routine we wish more server owners had in place before that day, and it's simple enough that you'll actually keep it going.

Start with the 3-2-1 idea, minus the jargon

You might have seen the phrase 3-2-1 backup thrown around. It sounds technical but it's a plain habit once you break it down. Keep three copies of your data. Store them on two different kinds of storage. And keep one of those copies somewhere away from the server itself.

So in practice that might be the live world on your server, a backup saved on the host's panel, and a third copy you pull down to your own machine or push to cloud storage. If one of those fails, you still have the other two. The whole point is that no single bad event takes out everything at once. A drive dies, a panel glitches, you fat finger a delete command. None of those should be the end of your server.

Decide what actually needs backing up

You don't need to back up the whole server folder every time. A lot of it is the game binaries and stuff you can redownload in minutes. What you really care about is the parts you can't get back. For most game servers that comes down to four things.

• The world or save data. On Minecraft that's the world folder (and any nether and end folders). On Rust it's the save files and the map. This is the thing players will riot over if it's gone.
• Your config files. Things like server.properties, paper.yml, spigot.yml, and the config folders for your plugins. Hours of tuning live in here.
• Plugins or mods. Your Paper plugins, your Oxide plugins, your Fabric or Forge mods, plus their data folders. LuckPerms groups and EssentialsX kits matter as much as the jars.
• Any database. If a plugin or your setup uses MySQL or SQLite, that database holds permissions, economy balances, and player data. Back it up separately, because copying the folder while it's live can give you a broken file.

If you want one rule of thumb: back up anything that would make you sad to recreate by hand. Skip anything you could redownload in five minutes.

How often should you run them?

This depends on how busy your server is, and honestly that's the right way to think about it. The real question is how much progress you're willing to lose. If your players build for hours every night, a daily backup means worst case they lose a day. For a lot of people that's the sweet spot.

Here's a rough guide we hand to people who ask.

That last row is the one people forget. Before you update Paper, add a mod, or change a major config, take a backup first. Updates are the single most common way to break a working server, and a thirty second backup turns a disaster into a five minute rollback.

Automated or manual? Mostly automated

Manual backups are fine for one off moments, like right before you mess with something risky. But relying on yourself to remember a daily backup is a losing game. You'll do it for a week, then life gets busy, and the gap right before a crash is exactly when you'll wish you hadn't skipped it.

So automate the routine and keep manual ones for the "I'm about to do something scary" moments. On most control panels, including the Pterodactyl style panel we run at Bytte.cloud, you can schedule backups to run on their own. If you're on a raw VPS, a small cron job does the trick. Something like this, run on a schedule, tars up your world and stamps it with the date so old ones don't overwrite each other.

#!/bin/bash
# simple daily world backup
DATE=$(date +%Y-%m-%d-%H%M)
SRC="/home/mc/server/world"
DEST="/home/mc/backups"

mkdir -p "$DEST"
tar -czf "$DEST/world-$DATE.tar.gz" "$SRC"

# delete backups older than 14 days
find "$DEST" -name "world-*.tar.gz" -mtime +14 -delete

Add it to your crontab with crontab -e and a line like 0 4 * * * /home/mc/backup.sh to run it at 4am. A quick warning though. For Minecraft, copying the world while the server is writing to it can grab a half saved file. Run a save-off and save-all before the copy and save-on after, or just back up while the server is stopped if you can.

The step almost everyone skips

Here it is, the one that actually matters. Test that a restore works. A backup you've never restored is a guess, not a safety net. We've seen people proudly point at a folder full of .tar.gz files that turned out to be empty, or zipped up the wrong directory, or were quietly failing for months because a path changed.

You don't need to do this constantly. Once when you set the routine up, and then maybe once a month, pull a backup down and actually restore it somewhere. Spin up a test server, drop the world in, and load it. Check the configs are there. Check the database imports cleanly. If it loads and looks right, great, now you know. If it doesn't, you just found that out on a calm Tuesday instead of during an emergency.

The day you need a backup is the worst possible day to discover it doesn't work.

Keep a copy off the server

This is the part of 3-2-1 people cut to save effort, and it's the part that saves you when things go really wrong. If every copy lives on the same machine, then one dead drive, one compromised account, or one accidental wipe of the box takes all of them. The backup folder right next to your world is convenient, but it's not protection.

So get at least one copy off the server. Pull it to your home PC on a schedule. Push it to cloud storage with a tool like rclone. Drop it on an external drive once a week. It doesn't have to be fancy. It just has to be somewhere that won't die at the same time as your server. Even a weekly manual download of the latest backup is miles better than nothing.

How long to keep old backups

You don't need every backup forever, and keeping them all will quietly fill your disk. The trick is to keep more recent ones and thin out the older ones. A pattern that works well for most small servers looks like this.

• Keep the last 7 daily backups.
• Keep one backup per week for the last month or so.
• Maybe keep one monthly snapshot if you really care about long term history.

That gives you fine grained recovery for recent days, where most mistakes get noticed, and a few older points to fall back on if something broke a while ago and nobody caught it. The find line in the script above handles the simple version by deleting anything past 14 days. Tune that number to fit your disk and how much history you want.

A quick story about why this matters

A while back someone we know ran a small survival server for a tight group of friends. About eight months of builds, a sprawl of redstone, a town the whole group had chipped away at. They had backups switched on, or so they thought. One night a plugin update corrupted the world on shutdown. No problem, they figured, just restore.

The backups were running fine. They were also backing up the wrong folder, an old test world from setup day. Eight months, gone, and not one usable copy. The group drifted apart not long after. Nobody wanted to start over from nothing.

None of that needed to happen. One test restore, even once, would have caught it instantly. That's the whole reason we keep banging on about testing.

Putting it into practice

You don't need anything complicated. Pick a frequency that matches how active your server is, automate it so you don't have to remember, and make sure one copy lives somewhere other than the server. Then do the one thing nobody does and restore a backup to confirm it actually works. That's the entire routine.

If you'd rather not script it yourself, most of our plans at Bytte.cloud include backup slots you can schedule from the panel, so you can set it once and get on with running your server. However you do it, set it up today, while everything is fine. Future you will be glad it's already running.