Server backup strategy: what, where and how often?
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 |
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
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.