How to Back Up Your Game Server (Automatically)

A corrupted save after a crash, a griefer's rampage, a bad mod update — any of these can erase hundreds of hours of play. The only real protection is backups that run automatically and live somewhere other than the server itself. Here's how to set that up on Linux.

The three rules of good backups

1. Automated — a backup you have to remember is a backup you'll forget.
2. Off-server — a backup on the same disk dies with the server. Copy it elsewhere.
3. Tested — an untested backup is a guess. Restore one occasionally to be sure it works.

Step 1: Know where your world lives

Every game stores its save differently. Common locations:

• Minecraft: the world folder in the server directory.
• Valheim: ~/.config/unity3d/IronGate/Valheim/worlds_local/.
• Palworld: Pal/Saved/SaveGames/.
• Project Zomboid: ~/Zomboid/Saves/ and ~/Zomboid/db/.

Identify your game's save path before scripting anything.

Step 2: Write a backup script

Create backup.sh. This example archives a Minecraft world with a timestamp and keeps the last 7 days:

#!/bin/bash
SRC="/home/minecraft/server/world"
DEST="/home/minecraft/backups"
STAMP=$(date +%Y-%m-%d_%H%M)
mkdir -p "$DEST"
tar -czf "$DEST/world-$STAMP.tar.gz" "$SRC"
# keep only the 7 most recent backups
ls -1t "$DEST"/world-*.tar.gz | tail -n +8 | xargs -r rm

Make it executable: chmod +x backup.sh.

Step 3: Flush the world before copying

For a clean, non-corrupt backup, tell the game to save first. In Minecraft, run save-off then save-all in the console before archiving, and save-on after. Many admins send these via RCON from the backup script so live players aren't interrupted.

Step 4: Schedule it with cron

Run crontab -e and add a line to back up every night at 4 AM:

0 4 * * * /home/minecraft/backup.sh

For busy servers, back up more often — every few hours during peak play.

Step 5: Get backups off the server

A local backup won't survive a disk failure. Copy archives to another machine or object storage. A simple option is rsync over SSH to a second box:

rsync -az /home/minecraft/backups/ user@backup-host:/backups/mc/

Add that line to the end of your backup script so it runs after each archive.

Step 6: Test a restore

This is the step everyone skips and later regrets. Occasionally, extract a backup into a test folder and confirm the world loads:

tar -xzf world-2026-06-04_0400.tar.gz -C /tmp/restore-test

Point a test server at it and make sure it works. A backup you've never restored is a backup you don't actually have.

How often should you back up?

Match the frequency to how much progress you'd hate to lose. A quiet server with occasional play is fine with a nightly backup. A busy community server where players build for hours every evening deserves backups every few hours during peak time. The retention window matters too: keeping the last 7 daily archives plus a weekly one going back a month protects you against problems you don't notice immediately, like a slow corruption or a griefing spree discovered days later.

Snapshots vs file backups

VPS-level snapshots capture the entire server state and are great for quick full-server rollbacks. File-level backups are better for restoring a single world or moving it to another host. Use both: snapshots for disaster recovery, scripted archives for granular restores.

Where hosting helps

Automated backups need reliable disk performance and often a place to send copies. Nxeon's NVMe VPS gives you full root to run cron jobs and rsync freely, and its snapshot support means you can pair scripted world archives with full-server snapshots for belt-and-braces protection. Set the cron job once, verify a restore, and you'll never lose a world to a bad crash again.