Backup Strategies for Game Servers: What's Included, What to Configure, and What to Test

There’s a familiar pattern with game-server backups: nobody thinks about them, until the day you need one. Then you discover you don’t have any, or the latest backup is from before the corruption you’re trying to recover from, or you can’t remember how to restore.

This post walks through the backup features that ship with Witchly servers, how to think about a backup strategy that fits the kind of server you run, and the recovery moves that actually work when something breaks.

What “backup” means on Witchly

A Witchly backup is a point-in-time snapshot of your server’s files — worlds, configs, plugins, mods, data folders, everything in your server’s data directory. Backups are stored separately from the running server, so they survive even if the server itself crashes, gets corrupted, or is rebuilt.

You can:

• Create backups manually from the dashboard whenever you want (e.g., before a big update)
• Schedule automatic backups via the Schedules tab (e.g., daily at 4 AM)
• Lock backups so they’re not rotated out when you hit your plan’s backup cap
• Download backups to your local machine as a tarball
• Restore from a backup to roll the server back to that snapshot
• Truncate during restore (wipe newer files first, optional) to ensure a clean rollback

Backups don’t include things outside the server’s data directory — for example, your account-level settings, dashboard preferences, or other servers’ data. Each server’s backups are self-contained.

Backup limits per plan

The number of backups you can keep is set by your plan, not by disk space. When you exceed the limit, the oldest unlocked backup is automatically rotated out to make room for the new one.

Tier	Typical backup limit
Free	0 backups (the slot/feature is shown but disabled — see below)
Elite (Construct/Scout-tier)	1 backup
Elite (Reactor/Explorer-tier)	2 backups
Elite (Mainframe/Creator-tier)	5 backups

Check your specific plan’s allowance on the Pricing page — the backup count is listed in each plan card.

The free tier doesn’t include backups by default. You can still take manual export/download operations of files via SFTP if you want a one-off snapshot — see the SFTP doc — but the integrated backup-and-restore flow is an Elite feature.

If you need more backups than your plan allows, the dashboard’s upsell card in the Backups tab points you to the next plan up — that’s not the only path, but it’s the cleanest one.

How automatic scheduling works

The Schedules tab in your server’s manage page lets you set up cron-style automation for power actions, commands, and backups. Most users want a single rule:

Daily at 4:00 AM (your timezone) → Create backup

This runs while your server is least active, captures a fresh snapshot, and rotates the oldest backup out if you’re at your plan limit. For most communities, that’s all the scheduling you need.

Some advanced patterns:

Pre-update safety net

If you push major updates on Saturdays (new modpack version, plugin upgrade, world reset), schedule an extra backup to fire 30 minutes before your update goes out:

Saturday 11:30 AM → Create backup

That gives you a recent rollback target if the update breaks something.

Pre-restart snapshot

Some communities run a daily restart at, say, 5 AM. Take the backup at 4:50 AM — the server is in a stable state, no players have logged on after the previous day’s checkpoint, and the snapshot reflects that day’s full activity:

Daily 4:50 AM → Create backup
Daily 5:00 AM → Restart server

Locked weekly milestone

If you want a weekly “stable state” backup that never rotates out:

1. Schedule the backup to fire weekly on Sunday at 3 AM
2. After it runs, manually lock the backup from the dashboard

Locked backups don’t count against your auto-rotation. They sit there indefinitely until you unlock them. Useful for:

• Big version transitions (“server before we updated to 1.21”)
• Pre-event states (“the world before the build competition”)
• Insurance against catastrophic player misbehaviour you might want to roll back from

Don’t lock everything — locks count against your backup limit. Locking 5 of 5 leaves you no room for new automatic backups.

Manual backups: when to create one by hand

Even with scheduling, manually-triggered backups are worth the click in a few specific moments.

Before installing a new plugin or mod. New plugins occasionally break worlds (mods that change biome generation, plugins that rewrite NBT tags, etc.). A pre-install backup is your single rollback if the plugin turns out to be the problem.

Before major config changes. Tweaking server.properties, bukkit.yml, or a complex plugin config in ways you’re not 100% sure about? Backup first.

Before letting an admin you don’t fully trust touch the server. Self-explanatory.

Before a player-driven event you want to immortalise. A pre-PvP-tournament backup gives you the option to restore the world to its pre-event state for archival purposes, while the live server continues.

After a particularly meaningful build. Some communities take a “world tour backup” once their players have built something cool, just so the snapshot exists in case the world is later wiped.

The pattern: any time you’d be sad to lose what’s currently on the server, a 30-second manual backup lets you sleep better.

Restoring from a backup

The restore flow in the dashboard is intentionally a two-step confirmation:

1. Click Restore on the backup you want — a dialog opens asking if you really want to roll back.
2. Confirm restore. A second dialog asks if you want to truncate (wipe newer files first) before extracting the backup.

The truncate option matters more than it looks:

• Truncate = OFF (default): The backup’s files overwrite existing ones, but files that exist in the current state but not in the backup remain in place. Useful if the backup is missing something you’ve added since (a plugin you installed yesterday, a config tweak).
• Truncate = ON: The current state is wiped first, then the backup is extracted. The result is bit-identical to the moment the backup was taken. Useful when you want a true rollback with no leftover artifacts from the present.

For corruption recovery (a world is glitched, a plugin scrambled NBT data, something is just wrong), use truncate. For “I want my old config back but keep my new plugins,” leave truncate off.

After restore completes, restart the server to load the restored files cleanly.

Downloading backups for off-platform storage

Click the Download icon on a backup to get a tarball you can save anywhere — your local drive, an external SSD, an off-platform cloud (Dropbox, Google Drive, S3). Witchly stores backups reliably, but the gold standard for important communities is the 3-2-1 rule:

• 3 copies of important data
• 2 different storage media types
• 1 off-site copy

A weekly download to your own storage covers all three. If your server data really matters, this is worth doing.

The downloaded file is a standard tarball you can inspect, extract, and re-upload via SFTP if you ever need to. It’s not a proprietary format.

What backups don’t cover

A few things the backup system doesn’t include:

Player-side data. Resource packs your players downloaded, their custom skins, their local mod configurations — none of that is on the server, so backups don’t cover it. Players are responsible for their own client backups.

External database content (mostly). If your server uses an external MySQL/PostgreSQL/MongoDB instance — a Witchly Application server, or some external host — the connection config is in your server’s backup, but the database content lives elsewhere. Back up databases separately. If you’re using a Witchly database app, manually export it (e.g., mysqldump, pg_dump) on a similar schedule and download those exports.

Things outside your server’s data directory. Nothing system-level is captured — that’s by design.

Time-of-event memory. Once a backup runs, that snapshot is the snapshot. Events that happened in the seconds before the backup might be missed if the backup runs while the server’s still flushing data. Best practice: back up during low-activity windows (4 AM, etc.).

Building a strategy that fits your server

Different server types have different sensitivities. A few profiles:

A small Minecraft survival server (5-20 players)

• One daily auto-backup at 4 AM
• One pre-modpack-update manual backup every couple of weeks
• Weekly download to your own storage if the world means something
• Locked backup before any major version transition

You’ll never need anything more elaborate than this.

A big modded community (50+ players, frequent crashes)

• Twice-daily auto-backup (4 AM and 4 PM)
• Locked weekly milestone backup, kept for at least a month
• Pre- and post-event backups around tournaments / build contests
• Off-platform downloads weekly

The doubled cadence catches more recent corruption. Locks protect long-term milestones.

A creative server with persistent builds

• Daily auto-backup
• Locked monthly milestone (“server state on the 1st of each month”)
• Pre-major-build-event backups
• Off-platform downloads of locked milestones

The lock keeps the milestone alive forever. Players know what state the world will roll back to in worst case.

An automation/dev server (constantly testing)

• Daily auto-backup before your usual restart window
• Manual backup before each significant deploy/test cycle
• Truncate-restore is your friend here — when an experiment breaks the server, roll back cleanly

If you’re using the server as a sandbox, embrace the rollback culture: backup early, backup often, roll back without guilt.

Test your restores at least once

This is the part everyone skips. A backup you’ve never tested isn’t a real backup. Once a quarter (or before any high-stakes event), do a restore test:

1. Create a manual backup — call it “Restore Test [date]”
2. Make a trivial change to the server (rename a file, edit a config value)
3. Restore from the backup you just created
4. Verify the change you made got rolled back

If something doesn’t work, you’ve discovered the problem in a low-stakes moment. If everything works, you’ve confirmed your backup strategy actually does what you think it does.

Wrapping up

Backups are the difference between “world corruption is annoying” and “world corruption is catastrophic.” On Witchly, the system is built into every Elite plan — daily auto-backups, locks for important milestones, downloads for off-platform redundancy, and two-step restore with optional truncation.

The mistake most server owners make isn’t choosing the wrong backup tool. It’s not setting up backups at all because nothing has gone wrong yet. Spend ten minutes on it now and never have to spend ten hours rebuilding a world later.

Read more in the backup management doc and the scheduled tasks doc.