aslain.dev
0%
01 Hizmetler 02 Hakkımda 03 Projeler 04 Stack 05 Blog 06 İletişim
← Tüm makaleler Metin2

Metin2 Backup : sauvegarde automatique avec mysqldump et cron

Gérer un serveur sans stratégie de Metin2 backup, c'est simplement attendre que la panne arrive. Une défaillance disque, une requête DELETE imprudente ou une modification de table ratée peuvent effacer des mois de progression des joueurs en quelques secondes. La bonne nouvelle : avec les outils natifs de MySQL, gratuitement et en quelques lignes de shell, tu peux mettre en place des sauvegardes entièrement automatiques, compressées et planifiées. Dans ce guide, je détaille quelles bases sauvegarder et comment, avec mysqldump et cron sur un serveur Metin2 sous Linux.

Quelles bases de données utilise Metin2 ?

Dans une installation Metin2 classique, la logique de jeu est généralement répartie sur plusieurs schémas distincts. Les noms exacts varient selon la distribution, mais tu trouveras typiquement :

  • account — comptes utilisateurs, mots de passe, e-mail et données de bannissement.
  • player — personnages, inventaire, items, données de guilde, état des quêtes. C'est le schéma le plus critique et le plus souvent modifié.
  • common — proto des items, boutique, mobs et tables de configuration partagées.
  • log — historiques de commerce, de drop et de déplacement des joueurs. Souvent volumineux, mais sa perte n'arrête pas le jeu.

En pratique, les schémas account et player valent de l'or ; en cas de perte de données, la réaction des joueurs en dépend directement. Sauvegarde aussi common, car la seule copie de tes ajustements manuels d'items peut s'y trouver.

Faire une sauvegarde ponctuelle avec mysqldump

Commençons par une sauvegarde manuelle pour confirmer que l'outil fonctionne. mysqldump exporte un schéma entier dans un fichier SQL cohérent sans arrêter le serveur en cours d'exécution :

mysqldump -u root -p \
  --single-transaction --quick \
  --routines --triggers \
  player > player.sql

Les options importantes :

  • --single-transaction : sur les tables InnoDB, prend un instantané cohérent sans verrouiller les tables. Essentiel pour que le jeu ne se fige pas pendant la sauvegarde des données en direct du schéma player de Metin2.
  • --quick : envoie les grandes tables ligne par ligne au lieu de les mettre en mémoire vive.
  • --routines --triggers : inclut aussi les procédures stockées et les triggers.

Pour regrouper plusieurs schémas dans un seul fichier, utilise --databases :

mysqldump -u root -p --single-transaction --quick \
  --routines --triggers \
  --databases account player common > metin2_full.sql

Note : si tu as des tables MyISAM, --single-transaction ne garantit pas leur cohérence ; dans ce cas il faut un faible trafic d'écriture au moment de la sauvegarde, ou --lock-tables.

Écrire un script de sauvegarde

Pour l'automatisation, préparons un script shell réutilisable. On centralise le nom de fichier daté, la compression et le nettoyage des anciennes sauvegardes. Enregistre-le sous /usr/local/bin/metin2-backup.sh :

#!/bin/bash
set -euo pipefail

BACKUP_DIR="/var/backups/metin2"
DBS="account player common"
KEEP_DAYS=14
STAMP=$(date +%F_%H%M)

mkdir -p "$BACKUP_DIR"

for DB in $DBS; do
  mysqldump --defaults-extra-file=/root/.my.cnf \
    --single-transaction --quick \
    --routines --triggers "$DB" \
    | gzip > "$BACKUP_DIR/${DB}_${STAMP}.sql.gz"
done

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

Au lieu de coder le mot de passe en dur dans le script, on le lit depuis un fichier d'identifiants séparé avec --defaults-extra-file. /root/.my.cnf ressemble à ceci et ne doit être lisible que par root :

[client]
user=root
password=UN_MOT_DE_PASSE_FORT
chmod 600 /root/.my.cnf
chmod 700 /usr/local/bin/metin2-backup.sh

La ligne set -euo pipefail rend le script sûr : si une commande échoue, le script s'arrête, évitant ainsi la production silencieuse d'une sauvegarde corrompue ou incomplète.

Planifier avec cron

Après avoir lancé le script manuellement et vérifié avec ls -lh /var/backups/metin2 que les fichiers .sql.gz apparaissent, on peut passer à la planification. Édite la crontab de root :

crontab -e

Pour une sauvegarde complète chaque nuit à 04h00 plus une supplémentaire toutes les 6 heures :

# min h jour mois jsem  commande
0 4 * * *   /usr/local/bin/metin2-backup.sh >> /var/log/metin2-backup.log 2>&1
0 */6 * * * /usr/local/bin/metin2-backup.sh >> /var/log/metin2-backup.log 2>&1

Rediriger la sortie vers un fichier journal (>> ... 2>&1) est important ; le jour où une sauvegarde échoue, c'est là que tu verras pourquoi. Place la sauvegarde complète à l'heure où le trafic des joueurs est le plus bas pour éviter les heures de pointe.

Copie hors site et vérification

Une sauvegarde sur la même machine disparaît avec toi si la machine meurt. Copie les sauvegardes sur un autre serveur ou un stockage objet. Tu peux ajouter une simple ligne rsync à la fin du script :

rsync -az "$BACKUP_DIR/" backup@serveur-sauvegarde:/metin2/

L'étape la plus souvent oubliée est le test de restauration. Une sauvegarde jamais testée n'est pas une sauvegarde. Une fois par mois, prends l'habitude de restaurer la sauvegarde dans une base de test vide et d'y jeter un œil :

gunzip < player_2026-06-28_0400.sql.gz | mysql -u root -p player_test

Si le nombre de tables, les derniers personnages et les enregistrements d'items sont conformes à tes attentes, tu sais que la sauvegarde fonctionne réellement.

Questions fréquentes

Dois-je arrêter le serveur pour faire une sauvegarde ?

Pour les tables InnoDB, non. Comme --single-transaction prend un instantané cohérent, le jeu peut rester en ligne. Pour les tables MyISAM, un bref verrou ou un moment de faible trafic est préférable pour une cohérence totale.

À quelle fréquence dois-je sauvegarder ?

Le schéma player doit être sauvegardé au moins une fois par jour, idéalement toutes les 6 heures, car c'est là que la perte se ressent le plus. Comme common et account changent moins souvent, une sauvegarde quotidienne suffit généralement. Ajuste l'intervalle selon le nombre d'heures de perte de données que tu peux tolérer.

La compression nuit-elle aux performances ?

gzip s'exécute pendant l'export et consomme du CPU, mais comme il réduit fortement les écritures disque, l'effet net est généralement positif. Pour des schémas très volumineux, tu peux réduire nettement le temps en utilisant pigz, parallèle, à la place de gzip.

Tu veux blinder ton serveur contre la perte de données ? Si tu as besoin d'aide pour mettre en place sauvegardes automatiques, supervision et reprise après sinistre pour ton infrastructure Metin2, contacte-moi — laisse-moi t'aider à dormir sans perdre tes données.

Bu kategorideki tüm yazılar →

Devamı için