Wipe Rust : comprendre et planifier la frequence de reset
Par Benjamin D. · PDG
· Mis à jour le 3 septembre 2026 · Lecture 11 min
Sommaire
Le wipe Rust est le mécanisme qui remet à zéro la carte, les constructions et, selon les cas, les blueprints d'une partie. Bien calibré, il relance la compétition ; mal calibré, il vide la population en trois jours. Voici comment fonctionne techniquement un reset, quels fichiers sont réellement concernés, et comment caler une cadence qui tient sur la durée.
Comprendre ce que fait réellement un wipe Rust
Un wipe n'est pas une case à cocher : c'est la suppression ciblée de fichiers de sauvegarde dans le dossier d'identité de ta machine de jeu. Selon les fichiers que tu supprimes, tu obtiens un reset partiel ou total. C'est cette granularité qui te permet de doser la progression de ta communauté.
Si tu administres une communauté Rust au quotidien et que tu veux une infrastructure Ryzen avec anti-DDoS et panel Pterodactyl pour appliquer ces manipulations en deux clics, regarde du côté de l'hébergeur Rust de Fly-Serv.
Les trois niveaux de reset
- Map wipe : suppression du monde et de tout ce qui est posé dessus (bases, coffres, tourelles, ressources ramassées). Les joueurs repartent nus, mais conservent leurs blueprints appris.
- Blueprint wipe (BP wipe) : suppression de la progression technologique. Chacun repart au niveau craft de base et doit relancer la recherche des composants.
- Full wipe : map + blueprints, souvent accompagné d'un nettoyage des données joueurs (statistiques, équipes, panneaux peints).
Les fichiers concernés dans le dossier d'identité
Tout se joue dans server/<identity>/. Voici la correspondance à connaître par cœur avant de toucher au gestionnaire de fichiers du panel :
| Fichier | Contenu | Supprimé lors de… |
|---|---|---|
proceduralmap.*.map | Carte générée | Map wipe (si tu changes de seed) |
proceduralmap.*.sav | Entités du monde : bases, deployables, loot | Map wipe |
player.blueprints.*.db | Blueprints appris | BP wipe |
player.deaths.*.db | Points de respawn / sacs | Full wipe (conseillé) |
player.identities.*.db | Correspondance SteamID / entités | Full wipe |
player.states.*.db | États joueurs (vie, faim, position) | Full wipe |
sv.files.*.db | Images des panneaux, skins peints | Optionnel, allège la sauvegarde |
Un map wipe propre se résume donc à ceci depuis la console de ta machine, une fois le processus arrêté :
cd /home/container/server/rustserver
rm -f proceduralmap.*.map proceduralmap.*.sav
# BP wipe en plus :
rm -f player.blueprints.*.db
# Full wipe :
rm -f player.deaths.*.db player.identities.*.db player.states.*.dbLe wipe forcé de Facepunch
Le premier jeudi de chaque mois, la mise à jour mensuelle change la version du protocole et le format de sauvegarde : la carte devient illisible et le map wipe est imposé. C'est la seule contrainte non négociable de ton calendrier. Le BP wipe, lui, reste à ta discrétion sauf annonce contraire dans les notes de version publiées par le studio (Source). Autrement dit : tu ne choisis pas si tu wipes tous les mois, tu choisis seulement à quelle fréquence supplémentaire tu le fais.
Seed et worldsize : le vrai levier de nouveauté
Supprimer les fichiers ne suffit pas à renouveler l'expérience si tu conserves la même seed : la carte régénérée sera identique. Change la valeur de server.seed à chaque cycle, ou laisse la taille du monde fixe pour que tes joueurs gardent leurs repères de densité de moniteurs.
./RustDedicated -batchmode -nographics \
+server.identity "rustserver" \
+server.port 28015 \
+server.level "Procedural Map" \
+server.seed 1874523 \
+server.worldsize 4000 \
+server.maxplayers 150 \
+server.saveinterval 300 \
+rcon.port 28016 \
+rcon.web 1Retiens la règle de dimensionnement : worldsize 3000 pour une population dense et un rythme rapide, 4000 à 4500 pour un cycle long avec beaucoup de bases. Au-delà, la consommation mémoire et le temps de génération montent sans bénéfice réel pour une population moyenne, et la latence perçue se dégrade sur les zones chargées.
Choisir la fréquence de wipe Rust adaptée à ta communauté
La fréquence de wipe Rust n'est pas une question de goût, c'est un arbitrage entre profondeur de progression et équité entre les joueurs. Plus le cycle est long, plus l'écart se creuse entre les clans installés et les nouveaux arrivants ; plus il est court, moins la construction avancée a de sens.
Les cadences qui fonctionnent
| Cadence | Profil de communauté | Effet observé |
|---|---|---|
| Map hebdomadaire (jeudi) + BP mensuel | Vanilla ou léger modding, forte population, PvP intensif | Pic de connexions chaque jeudi, très peu de décrochage, mais rush permanent |
| Map bi-mensuelle + BP mensuel | Communauté mixte, clans de 4 à 8 joueurs | Compromis solide : le temps de bâtir une base sérieuse sans stagner |
| Map mensuelle (wipe forcé uniquement) | Serveurs orientés construction, RP, PvE, taux de récolte élevés | Progression profonde, mais chute de fréquentation en fin de cycle |
| Map bi-hebdomadaire | Taux x5 et plus, sessions courtes | Renouvellement permanent, faible attachement, demande beaucoup d'animation |
Lire la courbe de population avant de trancher
La méthode la plus fiable consiste à observer ta propre fréquentation sur deux ou trois cycles complets. Note le pic du jour de wipe, puis la population à J+3, J+7 et J+14. Trois cas typiques :
- Décrochage à J+3 : ton cycle est trop long pour ton public, ou le rythme de progression est trop lent. Raccourcis, ou ajuste les taux de récolte.
- Population stable jusqu'à J+10 puis chute nette : c'est le signal d'une cadence bi-mensuelle bien calée. Ne touche à rien.
- Population plate dès J+1 : le problème n'est pas la fréquence mais la visibilité, le ping ou l'équilibrage des plugins.
Décaler ou non le créneau du jeudi
Le jeudi de wipe forcé concentre une part énorme des connexions Rust. Deux stratégies s'opposent : t'aligner sur le créneau officiel pour capter le flux de joueurs qui cherchent une partie fraîche, ou décaler ton wipe supplémentaire au vendredi soir ou au samedi matin pour récupérer ceux qui n'ont pas pu jouer le jeudi. Un cycle hebdomadaire décalé au vendredi 19h fonctionne bien pour une communauté francophone majoritairement active le week-end.
Wipe des blueprints : le paramètre le plus sensible
Le BP wipe est le levier qui remet réellement tout le monde à égalité, et c'est aussi celui qui fait fuir les joueurs qui détestent refaire la recherche. En pratique :
- BP mensuel : rythme de référence, aligné sur la mise à jour forcée.
- BP jamais wipé (hors contrainte technique) : confortable, mais crée un fossé entre les vétérans et les nouveaux, à réserver aux communautés fermées ou en whitelist.
- BP à chaque wipe : cohérent uniquement sur des taux élevés où la recherche prend moins d'une heure.
Automatiser et sécuriser le reset depuis le panel
Un wipe manuel à 19h un jeudi soir finit toujours par être oublié un jour. L'automatisation via les tâches planifiées du panel Pterodactyl évite l'erreur humaine et garantit que la machine redémarre sur une carte propre au bon moment.
Séquence d'arrêt propre
Avant toute suppression de fichiers, force une sauvegarde et un arrêt propre via RCON, sinon tu risques une écriture concurrente sur le .sav :
say "Wipe dans 5 minutes, deconnectez-vous proprement"
server.save
server.writecfg
quitPlanification avec une garde calendaire
Pour un reset hebdomadaire, une expression cron classique suffit : 0 19 * * 4. Pour cibler uniquement le premier jeudi du mois, méfie-toi : selon l'implémentation, restreindre à la fois le jour du mois et le jour de la semaine peut produire un OU logique et non un ET. Ajoute une garde dans ton script de démarrage :
#!/bin/bash
# Wipe uniquement le premier jeudi du mois
if [ "$(date +%u)" -ne 4 ] || [ "$(date +%-d)" -gt 7 ]; then
echo "Pas un premier jeudi, aucun wipe."
exit 0
fi
cd /home/container/server/rustserver
rm -f proceduralmap.*.map proceduralmap.*.sav
rm -f player.blueprints.*.db player.deaths.*.db player.states.*.db
echo "Wipe applique le $(date)"Note l'usage de %-d plutôt que %d : sans cela, une valeur comme 07 est interprétée en octal et casse la comparaison numérique. Détail idiot, panne réelle. La documentation des tâches planifiées est détaillée côté Source.
Sauvegarder avant, toujours
Déclenche une sauvegarde automatique juste avant chaque reset. Cela sert à deux choses : récupérer un monde si tu t'es trompé de fichiers, et archiver les cartes marquantes pour les remettre en rotation plus tard. Conserve au minimum les deux derniers cycles. Une archive du dossier d'identité prend quelques centaines de mégaoctets, c'est dérisoire face au coup de stress d'un rm -f mal ciblé.
tar -czf wipe-$(date +%F).tar.gz server/rustserver/Checklist du jour de wipe forcé
- Sauvegarde complète du dossier d'identité.
- Arrêt propre via RCON (
server.savepuisquit). - Mise à jour des fichiers de jeu, puis du framework de modding (Oxide ou Carbon) — dans cet ordre.
- Mise à jour des plugins : un plugin non recompilé après la mise à jour mensuelle est la première cause de plantage au redémarrage.
- Suppression des fichiers selon le niveau de wipe choisi.
- Changement de la valeur
server.seedet vérification deserver.worldsize. - Redémarrage, surveillance de la console pendant la génération du monde (compter plusieurs minutes sur une carte 4000+).
- Contrôle du
fpsserveur et du nombre d'entités une fois les premiers joueurs connectés.
Effet secondaire bienvenu : la performance
Un monde en fin de cycle accumule des dizaines de milliers d'entités : chaque base abandonnée, chaque coffre, chaque plaque de fondation pèse sur la boucle de simulation et sur le temps d'écriture des sauvegardes. Les micro-freezes ressentis par les joueurs lors du saveinterval viennent souvent de là. Le wipe remet ce compteur à zéro. Sur du NVMe avec un CPU haute fréquence, l'écriture de la sauvegarde reste courte même en fin de cycle, mais la charge CPU liée à la simulation, elle, ne dépend que du nombre d'entités actives.
Communiquer le calendrier et retenir les joueurs entre deux cycles
Un wipe Rust non annoncé est perçu comme un bug par les joueurs. Un wipe annoncé trois jours à l'avance devient un événement. La différence de fréquentation entre les deux situations est considérable.
Afficher le calendrier là où il est lu
- Dans la description en jeu : la première ligne doit contenir la cadence, au format explicite.
- Dans le nom affiché : beaucoup de joueurs filtrent directement depuis la liste des parties.
- Sur Discord : un salon dédié avec un message épinglé et un rappel automatique 24h avant.
+server.hostname "FR | Vanilla | Wipe JEUDI 19h | BP Mensuel"
+server.description "Map wipe : chaque jeudi 19h (Paris)\nBP wipe : 1er jeudi du mois\nTaux x1 - Team limit 4"Occuper la fin de cycle
La chute de population des derniers jours est mécanique : tout est construit, les grosses équipes dominent. Quelques leviers efficaces sans toucher à la cadence :
- Événements de fin de cycle : raid week-end, largages massifs, boost temporaire des taux les 48 dernières heures.
- Statistiques de cycle publiées après chaque reset (kills, ressources récoltées, temps de jeu) pour créer un objectif à long terme malgré le wipe.
- Conservation des rangs, skins ou avantages cosmétiques d'un cycle à l'autre : la progression méta survit au reset et donne une raison de revenir.
Modération et intégrité du cycle
Un cycle propre repose aussi sur des bases d'administration solides : mot de passe RCON long et unique, port RCON jamais laissé en configuration par défaut publique, sous-utilisateurs du panel avec des permissions limitées pour ton staff, et rotation des accès quand un modérateur quitte l'équipe. Un accès RCON compromis en milieu de cycle, c'est un wipe subi au pire moment. Côté réseau, la protection anti-DDoS opère en amont sur l'infrastructure : ta responsabilité porte sur les accès applicatifs et les sauvegardes.
Si tu gères plusieurs communautés en parallèle, la logique de cycle se transpose partiellement à d'autres titres survie : Serveur Valheim, Serveur Project Zomboid ou l'ensemble de Tous nos serveurs de jeu reposent sur des fichiers de sauvegarde équivalents, avec des cadences bien plus longues.
Conclusion
Le wipe n'est pas un incident, c'est le rythme cardiaque de ta communauté. Retiens l'essentiel : le premier jeudi du mois est imposé, tout le reste relève de ton arbitrage. Mesure ta courbe de fréquentation sur deux ou trois cycles, sauvegarde systématiquement avant suppression, automatise la séquence, et annonce le calendrier clairement. Le reste suivra tout seul.
FAQ
Peut-on éviter le wipe forcé du premier jeudi du mois sur Rust ?Non pour la carte : la mise à jour mensuelle modifie le format de sauvegarde du monde, l'ancien fichier .sav devient inexploitable. En revanche, tu peux parfaitement conserver les blueprints en ne supprimant pas les fichiers player.blueprints.*.db. Pense à mettre à jour Oxide ou Carbon puis tes plugins avant le redémarrage, sinon la console partira en boucle d'erreurs.
Conserve le fichier proceduralmap.*.map ainsi que la valeur de server.seed et de server.worldsize, et ne supprime que le fichier .sav qui contient les entités. Au redémarrage, le monde est identique mais totalement vide. Attention : après une mise à jour majeure du générateur de monde, la carte régénérée peut différer légèrement malgré une seed identique.
Une cadence bi-mensuelle avec un wipe des blueprints uniquement le premier jeudi du mois est le compromis le plus stable. Elle laisse le temps de bâtir une base sérieuse sans que les nouveaux arrivants ne se retrouvent face à des clans intouchables. Suis ta courbe de connexions à J+3 et J+10 : si la population s'effondre avant J+7, raccourcis le cycle ou augmente les taux de récolte.