Raisonne sur le stockage RAID et provoque une panne contrôlée

01Sépare trois problèmes différents

Une architecture résiliente peut utiliser les trois. Aucun des trois ne remplace automatiquement les deux autres.

02Compare les niveaux avant de manipuler

Dans les formules suivantes, N désigne le nombre de disques et S la capacité du plus petit disque.

Ces formules servent au raisonnement pédagogique. Les métadonnées, l’alignement, le système de fichiers et l’implémentation réduisent légèrement la capacité réellement disponible.

Exemple

Quatre disques de 2 To donnent approximativement :

RAID 0  → 8 To utiles, aucune tolérance
RAID 1  → dépend du type de miroir ; avec un miroir à 4 copies, 2 To utiles
RAID 5  → 6 To utiles, perte d'un disque tolérée
RAID 6  → 4 To utiles, perte de deux disques tolérée
RAID 10 → 4 To utiles, tolérance dépendant des paires touchées

03Prépare trois disques virtuels jetables

Depuis l’hyperviseur, ajoute à une VM Debian trois petits disques de même taille, par exemple 2 Go chacun.

Dans la VM :

lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS,MODEL
sudo fdisk -l

Pour la suite, l’exemple suppose que les disques jetables sont :

/dev/sdb
/dev/sdc
/dev/sdd

Adapte ces noms uniquement après vérification visuelle. Si l’un d’eux contient le système, une partition utile ou des données, arrête le TP.

Installe l’outil :

sudo apt update
sudo apt install -y mdadm
mdadm --version

04Crée un miroir RAID 1

Les deux premiers disques deviennent membres du miroir :

sudo mdadm --create /dev/md0 \
  --level=1 \
  --raid-devices=2 \
  /dev/sdb /dev/sdc

Observe immédiatement l’état :

cat /proc/mdstat
sudo mdadm --detail /dev/md0
lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS

Attends la fin de la synchronisation initiale avant de provoquer une panne. Le tableau doit être dans un état sain.

05Crée un système de fichiers et une preuve

sudo mkfs.ext4 /dev/md0
sudo mkdir -p /srv/raid-lab
sudo mount /dev/md0 /srv/raid-lab

printf 'preuve BTS RAID %s\n' "$(date --iso-8601=seconds)" |
  sudo tee /srv/raid-lab/preuve.txt

sudo sha256sum /srv/raid-lab/preuve.txt |
  sudo tee /srv/raid-lab/preuve.sha256

sudo df -h /srv/raid-lab
sudo mdadm --detail /dev/md0

Conserve :

• capacité observée ;
• état clean ou équivalent ;
• membres actifs ;
• hash du fichier.

C’est la baseline avant panne.

06Provoque la perte contrôlée d’un membre

Marque un seul membre comme défaillant :

sudo mdadm /dev/md0 --fail /dev/sdc
sudo mdadm --detail /dev/md0
cat /proc/mdstat

Retire ensuite ce membre du tableau :

sudo mdadm /dev/md0 --remove /dev/sdc
sudo mdadm --detail /dev/md0

Vérifie le service restant :

cat /srv/raid-lab/preuve.txt
cd /srv/raid-lab
sudo sha256sum -c preuve.sha256
sudo touch service-encore-disponible.txt
ls -l

07Remplace le disque et observe la reconstruction

Le troisième disque représente le remplacement :

sudo mdadm /dev/md0 --add /dev/sdd
cat /proc/mdstat
sudo mdadm --detail /dev/md0

Observe plusieurs fois :

watch -n 1 cat /proc/mdstat

Quitte watch avec Ctrl+C lorsque la reconstruction est terminée, puis vérifie :

sudo mdadm --detail /dev/md0
cd /srv/raid-lab
sudo sha256sum -c preuve.sha256

Consigne l’heure de début et de fin de reconstruction. Dans un vrai système, la reconstruction peut augmenter la charge et la période de vulnérabilité ; elle ne doit pas être considérée comme une opération instantanée.

08Explique le mode dégradé

Complète ce tableau avec tes observations :

Avant panne
- membres actifs :
- état :
- service fichier :
- hash :

Pendant panne
- membre perdu :
- état :
- service fichier :
- lecture/écriture :

Après remplacement
- nouveau membre :
- durée de reconstruction :
- état final :
- hash final :

Une preuve complète relie toujours :

état initial
→ action de panne
→ impact
→ service restant
→ remédiation
→ reconstruction
→ état final
→ limite

09Ne confonds pas disponibilité et récupération

Imagine maintenant quatre incidents :

1. /dev/sdc tombe physiquement en panne
2. un administrateur supprime preuve.txt
3. un rançongiciel chiffre le système de fichiers
4. la VM et tous ses disques sont supprimés

Avec un RAID 1 sain :

• le cas 1 peut être toléré ;
• les cas 2 et 3 sont répliqués sur les deux membres ;
• le cas 4 peut supprimer tout le tableau.

C’est la raison pour laquelle l’étape 6 réutilise aussi les leçons de sauvegarde indépendante, restauration testée et RPO/RTO.

10Nettoie uniquement le laboratoire jetable

Après avoir conservé les preuves et seulement si les trois disques sont bien ceux du TP :

cd /
sudo umount /srv/raid-lab
sudo mdadm --stop /dev/md0

sudo mdadm --zero-superblock /dev/sdb
sudo mdadm --zero-superblock /dev/sdc 2>/dev/null || true
sudo mdadm --zero-superblock /dev/sdd

Les commandes de nettoyage détruisent les métadonnées RAID. Elles ne doivent jamais être copiées sur un environnement dont les disques n’ont pas été identifiés explicitement.