Des sauvegardes qui se restaurent vraiment : la règle 3-2-1 pour une petite communauté de joueurs

Toute communauté qui fait tourner un serveur depuis un an a son histoire du monde qui s’est volatilisé : un disque qui est mort, un plugin qui a corrompu la carte, un admin qui a supprimé le mauvais dossier, un compte pris par quelqu’un qui l’a fait exprès. L’histoire finit toujours pareil. Soit il y avait une sauvegarde et elle a marché, soit il y avait une « sauvegarde » et elle n’a pas marché.

Cet article est une mise en place petite et réaliste pour un groupe d’amis ou un petit serveur public, avec des outils gratuits. Il suit la seule règle sur laquelle tous les guides de sauvegarde s’accordent, et ajoute l’étape que la plupart mentionnent trop brièvement : prouver que tu sais restaurer.

La règle : 3-2-1

L’agence américaine de cybersécurité CISA la décrit pour les petites entreprises sur sa page sur la sauvegarde des données professionnelles : 3 copies des fichiers importants, 2 types de supports de stockage différents (comme un disque dur et le cloud), et 1 copie conservée hors site. Elle dit aussi d’utiliser une combinaison de sauvegardes locales et distantes pour se protéger des menaces, des pannes matérielles et des dommages physiques, et de tester la procédure de sauvegarde pour pouvoir restaurer en totalité comme en partie, et revenir en arrière d’au moins sept jours.

Pour un serveur de jeu, ça se traduit ainsi :

1. La copie un est le monde en cours d’utilisation, sur le disque du serveur. Elle compte comme une copie, mais c’est celle qui se corrompt quand quelque chose tourne mal.
2. La copie deux est un instantané sur un autre stockage : un autre disque, un autre volume, ou le système de sauvegarde de ton hébergeur. Elle protège de tes propres erreurs et d’un monde corrompu, à condition de garder plusieurs générations, pas seulement la dernière.
3. La copie trois est hors site : un autre fournisseur, un autre bâtiment. Elle protège de la perte de la machine, du compte ou du fournisseur. Si le serveur et les sauvegardes sont au même endroit avec le même identifiant, un seul mot de passe volé emporte les deux.

Quoi sauvegarder

Tout n’a pas la même valeur. Pour un serveur Minecraft :

• Indispensable : les dossiers du monde (world, world_nether, world_the_end ou ce que dit ton level-name), les dossiers de configuration des plugins, et toute base de données utilisée par les plugins.
• Utile : server.properties, whitelist.json, ops.json, la liste des plugins avec leurs versions écrite dans un fichier texte.
• Inutile : le jar du serveur (retélécharge-le), les logs et les caches. Les laisser de côté garde la sauvegarde petite, ce qui veut dire que tu en garderas plus.

Les autres jeux ont la même forme : le monde ou la base de données sauvegardés, la configuration, et la liste des mods. La documentation du jeu dit où vivent ses sauvegardes.

Étape 1 : faire une copie cohérente

Copier un dossier dans lequel un programme en marche est en train d’écrire peut donner un mélange d’anciens et de nouveaux fichiers. Pour Minecraft Java, le serveur a des commandes pour ça, documentées sur le wiki Minecraft :

save-off
save-all flush

save-off désactive l’écriture des fichiers du monde, et save-all flush écrit tout sur le disque immédiatement, avec un bref gel. Fais ensuite ta copie, puis réactive l’enregistrement :

save-on

Le wiki note que le réglage save-off est réinitialisé au redémarrage du serveur : un plantage en plein milieu d’une sauvegarde ne laisse donc pas l’enregistrement coupé pour de bon. N’oublie quand même pas la dernière commande : un serveur laissé des heures avec l’enregistrement coupé perd toute cette partie s’il plante.

Étape 2 : utiliser un outil qui déduplique et chiffre

Copier tout le monde dans un nouveau dossier chaque nuit gaspille de la place. restic prend des instantanés, stocke chaque morceau de donnée une seule fois, et chiffre le dépôt, ce qui compte quand une partie de la sauvegarde vit chez un autre fournisseur. Installe-le depuis ta distribution (sudo apt install restic), puis crée un dépôt. La même commande marche pour un dossier local ou pour une autre machine en SFTP, comme le montre la documentation de restic :

# a repository on another disk
restic init --repo /mnt/backupdisk/mc

# or on another machine, over SSH
restic -r sftp:backup@other-host.example:/srv/restic/mc init

Il demande un mot de passe, deux fois. Lis ce que dit la documentation à ce sujet : retenir ton mot de passe est important, parce que si tu le perds, tu ne pourras plus accéder aux données du dépôt. Il n’y a aucune récupération possible. Mets le mot de passe dans ton gestionnaire de mots de passe et, si tu veux, dans une enveloppe scellée, et dans un endroit qui ne dépend pas du serveur sauvegardé.

Fais ensuite un instantané du monde et de la configuration :

restic -r /mnt/backupdisk/mc backup /srv/minecraft/world /srv/minecraft/plugins /srv/minecraft/server.properties

La page de la documentation sur la sauvegarde liste les options. Le premier instantané a la taille du monde ; les suivants ne stockent que ce qui a changé, donc une sauvegarde quotidienne d’un gros monde est souvent petite.

Étape 3 : l’automatiser, et garder l’ordre

Un script lancé par un timer sort la routine de ta tête. Voici la forme d’un script, pour un serveur Minecraft qui tourne dans une session tmux nommée mc :

#!/bin/bash
set -euo pipefail
export RESTIC_REPOSITORY=sftp:backup@other-host.example:/srv/restic/mc
export RESTIC_PASSWORD_FILE=/etc/restic-mc.pass     # root-only, mode 600

trap "tmux send-keys -t mc 'save-on' Enter" EXIT   # saving always comes back on, even if the backup fails

tmux send-keys -t mc 'save-off' Enter
tmux send-keys -t mc 'save-all flush' Enter
sleep 20          # a plain wait; check the console prints that the save finished
restic backup /srv/minecraft/world /srv/minecraft/plugins /srv/minecraft/server.properties

Le sleep est un raccourci : il laisse au flush le temps de se terminer, et dans une installation plus durable tu préférerais lire la réponse du serveur, ou utiliser RCON ou l’API de ton panel. Ce qui compte, c’est l’ordre : arrêter d’écrire, vider, copier, reprendre. La ligne trap rend la dernière étape inconditionnelle : si restic backup échoue et que set -e arrête le script, l’enregistrement est quand même réactivé, ce qui est le bon sens pour un serveur en marche. Lance le script depuis cron ou un timer systemd, toutes les nuits, à l’heure la plus calme.

Étape 4 : garder plusieurs générations, et les élaguer

Une sauvegarde d’hier est inutile si la corruption date d’il y a trois jours et s’est glissée dans toutes les copies depuis. Garde un ensemble glissant : quotidien pendant une semaine, hebdomadaire pendant un mois, mensuel pendant quelques mois. Restic supprime les anciens instantanés avec forget, puis récupère l’espace avec prune :

restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

Lance-le après la sauvegarde, avec le même calendrier.

Étape 5, celle que tout le monde saute : la restaurer

Le conseil de la CISA est de tester que tu sais restaurer, et rien ne rend la chose plus réelle que de le faire. Une fois par mois, ou au moins après la mise en place du système et après chaque changement, restaure un instantané dans un dossier vide et démarre un serveur dessus :

restic -r /mnt/backupdisk/mc snapshots
restic -r /mnt/backupdisk/mc restore latest --target /tmp/restore-test

Fais ensuite pointer une copie de test du serveur vers /tmp/restore-test, connecte-toi, et cherche ta base. Vérifie aussi que le dépôt lui-même est sain :

restic -r /mnt/backupdisk/mc check
restic -r /mnt/backupdisk/mc check --read-data-subset=10%

La première commande vérifie la structure du dépôt. La seconde lit un dixième aléatoire des données, ce qui détecte au fil du temps les fichiers abîmés sans tout télécharger chaque nuit (la documentation note qu’un --read-data complet lit chaque fichier de paquet et coûte de la bande passante).

Une sauvegarde que tu n’as jamais restaurée est un espoir. Une sauvegarde que tu as restaurée le mois dernier est un fait.

Où mettre la troisième copie

Hors site veut dire un autre domaine de défaillance : pas le même compte de fournisseur, pas le même bâtiment. Pour une petite communauté, les options réalistes sont le stockage d’un second hébergeur, un bucket de stockage objet bon marché, ou un disque gardé par un ami dans une autre ville et rafraîchi de temps en temps. Quel que soit ton choix :

• Chiffre avant d’envoyer, ce que restic fait.
• Donne au compte de sauvegarde un accès en écriture seule, si le stockage le permet, pour qu’un mot de passe de serveur volé ne puisse pas supprimer ton historique.
• Garde les identifiants du stockage de sauvegarde hors de l’historique du shell du serveur et hors des dossiers du monde.

Ce que ton hébergeur te donne peut-être déjà

Regarde ce que fait ton hébergeur avant de tout construire toi-même. Chez Alama, les serveurs payants ont des sauvegardes quotidiennes que tu peux restaurer toi-même depuis le panel, et les fichiers de chaque serveur peuvent être téléchargés en SFTP à tout moment, ce qui te permet de créer ta propre copie hors site. Les sauvegardes d’un hébergeur sont ta deuxième copie ; elles sont encore chez le même fournisseur, donc la troisième copie reste à organiser par toi. Tu peux voir les offres sur la page des jeux, ou d’abord essayer le serveur Minecraft gratuit.

Une routine hebdomadaire qui coûte cinq minutes

1. Regarde le log de la dernière sauvegarde. Dit-il qu’elle a réussi ?
2. Regarde le nombre et les dates des instantanés (restic snapshots).
3. Une fois par mois, restaure un instantané dans un dossier de test et démarre-le.
4. Après chaque gros changement (nouveau plugin, nouvelle version, nouvelle carte), fais d’abord un instantané manuel.

Pour le reste de la mise en place autour du serveur, le guide du serveur Minecraft contient les réglages et les 30 premières minutes sur un serveur neuf contient le durcissement.