Sauvegarde serveur : guide de reprise pour serveurs de jeu

Sur un serveur de jeu, la chose la plus coûteuse à perdre n'est jamais le matériel : ce sont les données — personnages des joueurs, inventaires, registres de guildes, économie et des mois de progression accumulée. Sans une vraie stratégie de sauvegarde serveur, une seule panne de disque, une requête DELETE malheureuse ou une attaque par rançongiciel peuvent disperser votre communauté en une nuit. Ce guide montre comment combiner sauvegardes automatiques, copie hors site et plan de restauration testé en un seul système cohérent.

Que faut-il réellement sauvegarder ?

Beaucoup d'administrateurs ne sauvegardent que la base de données et découvrent, lors d'un sinistre, que la moitié du serveur manque. Une récupération complète nécessite toutes ces couches :

• Base de données : les données joueurs, comptes et économie dans MySQL/MariaDB. C'est là que réside la vraie valeur.
• Fichiers du jeu : le cœur du serveur (binaire), les fichiers de quêtes, les réglages et les données de carte.
• Configuration : services nginx/systemd, règles de pare-feu, définitions cron.
• Contenu téléversé : logos des joueurs, ressources du site web, archives de logs.

Une règle pratique : si vous deviez reconstruire le serveur de zéro, les fichiers qui, une fois remis en place, font tout refonctionner sont ceux qui doivent figurer dans votre sauvegarde.

La règle 3-2-1

Le standard du secteur est simple mais puissant : 3 copies de vos données, sur 2 supports différents, dont 1 entièrement hors du serveur. Une sauvegarde posée sur un seul VPS n'est pas vraiment une sauvegarde : si le serveur meurt, la sauvegarde meurt avec lui. La copie hors site est ce qui vous maintient en vie même si le centre de données de votre hébergeur brûle.

Sauvegardes automatiques de la base de données

Pour la base de données, mysqldump est le point de départ le plus fiable. Utilisez un dump transactionnel afin de capturer un instantané cohérent plutôt qu'une table à la fois :

#!/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"

# supprimer les sauvegardes de plus de 14 jours
find "$DEST" -name 'game_*.sql.gz' -mtime +14 -delete

--single-transaction prend une copie cohérente sans verrouiller vos tables InnoDB ; vous n'avez donc jamais besoin d'arrêter le serveur en production. Lancez le script avec cron :

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

Cette ligne fait une sauvegarde toutes les six heures. Un serveur très actif préférera une fréquence horaire, une petite communauté quotidienne. Définissez votre tolérance à la perte (RPO — la quantité maximale de données que vous pouvez vous permettre de perdre) et choisissez l'intervalle en conséquence.

Sauvegardes incrémentielles pour les fichiers

Tout recopier à chaque fois gaspille espace et bande passante. rsync ne transfère que ce qui a changé, et avec --link-dest il crée des instantanés qui partagent les fichiers inchangés via des liens physiques (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

Chaque instantané ressemble à une copie complète mais n'occupe d'espace que pour les fichiers réellement modifiés.

La copie hors site

Une fois vos sauvegardes locales prêtes, envoyez-les hors du serveur. rclone fonctionne avec des dizaines de fournisseurs de stockage comme Backblaze B2, Wasabi et S3, et peut chiffrer le transfert :

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

Utilisez le chiffrement côté client (rclone crypt) lorsque c'est possible, afin que le fournisseur de stockage ne voie jamais le contenu de vos fichiers. Si votre synchronisation autorise la cible distante à supprimer des sauvegardes, activez le versionnage des objets ou le verrouillage en écriture du fournisseur : ainsi, même si un rançongiciel efface vos sauvegardes locales, une version plus ancienne survit dans le cloud.

L'étape la plus critique : tester la restauration

Une sauvegarde non testée n'est pas une sauvegarde, c'est un vœu. Faites régulièrement un véritable exercice de restauration : déployez la sauvegarde sur un serveur de test vide et vérifiez que le serveur revient réellement à la vie.

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

Mesurez trois choses lors de cet exercice : le dump est-il corrompu (contrôle d'intégrité avec gzip -t), combien de temps prend l'import (votre RTO — objectif de temps de reprise), et les données de personnages et d'économie sont-elles cohérentes. Quinze minutes de répétition une fois par mois vous épargnent des heures de panique lors d'un vrai sinistre.

Questions fréquentes

À quelle fréquence dois-je sauvegarder ?

Cela dépend de la perte de données que vous pouvez accepter. Sur un serveur PvP actif, les joueurs sont sensibles à la progression horaire ; une sauvegarde horaire de la base de données a donc du sens. Sur des serveurs plus calmes, un intervalle de six heures ou quotidien suffit. Les fichiers ne doivent être sauvegardés que lorsque vous les modifiez réellement.

Garder la sauvegarde sur le même serveur suffit-il ?

Non. Une sauvegarde sur le même disque est inutile en cas de panne de disque, et une sauvegarde sur le même VPS est inutile si le serveur s'effondre. Au moins une copie doit résider dans un emplacement totalement différent — stockage cloud ou autre centre de données.

Puis-je faire une sauvegarde cohérente sans arrêter le serveur en production ?

Oui. Pour les tables InnoDB, mysqldump --single-transaction fournit un instantané cohérent pendant que le serveur tourne. Côté fichiers, rsync est compatible avec un serveur en cours d'exécution ; avoir de nombreux fichiers séparés plutôt qu'un seul énorme fichier sans cesse réécrit rend simplement l'opération plus fluide.

Construisons ensemble le plan de sauvegarde et de reprise de votre serveur. Pour concevoir des sauvegardes automatiques, une copie hors site chiffrée et un flux de restauration testé, contactez-moi.