Le 8 octobre 2026, la note officielle de la version 1.0.0.8 précisait que les mondes déjà disparus nécessiteraient d’attendre la version 1.0.1 pour être concernés par le correctif (annonce de la mise à jour 1.0.0.8). Cela ne signifie pas que chaque monde de serveur dédié est récupéré automatiquement. Décision : ne supprimez pas le dossier et ne recréez pas le monde tout de suite ; arrêtez le serveur, copiez les fichiers existants, vérifiez les versions et testez le chargement sur une copie.
Ce guide s’adresse aux responsables d’un serveur dédié RuneScape: Dragonwilds qui ne voient plus leur monde après une mise à jour ou qui chargent un monde inattendu.
Il concerne aussi les administrateurs qui doivent distinguer un problème de monde d’une anomalie de progression de personnage.
Il est utile aux communautés qui veulent valider une restauration avant de rendre leur serveur aux joueurs.
Dernière vérification : 31 octobre 2026, à partir des annonces officielles du jeu et du guide officiel des serveurs dédiés. Les corrections et règles décrites ci-dessous ne prouvent pas qu’un fichier précis a été récupéré.
Distinguer le monde invisible, le personnage endommagé et le décalage de version
Avant toute intervention, il faut déterminer ce qui ne fonctionne pas. Un monde absent de la liste n’est pas nécessairement un fichier détruit : le serveur peut lire un autre dossier, ou le client et le serveur peuvent ne pas être sur la même version. À l’inverse, si le monde se charge mais qu’un personnage a perdu sa progression ou déclenche un message d’erreur, remplacer le fichier du monde ne constitue pas une réponse sûre.
La mise à jour 1.0.1, annoncée le 14 octobre 2026, inclut un correctif visant les mondes disparus, tout en reconnaissant que d’autres problèmes de sauvegarde peuvent subsister (note officielle de la version 1.0.1). Il faut donc traiter cette correction comme une piste pertinente, et non comme une garantie de restauration automatique pour tous les serveurs.
| Symptôme observé | Ce qu’il faut vérifier en premier | Action prudente |
|---|---|---|
| Le monde n’apparaît plus dans la liste | Présence des fichiers de monde, dossier effectivement lu par le serveur et journaux de démarrage | Arrêter le serveur et copier les fichiers avant de modifier le dossier |
| Le monde se charge, mais la progression d’un personnage semble incorrecte | État du personnage, versions client et serveur, message ou journal associé | Conserver le fichier original ; ne pas le remplacer par une sauvegarde du monde |
| Le serveur charge un autre monde ou ne retrouve pas le monde attendu | Nom du monde, contenu du dossier de sauvegarde et règle de sélection du fichier | Comparer le dossier et les journaux à la documentation officielle |
Des discussions de joueurs font état de problèmes de mondes après des mises à jour, mais ces publications décrivent des cas individuels : elles ne permettent pas de conclure que tous les serveurs sont touchés (un signalement individuel de monde disparu ; discussion sur les sauvegardes de monde). L’activité récente consultable dans les statistiques de fréquentation du jeu donne un contexte sur l’activité des joueurs ; elle ne mesure ni le volume des recherches ni la fréquence des pertes de sauvegarde.
Étape 1 : protéger les fichiers avant de chercher le monde
Pour un serveur dédié RuneScape: Dragonwilds, le premier objectif est de préserver l’état disponible, même s’il semble incomplet. Une intervention dans le dossier en cours peut remplacer un fichier encore exploitable ou rendre plus difficile la comparaison entre l’état initial et celui obtenu après correction.
Faut-il arrêter le serveur avant de copier le monde ?
Oui. Avant de copier ou de déplacer une sauvegarde, arrêtez proprement le processus du serveur. Une copie réalisée pendant que le jeu écrit encore des données peut ne pas correspondre à un état cohérent. Le guide officiel demande également de sauvegarder les fichiers avant une migration et décrit la gestion des sauvegardes du serveur.
Procédez dans cet ordre :
- Informez les joueurs que le serveur est temporairement indisponible et notez l’heure approximative du dernier fonctionnement normal.
- Arrêtez le serveur avec sa méthode habituelle, puis vérifiez dans les journaux qu’il ne continue pas à tourner en arrière-plan.
- Copiez le dossier de sauvegarde existant vers un emplacement distinct du dossier actif. Si le stockage disponible le permet, conservez une seconde copie hors de l’environnement qui héberge le serveur.
- Gardez les noms et l’organisation d’origine dans la copie ; évitez de renommer ou de convertir les fichiers pendant cette étape.
- Notez la version du jeu côté client et côté serveur, ainsi que les messages pertinents des journaux, sans supprimer les fichiers qui semblent inutilisés.
Cette copie de sécurité n’est pas une restauration : elle établit un point de retour. Si le diagnostic échoue ensuite, l’administrateur peut revenir aux fichiers préservés plutôt que d’avoir à reconstruire le monde à partir d’un répertoire modifié.
Où chercher le fichier .sav du monde ?
Le guide officiel indique que le serveur lit le répertoire de sauvegarde et retient le fichier .sav le plus récent. Il faut donc vérifier le répertoire configuré pour le serveur concerné, puis comparer les fichiers et leurs dates de modification ; un fichier .sav trouvé ailleurs sur la machine ne prouve pas que le serveur le consulte.
N’appliquez pas un chemin générique copié d’un tutoriel sans vérifier le système et la configuration utilisés. L’emplacement peut dépendre de la manière dont le serveur a été installé ou lancé. Consultez le chemin défini dans la configuration de l’instance et confrontez-le aux indications du guide officiel des serveurs dédiés.
Comparez ensuite trois éléments : le nom du monde que les joueurs attendent, le contenu réel du dossier lu par le serveur et les lignes de journal correspondant au dernier démarrage. Si le fichier est présent, mais que le serveur semble charger un autre monde, le problème peut relever de la sélection ou du répertoire plutôt que de la disparition du fichier. Si aucun fichier pertinent n’est présent, n’en concluez pas immédiatement que le monde est irrécupérable : recherchez d’abord une copie préexistante dans les emplacements de sauvegarde gérés par l’administrateur.
Un fichier .sav récent n’est pas automatiquement le bon fichier à restaurer. La date de modification aide à comparer les candidats, mais le nom du monde, le répertoire effectivement lu et le contenu attendu doivent également correspondre.
Étape 2 : traiter séparément une progression de personnage anormale
Une sauvegarde du monde et les données de progression d’un personnage ne doivent pas être considérées comme interchangeables. Si le paysage et les constructions du monde sont présents, mais qu’un joueur constate une progression manquante ou reçoit un message associé à son personnage, remplacer le fichier du monde par un ancien fichier pourrait modifier l’état collectif sans résoudre le problème individuel.
La note de la version 1.0.1 annonce un correctif concernant les mondes disparus, tout en indiquant que d’autres problèmes de sauvegarde peuvent exister. Elle ne permet pas de supposer que chaque anomalie de personnage est corrigée, ni qu’une sauvegarde de monde restaure une progression de personnage endommagée.
Dans ce cas, l’administrateur devrait :
- préserver les fichiers d’origine et éviter de les écraser par un fichier provenant d’une autre session ;
- relever la version du client du joueur concerné et celle du serveur au moment du problème ;
- conserver le texte exact du message, les journaux utiles et les étapes qui permettent de reproduire l’anomalie ;
- demander au joueur de vérifier si le problème se présente uniquement sur ce serveur ou également dans d’autres contextes, sans manipuler ses données à l’aveugle ;
- consulter les annonces officielles récentes pour vérifier si un correctif correspondant au symptôme a été publié.
Les publications communautaires peuvent aider à repérer les symptômes décrits par d’autres joueurs, mais elles ne sont pas une procédure de récupération validée. Une commande trouvée dans une discussion ne doit pas être exécutée sur les seuls fichiers disponibles : elle peut viser une version, une structure ou un cas différent. La comparaison avec les annonces officielles et la conservation d’une copie originale restent prioritaires.
Étape 3 : vérifier que le client et le serveur correspondent
Un serveur qui n’a pas terminé sa mise à jour peut ne pas se comporter comme une instance exécutant la version attendue. Avant d’interpréter une absence de monde comme une perte de données, vérifiez la version affichée par le client, la version réellement installée côté serveur et les journaux produits au démarrage. Comparez ces informations avec les annonces officielles disponibles, notamment la liste des mises à jour et annonces du jeu.
L’annonce officielle d’octobre 2026 a également signalé un problème de limitation rencontré à ce moment-là lors de mises à jour de serveurs dédiés par SteamCMD. Cette indication est limitée au contexte de l’annonce : elle ne démontre pas que l’outil échoue aujourd’hui ni que toute mise à jour de serveur est concernée. Si l’installation paraît incomplète, vérifiez son état et les journaux avant de relancer une opération susceptible de modifier les fichiers.
Un contrôle utile distingue les étapes au lieu de traiter « mise à jour réussie » comme un résultat unique :
- le processus de mise à jour s’est terminé sans erreur explicite ;
- les fichiers de serveur correspondent à la version attendue ;
- le lancement du serveur ne signale pas de composant manquant ou d’erreur de chargement ;
- le client utilisé pour le test peut rejoindre l’instance ;
- le monde attendu apparaît et se charge avec les données conservées.
Si la version du serveur ne peut pas être confirmée, ne testez pas la copie de sauvegarde dans le dossier de production. Corrigez d’abord l’installation sur un environnement de test ou une copie dédiée, en conservant intacts les fichiers de référence.
Choisir la branche de récupération selon les constats
La décision doit dépendre de ce que les fichiers et les journaux montrent, et non de la seule date de la mise à jour. Utilisez les conditions suivantes comme filtre avant toute remise en service :
- Si le fichier
.savattendu est présent dans le répertoire lu par le serveur, que les versions correspondent et que le journal permet d’identifier le monde, testez le démarrage avec une copie ; ne modifiez la production qu’après validation. - Si le fichier est présent, mais que le serveur charge un autre monde ou ne l’affiche pas, conservez le dossier actuel et vérifiez le chemin de lecture, le nom du monde et le fichier sélectionné selon la documentation officielle.
- Si le monde se charge, mais que la progression d’un personnage est incorrecte, ne remplacez pas le monde : préservez les données, relevez les versions et les erreurs, puis vérifiez si une annonce officielle couvre précisément ce cas.
- Si le répertoire ne contient plus le fichier attendu, recherchez une copie antérieure et conservez les éléments restants ; ne créez pas un nouveau monde au même emplacement avant d’avoir sécurisé l’existant.
- Si les versions client et serveur ne correspondent pas ou si la mise à jour paraît incomplète, rétablissez d’abord une version cohérente, puis réessayez sur la copie.
Cette décision conditionnelle évite deux erreurs coûteuses : remplacer des fichiers qui n’étaient pas la cause du problème et confondre un monde invisible avec une progression de personnage endommagée. Si aucune branche ne permet d’identifier clairement le bon fichier, la bonne décision est de suspendre les opérations destructives et de conserver l’état original.
Valider la copie avant de rouvrir le serveur
La copie doit être testée comme une candidate à la restauration, sans supprimer ni remplacer immédiatement l’original. Préparez un dossier de test distinct et vérifiez que le serveur de test lit bien cette copie, plutôt que le répertoire de production. Cette séparation réduit le risque qu’un essai modifie involontairement les seules données disponibles.
Pendant la validation, contrôlez les éléments suivants :
- le serveur démarre sans signaler d’erreur empêchant le chargement du monde ;
- le monde attendu est visible et correspond à son nom connu des joueurs ;
- les éléments importants du monde sont présents ;
- le joueur de test retrouve une progression cohérente avec le symptôme signalé ;
- les journaux ne montrent pas une nouvelle erreur après la connexion ;
- après un arrêt propre puis un nouveau démarrage, le serveur charge toujours le résultat attendu.
Une seule connexion réussie ne suffit pas à établir que la restauration est stable : un redémarrage contrôlé permet aussi de vérifier que le serveur relit bien le fichier attendu. Si le résultat change, si le monde chargé n’est pas celui prévu ou si une progression reste incohérente, arrêtez le test, préservez les deux états et revenez au diagnostic. Ne laissez pas les joueurs reprendre leur partie tant que la copie testée n’a pas produit un état compréhensible et reproductible.
Pour les futures mises à jour, intégrez à la maintenance une vérification avant et après intervention : copie des fichiers, versions relevées, démarrage de contrôle et possibilité de revenir aux fichiers précédents. Les administrateurs qui souhaitent formaliser une procédure de déplacement peuvent aussi consulter les informations d’aide et de gestion du service, sans confondre cette documentation générale avec une sauvegarde automatique de leur monde.
Relier l’hébergement au contrôle réel des sauvegardes
Un serveur dédié peut offrir à son administrateur un environnement où gérer les fichiers et les services, mais le mot « dédié » ne signifie pas que les mondes sont automatiquement sauvegardés ou restaurés par l’hébergeur. Il faut vérifier séparément les possibilités d’accès, les disques proposés, le système installé et l’emplacement où les copies seront conservées. La présence de stockage sur la machine ne constitue pas, à elle seule, une sauvegarde indépendante.
Avant de changer d’hébergement, comparez les conditions dont dépend réellement la reprise : accès administrateur pour copier les fichiers, compatibilité du système avec le serveur de jeu, espace disponible pour garder des copies distinctes et méthode permettant de transférer le monde sans écraser l’original. Les options et leurs prix doivent être contrôlés dans les offres de SFP Cloud ; aucune capacité de restauration ne doit être déduite d’une simple fiche matérielle.
Si le serveur actuel est un environnement partagé, ses ressources et ses règles d’accès peuvent limiter la maîtrise des fichiers ou rendre plus difficile une procédure de test isolée. À l’inverse, un serveur dédié n’est pas forcément le meilleur choix pour une partie temporaire, une activité très légère ou un besoin qui exige une élasticité immédiate : il ajoute la responsabilité de maintenir le système, de protéger les sauvegardes et de valider les mises à jour.
Pour une communauté qui héberge son monde durablement, une machine indépendante peut être plus cohérente si l’accès aux fichiers, la stabilité d’exploitation et la gestion simultanée de plusieurs services comptent davantage qu’une mise en route ponctuelle. L’option doit toutefois être choisie en fonction des systèmes, des disques et des modalités d’accès réellement affichés, puis associée à une sauvegarde organisée par l’administrateur. Les offres de SFP Cloud peuvent être comparées à cet aune ; la décision ne remplace ni la copie avant mise à jour ni les tests de restauration décrits ici.
Déployez votre serveur dédié pour RuneScape: Dragonwilds
Avec SFP Cloud, louez une machine bare metal réservée à votre usage, équipée d’un AMD EPYC 7543P et de 128 ou 256 Go de mémoire ECC. Les serveurs sont à Tokyo, au Japon. Vous pouvez commander avant de vous connecter.