Sauvegarder un serveur Minecraft avec DigitalOcean Spaces

Une sauvegarde ne sert que si elle restaure le monde attendu par vos joueurs. Pour un serveur Java classique, cela comprend généralement les dossiers de monde, la configuration, la liste blanche, les opérateurs, les plugins ou mods, ainsi que la version du serveur ou la définition du conteneur nécessaire pour le démarrer. Notez d’abord où se trouvent ces éléments : certains hébergements placent le monde hors du dossier qui contient server.jar.

Ce guide vise un serveur Java hébergé sous Linux et utilise AWS CLI, car Spaces accepte les requêtes compatibles S3. Il ne remplace ni une copie cohérente d’une base de données en cours d’utilisation ni un plan de reprise testé. Si votre serveur utilise un panneau, un volume Docker ou un modpack avec ses propres données, ajoutez ces chemins explicitement et testez le résultat sur une autre machine ou dans un autre dossier.

Créez dans Spaces Object Storage un compartiment tel que minecraft-backups-votre-serveur. Choisissez soigneusement la région : le nom du compartiment doit y être unique et l’endpoint régional est utilisé par chaque commande CLI. N’activez pas l’affichage public des fichiers et n’utilisez pas le CDN pour des sauvegardes.

Dans l’onglet Access Keys de Spaces, créez une clé limitée à ce compartiment, avec la permission Read/Write/Delete. Enregistrez le secret lorsqu’il apparaît : le panneau de contrôle ne l’affiche qu’une fois. Une clé distincte permet de la renouveler ou de la révoquer sans perturber une autre application. Les clés limitées et les politiques de compartiment S3 ne sont pas compatibles ; n’ajoutez donc pas de politique de compartiment dans cette configuration simple.

Le versionnage est une couche de récupération supplémentaire, pas un substitut à la rétention. Une modification ou une suppression ordinaire laisse un historique que vous pouvez inspecter et restaurer. DigitalOcean exige ici l’endpoint régional : utilisez par exemple nyc3.digitaloceanspaces.com, et non l’endpoint d’origine qui contient le nom du compartiment.

Définissez AWS_DEFAULT_REGION sur us-east-1 pour satisfaire le réglage requis côté client par AWS CLI ; l’endpoint Spaces, et non cette valeur, détermine la région effective du compartiment. Remplacez les espaces réservés ci-dessous par votre compartiment et votre région Spaces.

N’archivez pas un monde pendant que le serveur écrit des chunks. Le script ci-dessous emploie RCON pour exécuter save-off, save-all flush et save-on autour de l’archive. Remplacez la commande RCON par le mécanisme de console de votre serveur. Si vous ne pouvez pas interrompre les sauvegardes de manière fiable, arrêtez le service avant l’archivage puis redémarrez-le ; quelques minutes d’indisponibilité sont plus sûres qu’une sauvegarde qui ne se restaure que parfois.

Adaptez SERVER_DIR et la liste des fichiers inclus à votre installation. L’exemple garde les fichiers courants de Paper ou vanilla et exclut les journaux, le cache et un éventuel dossier backups. Il crée une archive datée, l’envoie sous un préfixe prévisible, puis conserve l’archive locale uniquement jusqu’à la réussite de l’envoi.

Exécutez d’abord le script manuellement, observez sa fin, puis vérifiez que l’objet apparaît dans le bon compartiment et sous le bon préfixe. Planifiez-le ensuite. Un minuteur est préférable à une commande automatique que personne ne regarde : au minimum, envoyez stderr vers un journal et mettez en place une alerte lorsque la commande échoue.

Une sauvegarde quotidienne est un bon départ pour un serveur personnel peu actif, mais ce n’est pas une réponse universelle. Choisissez la fréquence d’après la quantité de données que vous acceptez de perdre. Si perdre une soirée de construction est inacceptable, sauvegardez plus souvent et équilibrez ce choix avec la taille des archives, le temps d’envoi et le coût de rétention.

Les règles de cycle de vie Spaces peuvent expirer des objets après un certain nombre de jours et supprimer les envois multipartites incomplets. Choisissez une durée qui correspond à vos besoins de récupération, puis vérifiez exactement ce qu’elle couvre avant de l’activer. Une règle de 30 jours est simple à expliquer, mais elle peut être trop courte si un dommage au monde n’est détecté que plusieurs semaines après.

Le versionnage modifie la manière dont les suppressions fonctionnent : supprimer un objet peut laisser des versions antérieures et des marqueurs de suppression. Examinez ensemble le versionnage et le cycle de vie, surtout avant de compter sur un nettoyage automatique. Gardez au moins un chemin de récupération testé et indépendant pour un monde que vous ne pouvez pas perdre.

Choisissez une archive récente et restaurez-la dans un dossier de test vide. Vérifiez que l’archive contient les fichiers de monde et de configuration attendus avant de démarrer un processus Minecraft dessus. Pour un test plus solide, lancez une copie isolée sur un autre port avec la même version du serveur et laissez un administrateur la rejoindre.

Ne restaurez pas sur le dossier de production tant que le serveur de production fonctionne. Arrêtez le serveur, conservez le dossier endommagé jusqu’à ce que le monde restauré soit vérifié, puis échangez les dossiers pendant une fenêtre de maintenance planifiée.