Server backup strategy: what, where and how often?
By Datafex Engineering TeamPublished Updated 3 min read
A backup begins to exist not on the day it is taken but on the day the restore is tested. An untested backup is not a backup; it is an assumption.
The 3-2-1 rule
Forty years old and still valid:
- 3 copies (the original data + 2 backups)
- 2 different media
- 1 copy physically elsewhere
At game server scale the practical equivalent is a local backup on the server plus a remote backup on another server or in object storage.
A backup kept on the same machine is not a backup
This is the most common mistake. A backup sitting on the same disk is useless in these scenarios: disk failure, file system corruption, an accidentally deleted directory (with the backup in the same directory), ransomware.
A local backup is only for a quick rollback — undoing a bad configuration change in five minutes, for example. The real protection is in the remote copy.
What should you back up?
| Game / system | Critical data |
|---|---|
| FiveM / RedM | The MySQL database + resources/ + server.cfg |
| Minecraft | World folders + plugin configurations |
| Rust | The saves under server/<identity>/ |
| Metin2 | The account, player and common databases + CONFIG |
| Knight Online / Silkroad | MSSQL data and log files |
| Web hosting | The database + httpdocs + email |
The first five rows of the table are game servers; per-game resource and setup guidance: game server plans. The last row sits apart: on shared hosting all three items are taken through the Plesk panel, while on your own server you build the same job yourself with the commands below (web hosting plans).
Copying files is not enough for a database. Copying the files of a running MySQL produces an inconsistent copy; mysqldump or a consistent snapshot is required:
mysqldump --single-transaction --quick \
-u user -p database | gzip > backup-$(date +%F).sql.gz--single-transaction takes a consistent copy without acquiring locks — this is how you back up a live server without stopping it.
How often?
The answer is found with a single question: how many hours of data loss can you accept? Your backup frequency is that number, not less.
- An active roleplay server: the database every 6 hours, a full backup once a day
- A Minecraft/Rust community server: once a day
- A website: once a day, plus one by hand before a large change
- Static content: once a week
Retention
Keeping only the most recent backup is dangerous: if corruption goes unnoticed for a week, all you have left is the corrupted copy. A simple and sufficient scheme: 7 daily + 4 weekly + 3 monthly.
The restore test
Backups fail to work because this step gets skipped. Once a month:
- Extract the backup into another directory (or onto a test server)
- Restore the database and count the rows
- Load the world save and see the server come up
Trusting an untested backup is worse than taking no backup at all — because it creates a false confidence.
Automation
A backup taken by hand is a backup not taken. Automate it with a systemd timer or cron and set up a notification on failure. A backup job that silently stops running is noticed months later.
How this works at Datafex
On virtual server services the service detail includes an option to take a snapshot, and a snapshot backup can be added while ordering. But backing up the application data inside the server is your responsibility — a snapshot is a photograph of the whole machine and does not guarantee database consistency.