Niveau 🟢 débutant
Durée estimée : 10 min · Prérequis : La règle 3-2-1
Ce wiki a pris le temps d'expliquer le contrat d'assurance idéal (la règle 3-2-1) avant
d'avouer honnêtement : personne ici n'a encore souscrit ce contrat sur sa propre maison. Prétendre
le contraire, ou passer ce détail sous silence, n'aiderait personne — la valeur de cette page
est justement de le dire clairement, plutôt que de laisser croire qu'une bonne pratique
expliquée équivaut à une bonne pratique appliquée.
⚠️ Cette page rompt volontairement avec le ton du reste de ce wiki. Ce n'est pas un cours
sur une notion, mais un constat honnête sur l'état réel de notre propre installation —
conforme à la règle n°1 de ce projet : documenter le réel, pas l'idéal.
L'état réel, sans détour : le serveur de ce wiki n'a, à ce jour, aucune sauvegarde en
place. Ni copie sur un support externe, ni copie hors site, ni automatisation d'aucune sorte.
Tout ce qui a été expliqué dans ce module (systèmes de fichiers, limites du RAID, règle 3-2-1)
décrit la méthode à suivre — pas un état déjà atteint sur cette machine précise.
Ce que ça signifie concrètement, en cas de panne ou d'erreur : une panne du disque unique de
la machine, une suppression accidentelle, ou un vol du matériel entraînerait aujourd'hui la
perte totale et définitive de tout ce qui a été construit et documenté dans ce dépôt sur le
serveur lui-même — configurations, données des services, historique. Seule la documentation
elle-même (ce wiki, le dépôt Git qui la contient) survivrait, puisqu'elle est versionnée et
hébergée séparément de la machine qu'elle décrit.
Pourquoi ce manque n'a pas encore été comblé — les raisons réelles, pas des excuses
déguisées : ce projet a suivi un ordre de priorités (installer, sécuriser l'accès, déployer les
premiers services, mettre en place la supervision) où la sauvegarde n'a, jusqu'ici, pas encore
atteint le haut de la liste. Ce n'est pas un désaccord sur son importance — la règle 3-2-1 vient
d'être expliquée en détail précisément parce qu'elle est jugée nécessaire — c'est un manque
d'avancement, assumé comme tel.
Ce que ce manque implique pour toi, lecteur : ne prends pas l'absence de mise en œuvre
sur ce serveur comme un signal que la sauvegarde serait secondaire ou qu'on peut s'en passer.
C'est l'inverse : ce constat honnête est présenté ici précisément pour que tu voies à quoi
ressemble un vrai risque non couvert, plutôt qu'un exemple fictif abstrait — et pour t'inciter à
ne pas reproduire ce retard sur ta propre installation.
Le schéma illustre l'asymétrie actuelle : la documentation du projet est protégée par sa nature
même (versionnée, hébergée ailleurs), mais ce qu'elle documente — le serveur réel — ne l'est pas
encore.
Pas de commande sur cette page — l'action attendue n'est pas technique mais une priorisation :
Il n'y a rien à vérifier techniquement sur cette page — seulement une question honnête à te
poser : « si mon propre serveur disparaissait maintenant, que perdrais-je réellement, et
depuis combien de temps ce risque est-il resté sans réponse ? »
| Symptôme | Cause probable | Solution |
|---|---|---|
| Repousser indéfiniment la mise en place d'une sauvegarde | Recherche d'une solution parfaite avant de commencer | Démarrer avec une sauvegarde minimale imparfaite plutôt qu'attendre la solution idéale |
| Croire qu'un projet documenté sérieusement est nécessairement protégé | Confusion entre qualité de la documentation et état réel de la protection des données | Ce sont deux choses distinctes — vérifier l'état réel plutôt que de déduire l'un de l'autre |
| Considérer cette page comme un aveu d'échec du projet | Lecture négative d'une honnêteté délibérée | C'est l'inverse : documenter un manque réel, plutôt que le taire, est cohérent avec la règle n°1 de ce projet |
Tout le contenu du serveur lui-même (configurations, données des services) — de façon totale et
définitive, faute de toute sauvegarde en place. Seule la documentation, hébergée séparément et
versionnée, survivrait.
Par cohérence avec la règle n°1 du projet (documenter le réel, pas l'idéal), et pour illustrer
concrètement ce qu'est un vrai risque non couvert, plutôt qu'un exemple fictif abstrait.
Démarrer avec une sauvegarde minimale imparfaite plutôt que de repousser indéfiniment en
attendant une mise en œuvre complète de la règle 3-2-1.
Fais, pour ta propre installation (réelle ou prévue), l'exercice honnête de cette page : que
perdrais-tu si elle disparaissait aujourd'hui, et quelle serait la plus petite action de
sauvegarde que tu pourrais mettre en place dès cette semaine ?
Aucun terme technique nouveau — cette page mobilise le vocabulaire déjà posé dans
RAID n'est pas une sauvegarde et
La règle 3-2-1.
Cette formation est proposée par Deladev, studio web de Loïc D. — création de sites et d'applications, accompagnement et formation sur mesure.
Les projets réalisés · Prestations et tarifs · Le blog tech · Me contacter
Écrite par Loïc D. avec l'assistance de Claude (Anthropic) — un travail à deux.
© 2026 Deladev — publiée sous licence CC BY-NC-ND 4.0. Vous pouvez la lire, y renvoyer par un lien, la partager et la citer en créditant la source. La revendre, l'utiliser dans une prestation ou une formation payante, la republier même partiellement ailleurs, en diffuser une version modifiée ou l'exploiter pour entraîner un modèle d'IA nécessitent une autorisation écrite — pour un usage interne en entreprise, c'est souvent oui, il suffit de demander.