Server Backup: Game Server Disaster Recovery Guide

On a game server the most expensive thing you can lose is never the hardware — it is the data: player characters, inventories, guild records, the economy and months of accumulated progress. Without a solid server backup strategy, a single disk failure, a mistaken DELETE query or a ransomware hit can scatter your community overnight. This guide shows how to combine automated backups, an offsite copy and a tested restore plan into one coherent system.

What you actually need to back up

Many admins back up only the database and discover during a disaster that half the server is missing. A complete recovery needs all of these layers:

• Database: the player, account and economy data inside MySQL/MariaDB. This is where the real value lives.
• Game files: the server core (binary), quest files, settings and map data.
• Configuration: nginx/systemd services, firewall rules, cron definitions.
• Uploaded content: player logos, website assets, log archives.

A practical rule: if you had to rebuild the server from scratch, whatever files make everything work again when you put them back are the files that belong in your backup.

The 3-2-1 rule

The industry standard is simple but powerful: 3 copies of your data, on 2 different media, with 1 of them completely off the server. A backup that sits on a single VPS is not really a backup — if the server dies, the backup dies with it. The offsite copy is what keeps you alive even if your provider's data center burns down.

Automated database backups

For the database, mysqldump is the most reliable starting point. Use a transactional dump so you capture a consistent snapshot rather than a single table at a time:

#!/bin/bash
set -euo pipefail
STAMP=$(date +%F_%H%M)
DEST=/var/backups/db
mkdir -p "$DEST"

mysqldump --single-transaction --quick --routines \
  --databases player account log \
  | gzip > "$DEST/game_$STAMP.sql.gz"

# delete backups older than 14 days
find "$DEST" -name 'game_*.sql.gz' -mtime +14 -delete

--single-transaction takes a consistent copy without locking your InnoDB tables, so you never have to stop the live server. Run the script with cron:

# crontab -e
0 */6 * * * /opt/scripts/db_backup.sh >> /var/log/db_backup.log 2>&1

This line takes a backup every six hours. A busy server may want hourly, a small community daily. Decide your tolerance for loss (RPO — the maximum amount of data you can afford to lose) and pick the interval to match.

Incremental backups for files

Copying everything every time wastes space and bandwidth. rsync transfers only what changed, and with --link-dest it creates snapshots that share unchanged files as hard links:

rsync -a --delete \
  --link-dest=/var/backups/files/latest \
  /srv/gameserver/ \
  /var/backups/files/$(date +%F_%H%M)/
ln -sfn /var/backups/files/$(date +%F_%H%M) /var/backups/files/latest

Each snapshot looks like a full copy but only occupies space for the files that actually changed.

The offsite copy

Once your local backups are ready, push them off the server. rclone works with dozens of storage providers such as Backblaze B2, Wasabi and S3, and can encrypt the transfer:

rclone sync /var/backups remote:game-backup \
  --transfers 4 --checksum --log-file /var/log/rclone.log

Use client-side encryption (rclone crypt) where you can, so the storage provider never sees the contents of your files. If your sync lets the offsite target delete backups, enable the provider's object versioning or write-lock feature — that way, even if ransomware wipes your local backups, an older version survives in the cloud.

The most critical step: test the restore

An untested backup is not a backup, it is a wish. Run a real restore drill regularly: unpack the backup onto an empty test server and confirm the server actually comes back to life.

gunzip < game_2026-06-28_0600.sql.gz | mysql -u root -p

Measure three things in this drill: whether the dump is corrupt (integrity check with gzip -t), how long the import takes (your RTO — recovery time target), and whether character and economy data are consistent. Fifteen minutes of rehearsal once a month saves you hours of panic during a real disaster.

Frequently Asked Questions

How often should I back up?

It depends on how much data loss you can accept. On an active PvP server players are sensitive to hourly progress, so an hourly database backup makes sense. On calmer servers a six-hour or daily interval is enough. Files only need backing up when you actually change them.

Is keeping the backup on the same server enough?

No. A backup on the same disk is useless during a disk failure, and a backup on the same VPS is useless if the server collapses. At least one copy must live in a completely different location — cloud storage or another data center.

Can I take a consistent backup without stopping the live server?

Yes. For InnoDB tables, mysqldump --single-transaction gives a consistent snapshot while the server runs. On the file side, rsync is compatible with a running server; having many separate files rather than one huge constantly-written file just makes it smoother.

Let's build your server's backup and recovery plan together. To design automated backups, an encrypted offsite copy and a tested restore flow, get in touch with me.