« Format C: » et autres commandes qui ont ruiné des week-ends

Pourquoi les week-ends meurent : les commandes destructrices sont toujours là

« Format C: » est devenu la blague parce qu’il incarnait une vérité : les ordinateurs font exactement ce que vous leur dites de faire, pas ce que vous vouliez dire. Les systèmes modernes vous donnent simplement plus de façons d’avoir tort avec précision. Au lieu d’un disque, vous avez des couches LVM, des contrôleurs RAID qui virtualisent la réalité, des noms de périphériques multipath, des systèmes de fichiers overlay de conteneurs, des volumes cloud éphémères et des orchestrateurs capables de répliquer votre erreur à grande échelle.

Les commandes destructrices persistent parce que la suppression est une opération légitime. Nous avons besoin d’effacer des disques, de réinitialiser des nœuds, de réinitialiser des systèmes de fichiers, de trimmer des blocs et de collecter les anciens jeux de données. La différence entre hygiène et homicide tient généralement à un caractère, une hypothèse ou un modèle mental périmé.

Voici le schéma opérationnel à reconnaître : une tâche de maintenance courante croise l’incertitude (quel périphérique est lequel ?) sous pression temporelle (les alertes sonnent). L’ingénieur tente d’être efficace. L’efficacité devient rapidité. La rapidité devient conjecture. La conjecture devient un ticket « données manquantes » et un manager qui demande pourquoi les sauvegardes n’ont pas « magiquement » couvert l’incident.

Une citation à garder scotchée sur votre écran — parce qu’elle est vraie même quand on ne veut pas l’admettre — est une idée paraphrasée de John Allspaw : les incidents sont rarement le fait d’une seule mauvaise personne ; ils proviennent de personnes normales naviguant dans des systèmes désordonnés.

Autre point : les commandes destructrices ne paraissent pas toujours destructrices. Parfois, la pire commande est celle qui « corrige » un problème de performance en supprimant les garde-fous. Ou celle qui rééquilibre un cluster en « nettoyant » des volumes. Ou celle qui change des options de montage et corrompt des hypothèses, pas forcément des données.

Blague 1/2 : Une commande destructrice, c’est comme une tronçonneuse — un excellent outil, un terrible jouet d’occupation.

Faits et histoire utiles pour les postmortems d’incident

• La commande FORMAT originale de DOS n’était pas juste « effacer » ; elle écrivait des structures de système de fichiers. Cette distinction compte aujourd’hui : « formater » peut signifier réinitialiser des métadonnées, pas remplir de zéros.
• L’ordonnancement des disques par les premiers BIOS rendait l’identité des disques instable. Ce qui semblait être « Disque 0 » pouvait changer après des modifications matérielles — l’équivalent moderne est le renumérotage de /dev/sdX après reboot ou échange d’HBA.
• Le principe Unix « tout est un fichier » rend les périphériques modifiables comme des fichiers. C’est à la fois puissant et dangereux : dd ne se soucie pas de savoir si la cible est une image de test ou votre disque de démarrage.
• Beaucoup de systèmes de fichiers « suppriment » en enlevant des références, pas en effaçant le contenu. C’est pourquoi la récupération médico-légale fonctionne parfois, et pourquoi l’effacement sécurisé est un problème séparé.
• Device-mapper, LVM et multipath ont introduit de nouvelles couches d’abstraction. Elles ont résolu des problèmes (flexibilité, chemins HA) mais ont rendu « quel est ce disque ? » plus difficile sous pression.
• Les systèmes de fichiers copy-on-write ont changé les modes de défaillance. Les snapshots peuvent vous sauver d’une suppression, mais la fragmentation et la gestion d’espace peuvent aussi vous surprendre en récupération.
• Le cloud a rendu les disques jetables — et les gens ont traité les données de la même manière. « Reconstruire l’instance » va bien jusqu’au moment où l’état vivait sur le disque local de l’instance.
• Les contrôleurs RAID d’entreprise peuvent mentir par omission. Ils présentent des volumes logiques qui cachent la topologie physique, donc remplacer « le mauvais disque » peut encore casser le bon ensemble.
• L’automatisation a élargi le rayon de destruction. L’IaC qui peut reconstruire une flotte peut aussi l’effacer si la portée des variables ou le ciblage est incorrect.

Modes de panne : comment on finit par tout nuker

1) Identité ambiguë : le problème « quel disque est /dev/sdb ? »

Les noms de périphériques Linux ne sont pas une identité. Ce sont un ordre. L’ordre est une suggestion. Sur des systèmes avec plusieurs HBA, espaces de noms NVMe, LUN iSCSI ou événements hotplug, le mappage entre /dev/sdX et « le disque auquel vous pensez toucher » est un tirage au sort déguisé en déterminisme.

Les opérateurs sérieux utilisent des identifiants stables : WWN, numéro de série, chemins by-id et UUID de système de fichiers. L’erreur consiste à penser que vous pouvez « juste vérifier rapidement lsblk ». Sous la pression d’un incident, « rapidement » devient « suffisant », et « suffisant » devient « oups ».

2) Mauvais contexte : production vs staging, hôte vs conteneur, nœud vs cluster

De nombreuses « commandes destructrices » ont été exécutées sur la bonne machine — mais pas dans le bon environnement. Ou exécutées dans un conteneur alors qu’on supposait être sur l’hôte. Ou lancées sur un nœud Kubernetes alors que le volume était attaché ailleurs. Les erreurs de contexte arrivent parce que les invites mentent, les sessions SSH se multiplient, et les gens font plus confiance à la mémoire musculaire qu’aux vérifications.

3) Commandes qui paraissent sûres parce qu’on les a déjà utilisées sans problème

rm -rf est un classique, mais les succès modernes incluent mkfs sur le mauvais périphérique, parted sur le mauvais disque, zpool labelclear avant d’être sûr d’avoir des sauvegardes, et des scripts de « nettoyage » qui supposent que les chemins de périphériques sont constants. La commande elle-même n’est pas mauvaise ; c’est le manque de vérification.

4) L’optimisation déguisée en correction

Quand les systèmes sont lents, les gens deviennent créatifs. Ils désactivent les barrières, augmentent les profondeurs de queue, ajustent les ratios dirty, montent avec des options risquées ou changent le comportement d’écriture différée. Certaines optimisations sont légitimes, mais tout ce qui change l’ordre d’écriture ou les sémantiques de durabilité peut transformer une coupure de courant en corruption. Les correctifs de performance sont autorisés ; les compromis de durabilité non testés ne le sont pas.

5) Tentatives de récupération qui compliquent la récupération

Le tueur de récupération le plus courant est de continuer à écrire sur un disque après une suppression accidentelle. Le deuxième le plus courant est de « recréer » le système de fichiers en pensant que cela restaurera un point de montage. Une fois que vous lancez mkfs, vous avez écrasé des métadonnées clés. Une partie de la récupération est encore possible, mais vous êtes passé de « restaurer depuis un snapshot » à « appeler un cabinet de récupération de données et commencer à prier ».

Blague 2/2 : Les prestataires de récupération de données ne facturent pas à l’heure ; ils facturent au nombre de fois où vous avez dit « ça ira vite ».

Trois mini-histoires d’entreprise (toutes assez réelles pour faire mal)

Mini-histoire n°1 : L’incident causé par une mauvaise hypothèse

Une entreprise avait une petite flotte de réplicas de base de données utilisés pour l’analytique. Un ingénieur senior a reçu l’ordre de « nettoyer et reconstruire le plus ancien des réplicas » parce que sa latence de stockage était pire que les autres. L’hôte avait deux périphériques NVMe : un pour l’OS et un pour les données. Dans le ticket, le périphérique de données était décrit comme « le deuxième NVMe ». Cette formulation est la manière d’invoquer le chaos.

Sur cet hôte en particulier, après une mise à jour du firmware, l’ordre d’énumération avait changé. Les noms de périphériques restaient /dev/nvme0n1 et /dev/nvme1n1, mais lequel était le « data » était inversé par rapport à la mémoire de l’ingénieur. Il a lancé mkfs.xfs /dev/nvme1n1 en croyant que c’était le disque de données. C’était le disque de l’OS. Le nœud est devenu indisponible en plein milieu de la commande, comme on s’y attend.

Parce que c’était « seulement » un réplicat, la réaction initiale fut calme. Puis la calme a disparu. Le réplicat servait de source pour une pipeline aval qui était devenue silencieusement critique pour le business. Personne n’avait documenté cette dépendance. La reconstruction a pris des heures, et les consommateurs de la pipeline ont commencé à backfiller agressivement, transformant un problème de fraîcheur de données en problème de charge.

Le postmortem ne portait pas sur la commande. Il portait sur l’hypothèse : « deuxième disque = disque de données ». La correction n’était pas « soyez plus prudent ». La correction fut de standardiser sur des identifiants stables, d’étiqueter les périphériques dans l’automatisation, et de traiter « réplicat » comme « production jusqu’à preuve du contraire ».

Mini-histoire n°2 : L’optimisation qui s’est retournée contre eux

Un service gourmand en stockage peinait avec la latence d’écriture. Les ingénieurs avaient des pics pendant les heures de pointe, et l’équipe applicative demandait une « victoire rapide ». Quelqu’un a proposé d’ajuster les options de montage du système de fichiers et les paramètres VM pour réduire la latence en autorisant un writeback plus agressif. Le changement est passé pendant une fenêtre de maintenance, validé par un benchmark synthétique, et déployé.

Pendant une semaine, les courbes de latence semblaient meilleures. L’équipe a déclaré victoire. Puis il y a eu un événement d’alimentation imprévu dans une baie — bref, désordonné, le genre de chose qui « ne devrait pas arriver » jusqu’à ce que ça arrive. Après le redémarrage, plusieurs nœuds ont signalé des incohérences de système de fichiers. Quelques-uns sont revenus avec des corruptions nécessitant une restauration depuis des sauvegardes. Une victoire rapide est devenue une récupération lente.

La cause racine n’était pas « le tuning est mauvais ». C’était tuner sans modèle de menace de durabilité. Les benchmarks n’incluent pas les coupures de courant. Et une option de montage acceptable pour une couche cache peut être désastreuse pour l’état principal. Si vous changez les sémantiques d’ordre d’écriture, vous devez documenter le rayon d’impact et tester des scénarios de défaillance, pas seulement les chemins heureux de performance.

L’amélioration durable fut ennuyeuse : meilleure mesure de l’amplification d’écriture, séparation des données chaudes et froides, et choix de matériel de stockage adapté à la charge. Le tuning risqué a été annulé, et l’équipe a ajouté une politique : les changements de performance qui affectent la durabilité nécessitent une approbation explicite de l’équipe stockage/SRE et un plan de tests d’injection de pannes.

Mini-histoire n°3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une autre organisation exploitait une plateforme multi‑locataire où les données clients vivaient sur des datasets ZFS répliqués vers un second site. Ils avaient une pratique stricte : avant toute maintenance destructive, créer un snapshot avec un nom défini par le runbook et vérifier l’état de la réplication. Les ingénieurs détestaient ça parce que ça ajoutait cinq minutes à chaque tâche. Cinq minutes, c’est une éternité quand on est caféiné et confiant.

Un soir, un ingénieur on-call mettait hors service un locataire. Le ticket disait « supprimer le dataset pool/customers/acme ». Il a tapé par erreur zfs destroy -r pool/customers/acme-prod, parce que bien sûr le nommage était similaire. La commande a réussi immédiatement, et le dataset a disparu. C’est le moment où votre estomac essaie de sortir par vos chaussures.

Mais la politique de snapshots avait été respectée. Un snapshot existait depuis deux minutes, et la réplication vers le site secondaire était à jour. La récupération fut une procédure contrôlée : arrêter les services dépendants, revenir au snapshot, puis reprendre. Pas d’appels à un prestataire. Pas d’archéologie. L’incident est devenu un petit incident au lieu d’une catastrophe visible par le client.

Le postmortem n’a pas félicité d’héroïsme. Il a loué la checklist. La leçon était brute : si votre process dépend du fait que « les gens ne font jamais de fautes de frappe », votre process est fictif.

Tâches pratiques : commandes, sorties et décisions (12+)

Voici des tâches que vous pouvez lancer pendant le travail normal et pendant les incidents. Chaque tâche inclut : une commande, ce que signifie la sortie, et la décision que vous en tirez. Les commandes sont centrées Linux parce que c’est là que la plupart des moments « format C: » modernes surviennent, mais les principes s’appliquent ailleurs.

Task 1: Confirmer où vous êtes (identité de l’hôte et environnement)

cr0x@server:~$ hostnamectl
 Static hostname: prod-db-07
       Icon name: computer-vm
         Chassis: vm
      Machine ID: 9a2c3b...
         Boot ID: 4b113c...
  Virtualization: kvm
Operating System: Ubuntu 22.04.4 LTS
          Kernel: Linux 5.15.0-97-generic
    Architecture: x86-64

Signification : Cela vous indique le hostname, la virtualisation et l’OS. Si vous attendiez staging et voyez prod-, stoppez.

Décision : Si l’identité n’est pas exactement celle indiquée dans le ticket de changement, renoncez. Reconnectez-vous en utilisant le bastion/profil correct.

Task 2: Faire hurler votre invite « PROD » (vérification rapide)

cr0x@server:~$ echo "$PS1"
\u@\h:\w\$

Signification : Une invite fade encourage les erreurs de contexte.

Décision : Si vous opérez en production, utilisez une invite qui inclut l’environnement et éventuellement la couleur. C’est de l’ingénierie préventive, pas de l’esthétique.

Task 3: Lister les périphériques bloc avec identifiants stables

cr0x@server:~$ lsblk -o NAME,TYPE,SIZE,MODEL,SERIAL,WWN,MOUNTPOINTS
NAME        TYPE  SIZE MODEL          SERIAL        WWN                MOUNTPOINTS
nvme0n1     disk  476G Samsung SSD    S4EVNX0R...   0x5002538d...       
├─nvme0n1p1 part  512M                             /boot
└─nvme0n1p2 part 475G                             /
nvme1n1     disk 1.75T Intel SSD     BTTV1234...   0x55cd2e41...       
└─nvme1n1p1 part 1.75T                             /var/lib/postgresql

Signification : Vous voyez quel disque alimente quels points de montage, plus le serial/WWN pour l’identité.

Décision : Si une action destructive est prévue, enregistrez le WWN/serial dans le log de changement. Opérez sur cette identité, pas sur « nvme1n1 ».

Task 4: Vérifier les chemins de périphérique via /dev/disk/by-id

cr0x@server:~$ ls -l /dev/disk/by-id/ | sed -n '1,12p'
total 0
lrwxrwxrwx 1 root root 13 Jan 21 10:11 nvme-INTEL_SSDPE2KX020T8_BTT... -> ../../nvme1n1
lrwxrwxrwx 1 root root 13 Jan 21 10:11 nvme-SAMSUNG_MZVLW512HMJP_S4E... -> ../../nvme0n1
lrwxrwxrwx 1 root root 15 Jan 21 10:11 nvme-eui.55cd2e4141414141 -> ../../nvme1n1
lrwxrwxrwx 1 root root 15 Jan 21 10:11 nvme-eui.5002538d22222222 -> ../../nvme0n1

Signification : Ces liens symboliques fournissent des noms relativement stables. Les IDs de type EUI/WWN sont ce que vous voulez dans l’automatisation.

Décision : Utilisez le chemin by-id dans les scripts et les runbooks. Exemple : /dev/disk/by-id/nvme-eui.55cd....

Task 5: Confirmer ce qui est monté et ce qui l’utilise

cr0x@server:~$ findmnt -rno TARGET,SOURCE,FSTYPE,OPTIONS / /var/lib/postgresql
/ /dev/nvme0n1p2 ext4 rw,relatime,errors=remount-ro
/var/lib/postgresql /dev/nvme1n1p1 xfs rw,relatime,attr2,inode64,logbufs=8,logbsize=32k

Signification : Affiche le type de système de fichiers et les options de montage. Si vous êtes sur le point d’effacer un disque monté, vous vous apprêtez à passer un mauvais moment.

Décision : Si la cible est montée, arrêtez et démontez proprement (ou arrêtez d’abord les services). Si le démontage est impossible, vous avez probablement choisi la mauvaise cible.

Task 6: Identifier quels processus écrivent sur un point de montage

cr0x@server:~$ sudo lsof +f -- /var/lib/postgresql | sed -n '1,8p'
COMMAND   PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
postgres 2312  pg   cwd    DIR  259,1     4096    2 /var/lib/postgresql
postgres 2312  pg    10u   REG  259,1 10485760  123 /var/lib/postgresql/base/16384/2600
postgres 2312  pg    11u   REG  259,1  8388608  124 /var/lib/postgresql/base/16384/2601

Signification : Si vous voyez des écritures actives, vous ne pouvez pas considérer le système de fichiers comme « inactif ».

Décision : Arrêtez le service ou déplacez la charge avant toute maintenance disque. Si vous ne pouvez pas l’arrêter, replanifiez ou basculez.

Task 7: Voir la pression I/O immédiate (vérification « le stockage est-il le goulot ? »)

cr0x@server:~$ iostat -xz 1 3
Linux 5.15.0-97-generic (prod-db-07)  01/21/2026  _x86_64_  (8 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          12.10    0.00    3.22    8.45    0.00   76.23

Device            r/s     w/s   rkB/s   wkB/s  await  %util
nvme0n1          12.0   110.0   512.0  4096.0   2.10  18.0
nvme1n1         180.0   240.0  8192.0 16384.0  21.50  98.0

Signification : Un await élevé et un %util proche de 100% suggèrent que le périphérique est saturé ou subit de la latence.

Décision : Si nvme1n1 est à 98% d’utilisation avec 21ms d’attente et que votre SLO attend des ms faibles, diagnosez la charge (mise en file, amplification d’écriture) avant de « optimiser » les options de montage.

Task 8: Vérifier l’espace du système de fichiers et la pression d’inodes

cr0x@server:~$ df -hT /var/lib/postgresql
Filesystem     Type  Size  Used Avail Use% Mounted on
/dev/nvme1n1p1  xfs  1.8T  1.7T   90G  95% /var/lib/postgresql

Signification : 95% d’utilisation peut déclencher fragmentation, problèmes d’allocation et pics de latence d’écriture.

Décision : Si un système de fichiers dépasse ~85–90% pour des charges d’écriture intenses, planifiez une extension ou un nettoyage. Ne « réglez pas la performance » en désactivant les fonctions de sécurité.

Task 9: Vérifier ce que votre couche RAID/LVM pense qu’il se passe

cr0x@server:~$ sudo pvs; sudo vgs; sudo lvs -a -o +devices
  PV         VG   Fmt  Attr PSize   PFree
  /dev/sda2  vg0  lvm2 a--  931.00g 12.00g
  VG   #PV #LV #SN Attr   VSize   VFree
  vg0    1   2   0 wz--n- 931.00g 12.00g
  LV   VG   Attr       LSize   Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert Devices
  root vg0  -wi-ao---- 100.00g                                            /dev/sda2(0)
  data vg0  -wi-ao---- 819.00g                                            /dev/sda2(25600)

Signification : Si votre « disque » est en fait un PV dans un VG, l’effacer efface tout dans ce VG.

Décision : Si vous voyez LVM, traitez la pile comme un système. Planifiez les changements au bon niveau et mettez à jour les diagrammes/runbooks en conséquence.

Task 10: Confirmer les pools et datasets ZFS avant de détruire quoi que ce soit

cr0x@server:~$ sudo zpool status -v
  pool: tank
 state: ONLINE
  scan: scrub repaired 0B in 00:12:03 with 0 errors on Tue Jan 20 03:10:22 2026
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        ONLINE       0     0     0
          mirror-0                  ONLINE       0     0     0
            /dev/disk/by-id/ata-WDC_WD80...      ONLINE       0     0     0
            /dev/disk/by-id/ata-WDC_WD80...      ONLINE       0     0     0

errors: No known data errors

Signification : La topologie du pool et l’identité des périphériques sont explicites. Si vous voyez /dev/sdX ici, corrigez cela avant que ça ne devienne un cauchemar de migration.

Décision : Si vous êtes sur le point de retirer/remplacer un disque, assurez-vous d’opérer sur le périphérique by-id exact listé dans zpool status.

Task 11: Snapshot avant les opérations risquées (exemple ZFS)

cr0x@server:~$ sudo zfs snapshot -r tank/customers/acme@pre-decom-2026-01-21
cr0x@server:~$ sudo zfs list -t snapshot -o name,used,refer -r tank/customers/acme | tail -n 3
tank/customers/acme@pre-decom-2026-01-21     0B  1.2T

Signification : Le snapshot existe et est peu coûteux (0B utilisé initialement) parce qu’il référence des blocs existants.

Décision : Si la création du snapshot échoue ou si la réplication est en retard, arrêtez. Ne procédez pas à un changement destructeur sans poignée de rollback.

Task 12: Suppressions en mode dry-run (là où c’est possible) et contraindre la portée

cr0x@server:~$ rsync -aHAXn --delete /srv/app/ /srv/app.new/ | sed -n '1,8p'
deleting old-cache/tmp123
deleting old-cache/tmp124
./
config/
config/app.yaml

Signification : -n montre ce qui changerait. Le mot « deleting » devrait déclencher une revue attentive.

Décision : Si le dry run montre des suppressions inattendues, corrigez vos règles include/exclude avant d’exécuter sans -n.

Task 13: Attraper le « oups, mauvais répertoire » avant un rm -rf

cr0x@server:~$ pwd; ls -la
/var/lib/postgresql
total 24
drwx------  19 pg   pg  4096 Jan 21 10:02 .
drwxr-xr-x   3 root root 4096 Jan 10 09:11 ..
drwx------   5 pg   pg  4096 Jan 21 10:02 base
drwx------   2 pg   pg  4096 Jan 21 10:02 global

Signification : Si vous êtes dans un répertoire de données et que votre commande suivante est « nettoyage », vous jouez au hasard.

Décision : Utilisez des chemins absolus dans les commandes destructrices. Si vous devez utiliser des chemins relatifs, affichez explicitement pwd d’abord et lisez-le comme si vous révisiez un contrat.

Task 14: Prouver qu’un périphérique bloc est bien celui que vous voulez (vérification en lecture seule)

cr0x@server:~$ sudo blkid /dev/nvme1n1p1
/dev/nvme1n1p1: UUID="2a1d7c8f-3f2d-4b9d-9a7d-2ddfdd5d8b9a" TYPE="xfs" PARTUUID="b3d1..."

Signification : Cela vous indique quel système de fichiers existe et son UUID.

Décision : Si vous attendiez « pas de système de fichiers » et que vous voyez une signature XFS/ext4 valide, arrêtez. Vous êtes sur le point d’effacer quelque chose de réel.

Task 15: Inspecter les logs kernel récents pour réinitialisations et erreurs disque

cr0x@server:~$ sudo dmesg -T | egrep -i 'nvme|reset|I/O error|blk_update_request' | tail -n 8
[Tue Jan 21 10:05:11 2026] nvme nvme1: I/O 123 QID 4 timeout, aborting
[Tue Jan 21 10:05:11 2026] nvme nvme1: Abort status: 0x371
[Tue Jan 21 10:05:12 2026] nvme nvme1: resetting controller
[Tue Jan 21 10:05:14 2026] blk_update_request: I/O error, dev nvme1n1, sector 983040 op 0x1:(WRITE) flags 0x0 phys_seg 1 prio class 0

Signification : Timeouts et réinitialisations pointent vers des problèmes matériels, firmware ou pilote — souvent mal diagnostiqués comme « la base de données est lente ».

Décision : Si vous voyez des réinitialisations/timeouts, arrêtez d’ajuster le logiciel et commencez à isoler le matériel, le firmware, la mise en file ou les chemins.

Task 16: Confirmer le comportement TRIM/discard (parce que le « nettoyage » peut faire mal)

cr0x@server:~$ lsblk -D -o NAME,DISC-ALN,DISC-GRAN,DISC-MAX,DISC-ZERO
NAME     DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO
nvme0n1         0      512B       2G         0
nvme1n1         0      512B       2G         0

Signification : Le périphérique supporte discard. Selon le système de fichiers et les options de montage, les suppressions peuvent émettre des discard/TRIM et rendre la récupération médico-légale plus difficile.

Décision : Si vous comptez sur la récupération de type « undelete », supposez que discard réduit fortement la probabilité. Privilégiez snapshots/sauvegardes plutôt que l’espoir.

Méthode de diagnostic rapide : quoi vérifier en premier/deuxième/troisième

Voici la séquence « arrêter de deviner ». Vous n’avez pas besoin d’une salle de crise pour la suivre. Vous avez besoin de discipline et d’une volonté d’admettre votre erreur rapidement.

Premier : prouver ce qui échoue (symptôme vs source)

1. Le symptôme côté utilisateur est-il latence, erreurs ou données manquantes ? Des données manquantes suggèrent une action destructive ou une corruption. La latence suggère contention, saturation ou dégradation.
2. Vérifier le motif des erreurs applicatives. Les timeouts correspondent souvent à des attentes I/O ; « no such file » correspond à des suppressions/problèmes de montage ; les erreurs de checksum correspondent à la corruption.
3. Confirmer que vous êtes sur le bon hôte et le bon niveau. Conteneur vs hôte importe. Un chemin dans un conteneur peut pointer vers un volume auquel vous ne vous attendiez pas.

Deuxième : classer le goulot (CPU, mémoire, disque, réseau, contention de verrous)

1. CPU et file d’exécution : si la charge est élevée mais iowait faible, le stockage n’est pas la cause principale.
2. Pression mémoire : si le swapping est actif, tout ressemble à de la latence stockage alors que c’est une famine mémoire.
3. Saturation disque : un %util élevé et un await croissant indiquent de la mise en file ; corrélez avec des pics de charge.
4. Réseau : si le stockage est distant (iSCSI, NFS, block cloud), mesurez la latence/perte réseau.
5. Verrous et tempêtes fsync : les bases de données peuvent s’auto-infliger de la douleur I/O via des checkpoints ou des motifs sync-intensifs.

Troisième : choisir l’action suivante la plus sûre

1. Si des données pourraient être supprimées ou corrompues : arrêtez les écritures. Geler le patient. Prenez des snapshots (ou snapshots LVM) si possible.
2. Si c’est de la performance : capturez d’abord des preuves (iostat, vmstat, dmesg). Puis appliquez des mitigations réversibles (limiter le débit, déplacer la charge, ajouter de la capacité).
3. Si le matériel est suspect : ne « réparez » pas en reformattant. Isolez, basculez, remplacez.

Erreurs courantes : symptômes → cause racine → correctif

1) « J’ai formaté le mauvais disque »

Symptômes : le système ne démarre plus ; le montage échoue ; la signature du système de fichiers a changé ; plantage immédiat du service.

Cause racine : identité du disque basée sur /dev/sdX ou « deuxième disque », pas d’identifiants stables ; pas de vérifications préalables ; pas de snapshots.

Correctif : utilisez /dev/disk/by-id dans les runbooks ; exigez un lsblk avec serial/WWN capturé ; imposez un snapshot pré‑opérationnel si possible ; effectuez les actions destructrices en mode maintenance.

2) « rm -rf a supprimé plus que prévu »

Symptômes : fichiers soudainement manquants ; services qui n’arrivent pas à démarrer ; répertoires de config disparus ; logs montrant des suppressions.

Cause racine : chemin relatif lancé depuis le mauvais répertoire de travail ; expansion shell ; une variable vide (rm -rf "$DIR" avec DIR non défini) ou contenant « / ».

Correctif : utilisez des chemins absolus ; mettez set -u dans les scripts pour échouer sur variables non définies ; ajoutez des vérifications de garde comme « le répertoire doit matcher une regex » ; utilisez des dry runs (rsync -n) pour suppressions massives.

3) « dd a écrit des zéros sur le mauvais périphérique »

Symptômes : table de partitions disparue ; système de fichiers ne monte plus ; blkid ne renvoie rien ; les données semblent vides.

Cause racine : confusion de chemin de périphérique ; erreur de copier/coller ; confusion entre if= et of=.

Correctif : ne lancez jamais dd sans étape de vérification en lecture seule ; préférez des outils plus sûrs pour les opérations d’effacement ; quand vous devez utiliser dd, affichez la commande, confirmez la cible by-id et exigez une revue par un pair en production.

4) « Nous avons optimisé le disque et obtenu de la corruption plus tard »

Symptômes : après reboot ou crash, la relecture du journal échoue ; erreurs de checksum base de données ; réparations de système de fichiers nécessaires.

Cause racine : options de montage ou paramètres kernel modifiés affectant la durabilité ; barrières désactivées ; cache d’écriture RAID mal configuré sans protection batterie/flash.

Correctif : considérez les sémantiques de durabilité comme une contrainte de conception ; exécutez des tests d’injection de pannes ; documentez quelles couches peuvent échanger durabilité contre vitesse (cache) et lesquelles ne le peuvent pas (source de vérité).

5) « Tout est lent, mais seulement parfois »

Symptômes : pics de latence périodiques ; pics d’iowait ; timeouts applicatifs regroupés à des moments prévisibles.

Cause racine : jobs en arrière-plan (scrub, sauvegarde, compaction) ; expiration de snapshots ; rebuild RAID ; crédits de burst de volumes cloud épuisés.

Correctif : corrélez avec les plannings ; limitez les tâches d’arrière-plan ; isolez les voisins bruyants ; ajoutez de la capacité en steady-state plutôt que de compter sur le burst.

6) « Nous ne pouvons pas récupérer parce que nous avons continué à écrire »

Symptômes : tentative de récupération échoue ; fichiers supprimés écrasés ; outils d’undelete ne trouvent rien d’utile.

Cause racine : poursuite des écritures après la prise de conscience de la suppression ; recréation du système de fichiers ; services de nettoyage automatique en cours.

Correctif : procédure d’arrêt immédiat des écritures : arrêter les services, remonter en lecture seule si possible, détacher le volume, snapshot au niveau stockage, puis tenter la récupération.

Checklists / plan étape par étape

A. Avant toute commande destructrice sur le stockage (wipe, mkfs, destroy, labelclear)

1. Confirmer l’environnement : identité de l’hôte, compte/profil, contexte du cluster.
2. Identifier la cible par un ID stable : WWN/serial, pas sdX/nvmeX.
3. Prouver ce qui est monté : findmnt sur la cible.
4. Prouver qui écrit : lsof ou statut du service.
5. Créer une poignée de rollback : snapshot/dataset snapshot/snapshot LVM ou snapshot stockage. Si vous ne pouvez pas, obtenir une approbation explicite pour un changement irréversible.
6. Énoncer le rayon d’impact en une phrase : « Cela effacera le disque alimentant /var/lib/postgresql sur prod-db-07. » Si vous ne pouvez pas écrire cette phrase, vous ne comprenez pas le changement.
7. Revue par un pair : une autre personne lit le chemin de périphérique exact et la commande. Pas « ça a l’air bien ». Elle doit redéduire la cible.
8. Exécuter avec des garde-fous : utilisez les chemins by-id, des confirmations interactives quand disponibles, et consignez la sortie de la commande.

B. Si vous suspectez avoir lancé la mauvaise commande (contrôle des dégâts dans les 5 premières minutes)

1. Arrêter les écritures immédiatement. Arrêter les services, détacher les volumes, cordonner les nœuds — tout ce qui arrête les dégâts supplémentaires.
2. Ne lancez pas impulsivement des commandes de « réparation ». Surtout mkfs, outils de « repair » ou repartitionnement.
3. Capturer l’état : dmesg, lsblk, blkid, mount, statut couche stockage.
4. Snapshot si possible. Même un snapshot d’un volume brisé peut préserver des preuves et empêcher une perte supplémentaire.
5. Escaladez tôt. Stockage et SRE doivent être dans la boucle avant que quelqu’un n’essaie une « récupération rapide ».

C. Si le problème est « le stockage est lent » (réponse de performance sûre)

1. Mesurez d’abord : iostat, vmstat, I/O par processus et logs kernel.
2. Identifiez les principaux générateurs : quel processus ou job génère le plus d’I/O.
3. Mitigez de façon réversible : limitez les jobs batch, déplacez la charge, ajoutez des réplicas, augmentez le cache, réduisez la concurrence.
4. Puis seulement tunez : et seulement avec un plan de rollback et une évaluation de durabilité.

FAQ

1) « Formater » est‑il la même chose qu’« effacer » ?

Non. Formater écrit typiquement des métadonnées de système de fichiers (superblocs, structures d’allocation). Effacer implique écraser plus largement. L’un ou l’autre peut détruire la récupérabilité.

2) Pourquoi /dev/sdX est‑il peu fiable ?

Parce qu’il est assigné selon l’ordre de découverte. L’ordre de découverte peut changer au reboot, après des mises à jour de firmware, des changements de chemins ou l’ajout de périphériques. Utilisez les chemins by-id, les numéros de série, WWN ou UUID.

3) Si j’ai supprimé le mauvais répertoire, dois‑je remonter en lecture seule ?

Si vous pensez qu’une récupération des données est nécessaire et que vous pouvez tolérer une indisponibilité, oui — arrêtez les écritures. Les écritures écrasent les blocs libérés et réduisent les options de récupération.

4) TRIM/discard rend‑il la récupération impossible ?

Pas toujours, mais cela peut la rendre nettement plus difficile. Si des blocs sont discardés, le périphérique peut les traiter comme non mappés et retourner des zéros. Supposez que discard réduit vos chances.

5) Les snapshots remplacent‑ils les sauvegardes ?

Non. Les snapshots sont excellents pour un rollback rapide et une récupération d’erreur, mais ils partagent typiquement le même domaine de défaillance. Vous avez toujours besoin de sauvegardes séparées (et de restaurations testées).

6) Quelle est la façon la plus sûre d’exécuter des commandes risquées en production ?

Rendez l’identité non ambiguë (by-id), contraignez la portée (chemin/device exact), ajoutez une poignée de rollback (snapshot) et exigez qu’une seconde personne valide la cible.

7) Pourquoi des optimisations mènent‑elles parfois à de la corruption plus tard ?

Parce que certains changements de tuning modifient les sémantiques de durabilité : ordre d’écriture, comportement de flush, sécurité du cache ou hypothèses sur la protection contre les pertes d’alimentation. Cela peut sembler correct jusqu’à ce qu’un crash le teste.

8) J’ai lancé mkfs sur la mauvaise partition. Y a‑t‑il de l’espoir ?

Parfois. Arrêtez les écritures immédiatement. Ne relancez pas mkfs. Capturez les métadonnées et faites appel à une aide expérimentée en récupération. Votre succès dépend de ce qui a été écrasé et de combien a été écrit depuis.

9) Comment empêcher les scripts de faire des dégâts du type « rm -rf / » ?

Utilisez set -euo pipefail, validez les variables, exigez des listes blanches explicites et implémentez des prompts « êtes‑vous sûr ? » pour l’usage interactif. Pour l’automatisation, utilisez des déploiements par palier et des modes dry-run.

10) Quelle est la meilleure habitude pour éviter les ruineurs de week-end ?

Obligez‑vous à identifier les cibles par une identité stable et à dire le rayon d’impact à voix haute (ou dans le ticket) avant d’appuyer sur Entrée.

Conclusion : prochaines étapes qui réduisent vraiment le risque

Si vous ne devez retenir qu’une chose de l’ère « format C: » pour les opérations modernes, retenez ceci : les ordinateurs sont littéraux, et la production ne pardonne pas. Les commandes destructrices ne vont pas disparaître. L’objectif est de les rendre délibérées, vérifiables et récupérables.

Faites ceci ensuite :

1. Mettez à jour les runbooks pour utiliser des identifiants stables (/dev/disk/by-id, WWN/serial, UUIDs). Arrêtez de documenter « /dev/sdb » comme si c’était une loi de la nature.
2. Adoptez une politique obligatoire de snapshot pré‑destruction lorsque c’est techniquement possible, et suivez explicitement les exceptions.
3. Construisez un réflexe « arrêter les écritures » pour les incidents de perte de données suspectée. Les cinq premières minutes décident si la récupération est facile ou archéologique.
4. Séparez le tuning de performance des changements de durabilité avec une porte d’examen et un plan de rollback.
5. Entraînez‑vous à récupérer sur des environnements non‑production : restaurer depuis des sauvegardes, revenir à des snapshots, importer des pools, monter des volumes. Le meilleur moment pour apprendre n’est pas pendant une panne client.

Les week‑ends sont faits pour dormir, pas pour surveiller une barre de progression de restauration en vous demandant quelle suite de choix de vie vous a mené à « juste une petite commande rapide ».