Comprendre le wipe Rust : types, frequence et impact sur le serveur

Le wipe Rust est le mécanisme qui remet une partie à zéro : carte régénérée, bases effacées, parfois blueprints réinitialisés. Mal géré, il vide une communauté en une nuit ; bien planifié, il relance le cycle de jeu et ramène les joueurs semaine après semaine. Voici comment le système fonctionne réellement, ce que chaque type efface, et comment fixer un rythme tenable.

Comment fonctionne le wipe Rust côté fichiers

Contrairement à ce que beaucoup imaginent, il n'existe pas de « bouton wipe » officiel dans Rust. Tout l'état du monde persistant est stocké dans une poignée de fichiers, dans le dossier server/<identity>/. Un wipe consiste simplement à supprimer les bons fichiers pendant que l'instance est arrêtée, puis à redémarrer : le moteur régénère ce qui manque au premier tick.

Les fichiers qui composent une partie

Fichier	Contenu	Concerné par
proceduralmap.<size>.<seed>.<protocol>.map	Carte générée (relief, monuments, routes)	Map wipe
proceduralmap.*.sav (+ .1, .2, .3…)	État du monde : bases, deployables, TC, loot, ressources	Map wipe
player.blueprints.*.db	Blueprints appris par chaque SteamID	Blueprint wipe
player.states.*.db	Inventaire, santé, faim, position à la déconnexion	Full wipe
player.identities.*.db	Association SteamID ↔ entité joueur	Full wipe
player.deaths.*.db	Historique des morts et respawn	Full wipe
oxide/data/ ou carbon/data/	Données des plugins : clans, économie, kits, teleport, stats	Selon le plugin

Le numéro de protocol présent dans le nom du fichier .map change à chaque mise à jour majeure du jeu. C'est exactement pour cette raison que le premier jeudi de chaque mois provoque un « force wipe » : la carte de l'ancien protocole n'est plus chargeable, le monde est donc régénéré de force sur toutes les instances de la planète. Les wipes de blueprints forcés, eux, sont plus rares et annoncés à l'avance par Facepunch.

Avant d'aller plus loin dans la mécanique, une remarque pratique : la qualité de l'infrastructure conditionne directement la génération de la carte et le premier soir de wipe, quand 100 joueurs se connectent en dix minutes. Un CPU haute fréquence, du NVMe et un anti-DDoS actif changent tout sur ce créneau précis — c'est ce que propose un hébergeur Rust orienté performance, avec un panel Pterodactyl pour gérer les fichiers sans passer par du SSH manuel.

Map wipe, blueprint wipe et full wipe : ce que chacun efface

Trois niveaux, trois impacts très différents sur la progression des joueurs. Choisir le mauvais, c'est perdre une partie de sa base de joueurs réguliers.

Le map wipe

Le plus courant. On supprime la carte et les sauvegardes du monde : toutes les constructions, coffres, tourelles et ressources disparaissent. Les joueurs conservent leurs blueprints, donc ils repartent de zéro en matériel mais avec leur tech déjà débloquée. C'est le wipe qui produit le fameux « rush » des premières heures : farm, tour de mise à niveau, raid des voisins.

cd /home/container/server/rust01
rm -f proceduralmap.*.map proceduralmap.*.sav*

Le blueprint wipe (BP wipe)

On efface uniquement la table des blueprints. Les joueurs repartent avec le tier 1 de base et doivent réapprendre l'ensemble de l'arbre : scrap, recycleurs, workbenches, tech tree. Un BP wipe seul (sans map wipe) est rare et déroutant ; dans la pratique, il se combine presque toujours avec un map wipe.

rm -f player.blueprints.*.db

Le full wipe

Carte + blueprints + états joueurs + données de plugins. Personne ne conserve rien : ni inventaire de déconnexion, ni solde d'économie, ni clan, ni rang de kit. C'est le reset intégral, celui qui remet tous les nouveaux arrivants sur un pied d'égalité avec les vétérans.

cd /home/container/server/rust01
rm -f *.db proceduralmap.*.map proceduralmap.*.sav*
rm -rf /home/container/oxide/data/*

Attention : vider oxide/data supprime aussi les permissions et groupes de certains plugins. Sauvegarde ce dossier séparément avant, et conserve toujours oxide/data/oxide.groups.data et oxide.users.data si tu veux garder tes VIP et ton staff.

Type	Bases effacées	Blueprints effacés	Données plugins	Ressenti joueur
Map wipe	Oui	Non	Non	Reset court, reprise rapide
Blueprint wipe	Non (si seul)	Oui	Non	Progression tech relancée
Full wipe	Oui	Oui	Oui	Remise à zéro totale

Planifier la fréquence des wipes pour garder une communauté active

La fréquence n'est pas un détail cosmétique : c'est la variable qui définit le type de joueurs que tu attires. Un rythme court attire les rushers et les petites teams ; un rythme long attire les builders et les gros clans. Les deux publics cohabitent mal sur la même instance.

Les rythmes qui fonctionnent

Profil	Map wipe	BP wipe	Public visé
Vanilla PvP	Hebdomadaire (jeudi)	Mensuel (force wipe)	Solo/duo, sessions courtes
Modded 2x–3x	Toutes les 2 semaines	Mensuel	Teams moyennes, progression accélérée
Modded 5x–10x	Hebdomadaire	Toutes les 2 semaines	Raid intensif, farm rapide
PvE / Build	Mensuel ou trimestriel	Rarement, ou jamais	Builders, roleplay, longue durée
Low pop / communauté fermée	Mensuel (force wipe uniquement)	Suit le force wipe	Groupe d'habitués

Trois règles de planification

1. Un jour et une heure fixes, non négociables. Le jeudi entre 19h et 21h (heure de Paris) est le créneau standard de la communauté Rust, calé sur les mises à jour Facepunch. Décaler un wipe de deux jours « parce que ça arrangeait » coûte systématiquement du monde le soir J.
2. Annoncer 72 heures avant. Discord, message in-game récurrent, et surtout le nom d'instance : intégrer [Wipe Thursday] ou la date directement dans le hostname permet aux joueurs de la liste publique de savoir immédiatement où ils mettent les pieds.
3. Ne jamais changer le rythme en cours de cycle. Si tu passes d'un wipe hebdomadaire à bimensuel, annonce-le au moins deux cycles à l'avance. Les joueurs organisent leur semaine autour de ton calendrier ; le briser une fois suffit à casser l'habitude.

Le soir du wipe : ce qui se joue vraiment

Les deux premières heures représentent le pic de charge le plus violent du cycle. Cent connexions simultanées, génération du monde, spawn massif d'entités : c'est là que les instances sous-dimensionnées lâchent, avec du rubber-banding et des timeouts. Quelques réflexes utiles :

• Redémarrer l'instance 30 minutes avant l'heure annoncée, pour que la carte soit déjà générée et en mémoire quand les joueurs arrivent.
• Vérifier le server.saveinterval : une valeur trop basse (60s) multiplie les micro-freezes sur une grosse map. 300 secondes est un compromis raisonnable.
• Adapter la worldsize à ta population réelle. Une carte de 4500 avec 20 joueurs donne un serveur désert ; 3000 à 3500 concentre l'action et allège la charge CPU.
• Surveiller la console live pendant le premier quart d'heure : les erreurs de plugin post-wipe (données manquantes) apparaissent immédiatement.

Exécuter un wipe Rust proprement depuis le panel

Voici la procédure que j'applique sur un cycle standard, du dernier arrêt à la reprise. Elle prend une dizaine de minutes et évite 90 % des incidents post-wipe.

1. Sauvegarder avant de supprimer

Même sur un wipe volontaire, garder une archive de l'ancien cycle permet de restaurer si une manipulation dérape, et de récupérer des données (stats, économie) pour un classement de fin de cycle. Depuis un accès shell :

tar -czf /home/container/backup-wipe-$(date +%F).tar.gz \
    /home/container/server/rust01 /home/container/oxide/data

Sur un panel Pterodactyl, la fonction de sauvegarde intégrée fait le même travail en un clic, avec un snapshot horodaté que tu peux télécharger avant de nettoyer les fichiers.

2. Arrêter l'instance proprement

Ne jamais supprimer des fichiers pendant que le processus tourne : Rust réécrit ses .sav à intervalle régulier et recréerait aussitôt ce que tu viens d'effacer. Dans la console ou en RCON :

save
quit

Attends que le processus soit réellement en statut offline avant l'étape suivante.

3. Supprimer les fichiers correspondant au type de wipe

Reprends les commandes de la section précédente selon le type choisi. Vérifie toujours le contenu du dossier avant et après :

cd /home/container/server/rust01
ls -lh

4. Changer la seed (et éventuellement la taille)

Une nouvelle seed garantit une carte inédite. Si tu conserves la même seed après un map wipe, tu retrouveras exactement le même relief et les mêmes emplacements de monuments — ce qui peut être voulu sur une communauté attachée à sa carte, mais lasse vite ailleurs. Pour générer une valeur aléatoire :

shuf -i 1-2147483647 -n 1

Puis reporte-la dans les variables de démarrage :

./RustDedicated -batchmode -nographics \
  +server.identity "rust01" \
  +server.hostname "[EU] Weekly Wipe | Thursday 19h" \
  +server.seed 1849302471 \
  +server.worldsize 3500 \
  +server.maxplayers 100 \
  +server.saveinterval 300 \
  +server.port 28015 \
  +rcon.port 28016 \
  +rcon.password "MOT_DE_PASSE_LONG_ET_UNIQUE"

Sur un panel, ces valeurs sont exposées en variables (SEED, WORLD_SIZE, HOSTNAME) : tu les modifies dans l'onglet de configuration sans toucher à la ligne de démarrage.

5. Mettre à jour les plugins avant redémarrage

Un force wipe s'accompagne d'un changement de protocole : Oxide/uMod et Carbon doivent être mis à jour, et une partie des plugins aussi. Redémarrer sans mise à jour donne un serveur qui refuse les connexions ou qui spamme des exceptions dans la console. Vérifie la compatibilité de tes extensions sur le wiki officiel Rust et chez le mainteneur de chaque plugin avant le jeudi soir.

6. Automatiser ce qui peut l'être

Les tâches planifiées d'un panel gèrent très bien la partie récurrente : arrêt programmé, sauvegarde automatique, redémarrage quotidien pour purger la RAM. La suppression des fichiers de map, elle, reste une action ponctuelle à faire via le gestionnaire de fichiers ou en ligne de commande, parce qu'un script mal calibré qui déclenche un rm au mauvais moment efface un cycle entier de progression.

Un exemple de redémarrage quotidien via systemd sur une machine que tu administres toi-même :

sudo systemctl restart rust-server.service
sudo systemctl status rust-server.service --no-pager

Sécurité et hygiène autour du wipe

• Mot de passe RCON long, unique, jamais partagé sur Discord — c'est le vecteur numéro un de sabotage d'un cycle.
• Sous-utilisateurs du panel avec permissions limitées : ton staff n'a pas besoin d'un accès aux fichiers pour modérer.
• Sauvegardes automatiques activées en permanence, pas seulement la veille du wipe.
• Sur une machine que tu gères directement : clés SSH plutôt que mot de passe, ufw pour n'ouvrir que 28015/UDP et 28016/TCP, fail2ban sur le port SSH.

Si tu administres plusieurs jeux en parallèle avec des cycles de reset différents, la logique reste identique : identifier les fichiers de persistance, sauvegarder, arrêter, nettoyer. Tu retrouveras d'autres guides d'administration sur le Blog Fly-Serv, et le détail des jeux gérés via un panel Pterodactyl sur Tous nos serveurs de jeu.

Ce qu'il faut retenir

Un cycle réussi tient à trois choses : un type de reset cohérent avec ton public, un calendrier fixe et annoncé, et une exécution technique propre — sauvegarde, arrêt, nettoyage ciblé, nouvelle seed, plugins à jour. Le reste suit naturellement : les joueurs reviennent le jeudi soir parce qu'ils savent exactement ce qui les attend. C'est la régularité, pas la fréquence, qui fidélise.

FAQ

Peut-on wiper une map sans effacer les blueprints des joueurs ?

Oui, c'est même le cas le plus fréquent. Il suffit de supprimer les fichiers proceduralmap.*.map et proceduralmap.*.sav* en laissant intacts les fichiers player.blueprints.*.db. Les constructions disparaissent, les joueurs conservent leur arbre technologique et repartent directement en tier 2 ou 3.

Que se passe-t-il si j'oublie de wiper le jour du force wipe mensuel ?

Le numéro de protocole change avec la mise à jour : l'ancienne carte devient illisible et le monde est régénéré automatiquement au redémarrage. Tu n'as donc pas de risque de blocage, mais tu perds le contrôle sur la seed et la taille de carte si tu ne les as pas définies à l'avance. Mets à jour Oxide ou Carbon dans la foulée, sinon les plugins tomberont en erreur.

Comment conserver les grades VIP et les permissions après un full wipe ?

Sauvegarde oxide/data/oxide.groups.data et oxide/data/oxide.users.data avant de vider le dossier data, puis restaure ces deux fichiers une fois le nettoyage terminé. Les groupes, permissions et attributions par SteamID sont ainsi préservés, alors que les données de jeu (économie, kits, clans) repartent bien de zéro.