Transférer les fichiers d’un serveur de jeu Linux avec rsync permet de préparer une migration, une sauvegarde ou un changement de machine sans recopier inutilement les données déjà présentes. La méthode convient à un VPS Linux, un serveur dédié et une instance administrée avec Pterodactyl. Elle peut servir pour Minecraft, FiveM, Rust ou tout autre logiciel de jeu qui stocke ses données dans un répertoire local.
Avant le transfert : préparer les deux serveurs
Identifiez le répertoire réellement utilisé par votre serveur de jeu : fichiers de configuration, monde, scripts, extensions, mods, ressources, journaux et sauvegardes. Notez le chemin absolu, l’utilisateur qui possède ces fichiers, le groupe associé et l’espace disque disponible sur la machine cible. Une copie fiable commence par un dossier de destination clairement défini.
Vérifiez que le système source et le système cible peuvent communiquer en SSH. Testez l’adresse IP, le port SSH, le compte utilisé et l’authentification par clé. Le transfert rsync passe généralement par SSH : si cette connexion n’est pas fiable, corrigez-la avant de déplacer les données du serveur de jeu.
Arrêtez le serveur de jeu avant la copie finale. Cette précaution évite de transférer un monde, une base de données locale, un fichier de configuration ou une sauvegarde pendant une écriture. Vous pouvez réaliser une première synchronisation serveur allumé pour gagner du temps, puis refaire une synchronisation après l’arrêt.
Installer et vérifier rsync
Sur les distributions Linux courantes, installez le paquet rsync avec le gestionnaire de paquets adapté à votre système. Vérifiez ensuite que la commande répond sur le serveur source et sur le serveur cible. Le programme doit être disponible des deux côtés pour exploiter la synchronisation et ses contrôles de fichiers.
Ne supprimez pas l’ancienne copie avant d’avoir vérifié la nouvelle. Si le transfert doit remplacer une installation existante, renommez d’abord le dossier cible ou conservez une sauvegarde indépendante. Cette étape donne un point de retour si le service, le monde ou les permissions ne fonctionnent pas après la migration.
Réaliser une première synchronisation
Depuis le serveur source, lancez une synchronisation vers le compte et le chemin de la machine cible. Une commande type ressemble à celle-ci :
rsync -aP -e "ssh -p PORT" /chemin/du/serveur/ utilisateur@IP_CIBLE:/chemin/de/destination/
Remplacez les éléments entre majuscules par vos propres valeurs. L’option d’archivage conserve les attributs utiles à la copie et l’affichage de progression permet de suivre les fichiers volumineux. Rsync compare les fichiers et ne retransfère que les données nécessaires, ce qui réduit le temps de migration quand une première copie existe déjà.
Pour un premier essai, contrôlez attentivement le chemin source. Une barre oblique finale peut modifier le contenu copié dans le dossier cible : copiez le contenu du répertoire ou le répertoire lui-même selon le résultat attendu. Vérifiez également le chemin distant avant d’appuyer sur Entrée.
Simuler et contrôler une copie
Avant une synchronisation sensible, utilisez une simulation pour observer les fichiers qui seraient ajoutés, modifiés ou supprimés. Une simulation ne remplace pas la sauvegarde : elle sert à relire le périmètre et à repérer une erreur de chemin. Comparez ensuite le nombre de fichiers, la taille globale et les éléments essentiels du serveur de jeu.
Pour contrôler l’intégrité d’un fichier important, comparez son nom, sa taille et, si nécessaire, son empreinte sur les deux machines. Pour un monde ou une sauvegarde volumineuse, le contrôle doit être réalisé après la fin complète du transfert et non pendant l’écriture.
Exclure les fichiers temporaires
Les journaux très anciens, les caches et certains fichiers temporaires ne sont pas toujours nécessaires à la migration. Vous pouvez utiliser des règles d’exclusion adaptées à votre serveur, mais ne retirez jamais un monde, une configuration, une extension, un script ou une sauvegarde sans l’avoir identifié.
rsync -aP --exclude='logs/*.old' --exclude='cache/' -e "ssh -p PORT" /chemin/source/ utilisateur@IP_CIBLE:/chemin/cible/
Listez les exclusions dans votre documentation de migration. Une règle valable pour un jeu peut être dangereuse pour un autre : le nom cache, par exemple, ne décrit pas toujours une donnée reconstruisible.
Contrôler les permissions et le propriétaire
Une copie réussie ne garantit pas que le processus du serveur de jeu pourra lire et écrire les fichiers. Sur la machine cible, vérifiez le propriétaire, le groupe, les droits du dossier et les permissions des sous-répertoires. Réattribuez-les avec les outils d’administration de votre distribution si nécessaire, puis testez la création d’un fichier temporaire avec l’utilisateur qui exécutera réellement le serveur.
Évitez de donner des droits d’écriture généraux à tous les utilisateurs. Les permissions doivent répondre au besoin du service, pas masquer un problème de propriétaire ou de chemin. Contrôlez aussi les fichiers cachés, car ils peuvent contenir des réglages importants pour le serveur ou son environnement.
Faire la synchronisation finale
Arrêtez le serveur de jeu source, lancez une dernière synchronisation, puis comparez quelques fichiers importants : configuration, sauvegarde du monde, liste des extensions, scripts, mods et journaux utiles. Ne redémarrez le service sur la cible qu’après ces contrôles.
Si vous utilisez une option de suppression pour rendre deux dossiers identiques, faites d’abord une simulation et relisez la liste des fichiers concernés. Une suppression mal ciblée peut effacer une sauvegarde ou un fichier local à la machine cible. Pour une migration prudente, préférez d’abord une copie vers un nouveau dossier et gardez l’ancienne version intacte.
Vérifier le serveur après la migration
Démarrez le serveur avec son utilisateur habituel et observez les journaux. Testez la connexion d’un joueur, le chargement du monde, l’accès aux extensions, l’écriture d’une sauvegarde et la modification d’une configuration. Vérifiez aussi que le port de jeu est bien ouvert sur la machine cible et que le service écoute sur la bonne adresse.
Conservez l’ancienne machine quelques heures ou quelques jours selon votre tolérance au risque, sans la présenter comme une sauvegarde tant que sa restauration n’a pas été vérifiée. Une sauvegarde utile doit pouvoir être relue et restaurée, pas seulement exister sous forme de fichiers copiés.
Pour une migration plus large, documentez l’adresse IP, le port SSH, le chemin des fichiers, l’utilisateur de service, les permissions, la commande de démarrage, le port de jeu et la procédure de retour arrière. Cette fiche réduit les erreurs lors d’une prochaine intervention et facilite le diagnostic si le serveur ne démarre pas.
Diagnostiquer un transfert incomplet
Si rsync signale une erreur, relisez le code de sortie et le chemin concerné. Un refus d’accès indique souvent un utilisateur incorrect, un propriétaire différent ou un répertoire cible absent. Une erreur SSH concerne plutôt l’adresse, le port, la clé ou la disponibilité du service d’administration. Une interruption réseau peut laisser une copie partielle : relancez rsync après avoir vérifié l’espace disque et la connexion.
Ne démarrez pas le serveur de jeu sur une copie dont les fichiers essentiels sont absents. Comparez la configuration, le monde, les scripts, les mods, les extensions et les sauvegardes avec la liste préparée avant la migration.
Checklist de transfert rsync
- Le serveur source et le serveur cible communiquent en SSH.
- Le chemin source et le chemin cible ont été vérifiés.
- Une première synchronisation a été terminée sans erreur.
- Le serveur de jeu a été arrêté avant la copie finale.
- Les permissions et le propriétaire correspondent à l’utilisateur du service.
- Le monde, la configuration, les extensions et les sauvegardes ont été contrôlés.
- Le serveur cible a été démarré et testé avant l’abandon de l’ancienne copie.
Besoin d’une machine pour votre serveur ?
Découvrez les solutions ElypseCloud pour héberger un serveur de jeu ou un environnement Linux avec une configuration adaptée à votre projet.
Pour poursuivre, consultez aussi notre guide de migration d’un serveur de jeu, la méthode de sauvegarde et restauration Pterodactyl, le guide Pterodactyl sur serveur dédié, les premiers réglages de sécurité d’un serveur dédié et les serveurs dédiés ElypseCloud.