L’appel arrive généralement quand le tableau de bord est vert et que les données ont disparu. L’ensemble est « healthy ». La base de données est « running ».
Et pourtant le directeur financier regarde un rapport vide, l’équipe produit regarde un bucket vide, et vous regardez la phrase que vous auriez voulu tatouer sur le bon de commande : RAID n’est pas une sauvegarde.
RAID est excellent pour une chose : maintenir un système en ligne face à certains types de défaillance de disque. Il n’est pas conçu pour vous protéger des
suppressions, corruptions, ransomwares, incendies, doigts maladroits, firmware défaillant, ou de l’impulsion humaine étrange et intemporelle d’exécuter rm -rf
dans la mauvaise fenêtre.
Ce que le RAID fait réellement (et ce qu’il n’a jamais promis)
Le RAID est un schéma de redondance pour la disponibilité du stockage. C’est tout. C’est une manière de continuer à servir des lectures et écritures quand un disque
(ou parfois deux) cesse de coopérer. Le RAID concerne la continuité du service, pas la continuité de la vérité.
En termes de production : le RAID vous achète du temps. Il réduit la probabilité qu’une seule défaillance de disque devienne une panne. Il peut améliorer
les performances selon le niveau et la charge de travail. Il peut simplifier la gestion de capacité. Mais il ne crée pas une copie séparée, indépendante et versionnée
de vos données. Et indépendance est le mot qui vous garde votre poste.
Disponibilité vs durabilité vs capacité de restauration
Les gens confondent ces notions sous l’étiquette « sécurité des données ». Ce ne sont pas les mêmes choses :
- Disponibilité : le système peut-il continuer à fonctionner maintenant ? Le RAID aide ici.
- Durabilité : les bits resteront-ils corrects dans le temps ? Le RAID aide parfois, parfois il masque la réalité.
- Capacité de restauration : pouvez-vous restaurer un état connu et sain après un incident ? C’est le rôle des sauvegardes, snapshots, réplication et processus.
Le RAID peut continuer à servir des données corrompues. Le RAID peut répliquer fidèlement votre suppression accidentelle. Le RAID peut propager avec zèle vos blocs chiffrés par un ransomware.
Le RAID est un employé loyal. Loyal ne signifie pas intelligent.
Ce que « sauvegarde » signifie dans un système défendable
Une sauvegarde est une copie séparée des données qui est :
- Indépendante du domaine de défaillance primaire (disques différents, hôte différent, idéalement compte/crédentials différents).
- Versionnée pour pouvoir revenir avant que la catastrophe n’ait eu lieu.
- Restaurable dans un délai acceptable (RTO) et jusqu’à un point dans le temps acceptable (RPO).
- Testée, car « nous avons des sauvegardes » n’est pas un fait tant que vous n’avez pas restauré depuis elles.
Les snapshots et la réplication sont d’excellents outils. Ils ne sont pas automatiquement des sauvegardes. Ils deviennent des sauvegardes quand ils sont indépendants, protégés
contre les mêmes erreurs d’administration, et que vous pouvez les restaurer sous pression.
Blague n°1 : RAID est la ceinture de sécurité. La sauvegarde est l’ambulance. Si vous comptez sur la ceinture pour faire une chirurgie, vous allez passer une longue journée.
Pourquoi le RAID échoue comme sauvegarde : les modes de défaillance importants
La raison pour laquelle « RAID n’est pas une sauvegarde » est répétée, c’est que les modes de défaillance sont contre-intuitifs. La défaillance d’un disque n’est qu’un type de perte de données.
Les systèmes modernes perdent des données à cause des logiciels, des humains et des attaquants plus souvent que par l’explosion d’un seul disque.
1) Suppression et écrasement sont instantanément répliqués
Supprimez un répertoire. Le RAID réplique la suppression. Écrasez une table. Le RAID stripera cette nouvelle vérité sur l’ensemble. Il n’y a pas d’« annulation » parce que le travail du RAID
est de garder les copies cohérentes, pas de garder les copies historiques.
2) Corruption silencieuse, bit rot, et le piège du « ça a l’air OK »
Disques, contrôleurs, câbles et firmwares peuvent renvoyer de mauvaises données sans lever d’erreur. Les systèmes de fichiers avec sommes de contrôle (comme ZFS, btrfs) peuvent
détecter la corruption, et avec la redondance ils peuvent souvent s’auto-réparer. Le RAID traditionnel sous un système de fichiers qui ne contrôle pas les blocs
peut renvoyer joyeusement des blocs corrompus et l’appeler un succès.
Même avec des sommes de contrôle de bout en bout, vous pouvez toujours corrompre les données à un niveau supérieur : écritures applicatives erronées, compactage bogué, migrations à moitié appliquées.
Le RAID conservera la corruption parfaitement.
3) Le ransomware se moque de votre parité
Le ransomware chiffre ce qu’il peut atteindre. S’il peut accéder à votre système de fichiers monté, il peut chiffrer vos données sur RAID1, RAID10, RAID6,
miroirs ZFS, peu importe. La redondance n’empêche pas le chiffrement. Elle fait juste en sorte que le chiffrement soit hautement disponible.
4) Les pannes de contrôleur et de firmware emportent l’ensemble
Le RAID matériel ajoute un domaine de défaillance : le contrôleur, son module cache, son firmware, sa batterie/supercap, et son format de métadonnées.
Si le contrôleur meurt, vous pourriez avoir besoin d’un modèle de contrôleur identique et d’un niveau de firmware identique pour réassembler proprement l’ensemble.
Le RAID logiciel a aussi des domaines de défaillance (noyau, métadonnées md, outils utilisateurs), mais ils tendent à être plus transparents et portables.
Transparent ne veut pas dire sûr. Ça veut juste dire que vous pouvez voir le couteau avant d’y marcher dessus.
5) Les rebuilds sont stressants et s’aggravent avec la taille des disques
La reconstruction est le moment où les maths rencontrent la physique. Pendant un rebuild, chaque disque restant est lu intensivement, souvent proche de la bande passante maximale, pendant des heures ou des jours.
C’est une tempête parfaite pour révéler des erreurs latentes sur les disques restants. Si vous perdez un autre disque dans un RAID5 pendant la reconstruction, vous perdez l’ensemble.
RAID6 vous donne plus de marge, mais la reconstruction augmente toujours le risque et dégrade les performances.
6) Erreur humaine : le mode de défaillance le plus courant et le moins respecté
Un ingénieur fatigué remplace le mauvais disque, enlève la mauvaise baie, ou exécute la bonne commande sur le mauvais hôte. Le RAID ne protège pas contre les humains. Il les amplifie.
Un mauvais clic se réplique à la vitesse du réseau.
7) Catastrophes de site et rayon d’impact
Le RAID est local. Le feu est local aussi. La même chose pour le vol, les événements électriques, et « oups on a supprimé tout le compte cloud ». Une vraie stratégie de sauvegarde suppose
que vous perdrez un domaine de défaillance entier : un hôte, une baie, une région, ou un compte.
Faits intéressants et un peu d’histoire (la partie utile)
Quelques faits concrets rendent ce sujet marquant parce qu’ils montrent comment le RAID a fini par être traité comme une formule magique.
Voici neuf faits, tous pertinents, aucun romantique.
- Le RAID a été nommé et popularisé dans un article de l’UC Berkeley en 1987 qui présentait les « redundant arrays of inexpensive disks » comme une alternative aux gros disques coûteux.
- Le marketing RAID initial a beaucoup misé sur la « tolérance aux pannes », et beaucoup de gens ont traduit cela silencieusement par « protection des données », ce qui n’est pas le même contrat.
- Les niveaux RAID n’ont jamais été une norme officielle unique. Les fournisseurs implémentaient « RAID5 » avec des comportements et politiques de cache différents, puis discutaient de la sémantique pendant votre fenêtre d’incident.
- Les contrôleurs RAID matériels utilisaient historiquement des formats de métadonnées propriétaires sur disque, ce qui explique pourquoi une panne de contrôleur peut tourner à l’archéologie.
- L’arrivée des disques multi-téraoctets a rendu les rebuilds RAID5 dramatiquement plus risqués parce que le temps de reconstruction a augmenté et la probabilité de rencontrer un secteur illisible pendant le rebuild a monté.
- Les taux URE (unrecoverable read error) étaient largement discutés dans les années 2000 comme raison pratique de préférer la double parité pour les grands ensembles, surtout sous forte charge de reconstruction.
- ZFS (publié pour la première fois au milieu des années 2000) a poussé les sommes de contrôle de bout en bout dans les opérations courantes et a rendu « bit rot » acceptable en salle de réunion parce qu’on pouvait enfin le détecter.
- Les snapshots sont devenus courants dans le stockage d’entreprise dans les années 1990 mais étaient souvent stockés sur le même ensemble — rollback rapide, pas reprise après sinistre.
- Le ransomware a déplacé la conversation sur les sauvegardes de « bande vs disque » vers « immutabilité vs identifiants », parce que les attaquants ont appris à supprimer les sauvegardes en premier.
Trois mini-récits d’entreprise venant des tranchées
Mini-récit 1 : L’incident causé par une mauvaise hypothèse
Une entreprise SaaS de taille moyenne exécutait son cluster PostgreSQL principal sur une paire de serveurs haut de gamme avec RAID10 matériel. Le discours du fournisseur sonnait
rassurant : disques redondants, cache d’écriture sur batterie, hot spares. L’équipe a entendu « pas de perte de données » et rangé mentalement les sauvegardes dans la case « agréable à avoir ».
Un après-midi, un développeur a lancé un script de nettoyage contre la production. Il était censé cibler un schéma de staging ; il a ciblé celui en production.
En quelques secondes, des millions de lignes ont été supprimées. La base de données continuait de servir le trafic, et les graphiques de monitoring semblaient corrects — les requêtes étaient même plus rapides,
parce qu’il y avait moins de données.
Ils ont essayé de récupérer en utilisant la fonctionnalité de « snapshot » du contrôleur RAID, qui n’était pas un snapshot au sens système de fichiers. C’était un profil
de configuration pour le comportement du cache. Le fournisseur de stockage, à leur crédit, n’a pas ri. Il a simplement posé la question qui met fin aux carrières :
« Quels sont vos derniers backups connus bons ? »
Il n’y en avait pas. Il y avait un dump logique nocturne configuré des mois auparavant, mais il écrivait sur le même volume RAID, et le script de nettoyage a supprimé aussi le répertoire du dump.
L’entreprise a reconstruit à partir des journaux applicatifs et des flux d’événements tiers. Ils ont récupéré la plupart des choses, mais pas tout, et ont passé des semaines à corriger des dommages référentiels subtils.
La mauvaise hypothèse n’était pas « le RAID est sûr ». C’était « disponibilité implique capacité de restauration ». Ils avaient une haute disponibilité et peu de vérité.
Mini-récit 2 : L’optimisation qui s’est retournée contre eux
Une plateforme média était obsédée par les performances. Ils ont déplacé les métadonnées de leur stockage d’objets d’une configuration conservatrice vers un large RAID5 pour grappiller
plus de capacité utile et un meilleur débit d’écriture sur le papier. Ils ont aussi activé un cache contrôleur agressif pour améliorer les débits d’ingestion.
En fonctionnement normal, c’était super. Les profondeurs de file d’attente étaient basses. La latence a baissé. La direction avait sa diapositive « efficacité de stockage » pour le rapport trimestriel.
Tout le monde a mieux dormi pendant environ un mois.
Puis un seul disque a commencé à renvoyer des erreurs de lecture intermittentes. L’ensemble l’a marqué comme « predictive failure » mais l’a gardé en ligne. Une reconstruction a été lancée
vers un hot spare pendant les heures de pointe parce que le système était « redondant ». Ce rebuild a saturé les disques restants. La latence a grimpé, les timeouts ont augmenté,
et les retries applicatifs ont créé une boucle de rétroaction.
En plein rebuild, un autre disque a rencontré un secteur illisible. RAID5 ne peut pas gérer cela pendant une reconstruction. Le contrôleur a déclaré le disque virtuel défaillant.
Le résultat n’a pas été seulement une indisponibilité. C’était une corruption partielle des métadonnées qui a rendu la récupération plus lente et plus sale qu’un crash propre.
L’optimisation n’était pas malveillante ; elle était sans bornes. Ils ont optimisé pour la capacité et les performances de benchmark, puis payé le prix avec le risque de rebuild et un plus grand rayon d’impact.
Ils ont remplacé la configuration par une double parité, déplacé les fenêtres de rebuild en heures creuses, et — plus important — construit une pipeline de sauvegarde hors ensemble pour que la prochaine panne soit ennuyeuse.
Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise
Une société de services financiers exploitait un service de fichiers utilisé par des équipes internes. Le stockage était un ensemble miroir ZFS : simple, conservateur, pas excitant.
La partie excitante était leur hygiène de sauvegarde : snapshots nocturnes, réplication hors site vers un domaine administratif différent, et tests de restauration mensuels.
Tout le monde se plaignait des tests de restauration parce qu’ils « faisaient perdre du temps ». Le manager SRE les a rendus non optionnels quand même.
L’ordinateur portable d’un sous-traitant a été compromis. L’attaquant a obtenu l’accès VPN puis des identifiants privilégiés pouvant écrire sur le partage de fichiers.
Durant la nuit, un ransomware a commencé à chiffrer les répertoires utilisateurs. Comme le partage était en ligne et inscriptible, le chiffrement s’est propagé rapidement.
ZFS a fait exactement ce qu’on lui a demandé : il a stocké les nouveaux blocs chiffrés avec intégrité. Le miroir RAID a assuré que le chiffrement était durable.
Le lendemain matin, les utilisateurs ont trouvé leurs fichiers renommés et illisibles. Le miroir était « healthy ». L’entreprise ne l’était pas.
La société a mis le partage réseau hors ligne, fait pivoter les identifiants, et vérifié la cible de sauvegarde immuable. Les sauvegardes étaient stockées dans un environnement séparé
avec des permissions de suppression restreintes et des verrous de rétention. L’attaquant n’a pas pu y toucher.
La restauration n’était pas magique ; elle était pratiquée. Ils ont restauré d’abord les répertoires les plus critiques selon une liste de priorités pré-établie, puis le reste
le jour suivant. Le post-mortem était ennuyeux de la meilleure manière. La morale était aussi ennuyeuse : le processus ennuyeux bat la redondance sophistiquée.
Feuille de route pour un diagnostic rapide : trouver le goulet d’étranglement et le rayon d’impact
Quand quelque chose ne va pas avec le stockage, les équipes perdent du temps à se disputer si c’est « les disques », « le réseau » ou « la base de données ».
La bonne approche est d’établir : (1) ce qui a changé, (2) ce qui est lent, (3) ce qui est dangereux, et (4) ce en quoi vous pouvez encore avoir confiance.
Premièrement : arrêtez d’empirer la situation
- Si vous suspectez une corruption ou un ransomware, geler les écritures là où c’est possible : remonter en lecture seule, arrêter les services, révoquer les identifiants.
- Si un ensemble est dégradé et en reconstruction, envisagez de réduire la charge pour éviter une seconde défaillance pendant le rebuild.
- Commencez un journal d’incident : commandes exécutées, horodatages, changements effectués. La mémoire n’est pas une preuve.
Deuxièmement : identifiez si c’est de la performance, de l’intégrité ou de la disponibilité
- Performance : latence élevée, timeouts, profondeur de file d’attente, iowait. Les données peuvent être encore correctes.
- Intégrité : erreurs de checksum, corruption au niveau applicatif, changements inattendus de fichiers. Les performances peuvent sembler normales.
- Disponibilité : périphériques manquants, ensembles dégradés/échoués, systèmes de fichiers non montés. Le système crie.
Troisièmement : localisez rapidement le domaine de faute
- Hôte : logs noyau, erreurs disque, état du contrôleur.
- Pile de stockage : RAID/mdadm/ZFS, santé du système de fichiers, statut des scrubs.
- Chemin IO : multipath, HBA, SAS expander, NICs, switches si stockage réseau.
- Application : plans de requête, contentions de locks, boucles de retry.
- Posture de sauvegarde/restauration : avez-vous un point de restauration connu et atteignable ?
Quatrièmement : choisissez l’objectif
Dans une panne, vous devez choisir un objectif principal :
- Maintenir en fonctionnement (disponibilité) : stabiliser, accepter un mode dégradé.
- Protéger les données (intégrité) : geler les écritures, prendre des copies médico-légales, restaurer depuis un point connu bon.
- Récupérer le service (recoverability) : basculer, reconstruire ailleurs, restaurer les sauvegardes.
Ces objectifs sont en conflit. Prétendre le contraire, c’est finir avec un système qui fonctionne mais qui sert de mauvaises données.
Tâches pratiques avec commandes : quoi exécuter, ce que ça signifie, ce que vous décidez
Ci-dessous des tâches concrètes à exécuter sur des systèmes Linux pour comprendre votre posture de redondance et votre réelle capacité de restauration.
Chaque tâche inclut : commande, sortie exemple, ce que ça signifie, et la décision que vous prenez à partir de cela.
Tâche 1 : Vérifier les périphériques bloc actuels et l’appartenance RAID
cr0x@server:~$ lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINT,MODEL,SERIAL
NAME SIZE TYPE FSTYPE MOUNTPOINT MODEL SERIAL
sda 3.6T disk HGST_HUS726T4TAL K8H1ABCD
├─sda1 512M part vfat /boot/efi
└─sda2 3.6T part
sdb 3.6T disk HGST_HUS726T4TAL K8H1EFGH
└─sdb1 3.6T part
md0 3.6T raid1 ext4 /data
Ce que ça signifie : Vous avez un device RAID logiciel md0 monté sur /data, construit à partir de partitions.
Décision : Si vous pensiez avoir des « sauvegardes », ce n’est pas le cas. Il s’agit seulement de redondance. Confirmez que l’emplacement des sauvegardes est séparé.
Tâche 2 : Inspecter la santé mdadm et le statut de reconstruction
cr0x@server:~$ cat /proc/mdstat
Personalities : [raid1]
md0 : active raid1 sdb1[1] sda2[0]
3906886464 blocks super 1.2 [2/2] [UU]
unused devices: <none>
Ce que ça signifie : [UU] indique que les deux membres sont opérationnels. Pendant un rebuild vous verriez [U_] et une ligne de progression.
Décision : Si dégradé, réduisez la charge et planifiez le remplacement du disque. Aussi : prenez un snapshot de sauvegarde maintenant si vous n’en avez pas hors hôte.
Tâche 3 : Obtenir des informations détaillées mdadm, y compris les compteurs d’événements
cr0x@server:~$ sudo mdadm --detail /dev/md0
/dev/md0:
Version : 1.2
Creation Time : Mon Oct 2 11:22:09 2023
Raid Level : raid1
Array Size : 3906886464 (3726.02 GiB 4000.79 GB)
Used Dev Size : 3906886464 (3726.02 GiB 4000.79 GB)
Raid Devices : 2
Total Devices : 2
State : clean
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0
Name : server:0
UUID : 1a2b3c4d:5e6f:7890:abcd:ef0123456789
Events : 12891
Number Major Minor RaidDevice State
0 8 2 0 active sync /dev/sda2
1 8 17 1 active sync /dev/sdb1
Ce que ça signifie : « clean » est bon, mais cela ne dit rien sur le fait que les fichiers soient corrects, cohérents ou restaurables.
Décision : Utilisez ceci pour confirmer la topologie et identifier quel disque physique correspond à quel membre avant de toucher le matériel.
Tâche 4 : Vérifier les logs noyau pour erreurs IO et resets
cr0x@server:~$ sudo journalctl -k -S "1 hour ago" | egrep -i "ata|sas|scsi|i/o error|reset|timeout" | tail -n 8
Jan 22 10:11:41 server kernel: ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
Jan 22 10:11:41 server kernel: ata3.00: failed command: READ DMA EXT
Jan 22 10:11:41 server kernel: blk_update_request: I/O error, dev sdb, sector 9175040 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
Jan 22 10:11:42 server kernel: ata3: hard resetting link
Jan 22 10:11:47 server kernel: ata3: link is slow to respond, please be patient
Jan 22 10:11:52 server kernel: ata3: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
Ce que ça signifie : Les resets de lien et erreurs IO sont des signes avant-coureurs. Ça peut venir du disque, du câble, du backplane ou du contrôleur.
Décision : Traitez comme « intégrité à risque ». Lancez une sauvegarde fraîche si possible ; planifiez une maintenance et une isolation matérielle.
Tâche 5 : Interroger SMART pour la santé et les compteurs clés
cr0x@server:~$ sudo smartctl -a /dev/sdb | egrep -i "SMART overall|Reallocated_Sector_Ct|Current_Pending_Sector|Offline_Uncorrectable|Power_On_Hours"
SMART overall-health self-assessment test result: PASSED
5 Reallocated_Sector_Ct 0x0033 100 100 010 Pre-fail Always - 12
197 Current_Pending_Sector 0x0012 100 100 000 Old_age Always - 2
198 Offline_Uncorrectable 0x0010 100 100 000 Old_age Offline - 2
9 Power_On_Hours 0x0032 089 089 000 Old_age Always - 41231
Ce que ça signifie : « PASSED » n’est pas rassurant. Les secteurs en attente / offline-uncorrectable comptent davantage. Ce disque se détériore.
Décision : Remplacez de façon proactive. Si en RAID5/6, le risque de rebuild augmente ; planifiez la reconstruction avec charge réduite et sauvegardes vérifiées.
Tâche 6 : Pour le RAID matériel, vérifier l’état du contrôleur/du disque virtuel (exemple storcli)
cr0x@server:~$ sudo storcli /c0/vall show
Controller = 0
Status = Success
Description = Show Virtual Drives
DG/VD TYPE State Access Consist Cache Cac sCC Size Name
0/0 RAID5 dgrd RW No RWBD - OFF 10.913 TB data_vd0
Ce que ça signifie : Le disque virtuel est dgrd (dégradé). « Consist No » suggère qu’une vérification de cohérence est nécessaire.
Décision : Mettez en pause les écritures non essentielles, identifiez les disques défaillants/prédictifs, et assurez-vous d’avoir une sauvegarde restaurable avant la reconstruction.
Tâche 7 : Confirmer la politique de cache d’écriture et l’état batterie/supercap
cr0x@server:~$ sudo storcli /c0 show battery
Controller = 0
Status = Success
Description = Battery Status
BatteryType = iBBU
Status = Failed
Replacement required = Yes
Ce que ça signifie : Si la protection du cache est défaillante, les contrôleurs désactivent souvent le write-back cache ou risquent de perdre des écritures reconnues en cas de coupure de courant.
Décision : Attendez-vous à des changements de performance et à un risque d’intégrité si la politique est mal configurée. Remplacez la batterie/supercap et revoyez le mode de cache.
Tâche 8 : Mesurer si vous manquez de CPU ou d’IO (iostat)
cr0x@server:~$ iostat -xz 1 3
Linux 6.1.0 (server) 01/22/2026 _x86_64_ (16 CPU)
avg-cpu: %user %nice %system %iowait %steal %idle
12.34 0.00 5.12 31.45 0.00 51.09
Device r/s rkB/s rrqm/s %rrqm r_await rareq-sz w/s wkB/s w_await aqu-sz %util
md0 85.0 5420.0 0.0 0.0 18.20 63.76 40.0 3120.0 44.10 2.90 98.7
Ce que ça signifie : Un %iowait élevé et un %util proche de 100% indiquent un goulet IO. La latence d’écriture est élevée.
Décision : Limitez les jobs intensifs, vérifiez un rebuild/scrub, et envisagez de déplacer les charges chaudes hors de l’ensemble pendant que vous stabilisez.
Tâche 9 : Trouver les processus qui saturent l’IO (iotop)
cr0x@server:~$ sudo iotop -oPa -n 5
Total DISK READ: 55.43 M/s | Total DISK WRITE: 12.10 M/s
PID PRIO USER DISK READ DISK WRITE SWAPIN IO> COMMAND
18422 be/4 postgres 40.22 M/s 8.10 M/s 0.00 % 92.00 % postgres: checkpointer
27109 be/4 root 12.11 M/s 0.00 B/s 0.00 % 15.00 % rsync -aH --delete /data/ /mnt/backup/
Ce que ça signifie : Votre job de sauvegarde et la maintenance de la base se concurrencent. Ce n’est pas une leçon morale ; c’est de la physique.
Décision : Reprogrammez les sauvegardes/fenêtres de maintenance ou mettez en place une limitation de débit pour que les sauvegardes n’entraînent pas de panne (ou l’inverse).
Tâche 10 : Vérifier rapidement les erreurs du système de fichiers (exemple ext4)
cr0x@server:~$ sudo dmesg | egrep -i "EXT4-fs error|I/O error|Buffer I/O error" | tail -n 6
[915230.112233] EXT4-fs error (device md0): ext4_find_entry:1531: inode #524301: comm nginx: reading directory lblock 0
[915230.112240] Buffer I/O error on device md0, logical block 12345678
Ce que ça signifie : Le système de fichiers voit des erreurs de lecture. Le RAID peut masquer certaines défaillances, mais pas toutes.
Décision : Arrêtez les services si possible, capturez les logs, planifiez un fsck contrôlé (ou une restauration) plutôt que de laisser la corruption se propager.
Tâche 11 : Vérifier la santé du pool ZFS et les compteurs d’erreurs
cr0x@server:~$ sudo zpool status -v
pool: tank
state: DEGRADED
status: One or more devices has experienced an unrecoverable error.
action: Replace the faulted device, or use 'zpool clear' to mark the device repaired.
scan: scrub repaired 0B in 00:42:18 with 0 errors on Sun Jan 18 02:15:01 2026
config:
NAME STATE READ WRITE CKSUM
tank DEGRADED 0 0 0
mirror-0 DEGRADED 0 0 0
sdc FAULTED 0 0 8 too many errors
sdd ONLINE 0 0 0
errors: Permanent errors have been detected in the following files:
tank/data/app.db
Ce que ça signifie : ZFS a détecté des erreurs de checksum et peut indiquer quel fichier est affecté. C’est la différence entre « on pense » et « on sait ».
Décision : Traitez les fichiers nommés comme suspects. Restaurez les données affectées depuis une sauvegarde ou une réplication applicative ; remplacez le disque défaillant.
Tâche 12 : Vérifier les snapshots ZFS et si vous les confondez avec des sauvegardes
cr0x@server:~$ sudo zfs list -t snapshot -o name,creation -s creation | tail -n 5
tank/data@hourly-2026-01-22-0600 Thu Jan 22 06:00 2026
tank/data@hourly-2026-01-22-0700 Thu Jan 22 07:00 2026
tank/data@hourly-2026-01-22-0800 Thu Jan 22 08:00 2026
tank/data@hourly-2026-01-22-0900 Thu Jan 22 09:00 2026
tank/data@hourly-2026-01-22-1000 Thu Jan 22 10:00 2026
Ce que ça signifie : Sympa. Mais si ces snapshots vivent sur le même pool, ils ne survivront pas à la perte du pool, à la compromission du compte, ou à une défaillance de site.
Décision : Répliquez les snapshots vers une cible indépendante avec des identifiants différents et des protections contre la suppression.
Tâche 13 : Confirmer que des sauvegardes existent et sont récentes (exemple restic)
cr0x@server:~$ restic -r /mnt/backup/restic-repo snapshots --last
repository 9b2f1c12 opened (version 2, compression level auto)
ID Time Host Tags Paths
a1b2c3d4 2026-01-22 09:00:14 server /data
Ce que ça signifie : Vous avez un snapshot de sauvegarde datant d’aujourd’hui. C’est un début.
Décision : Validez la capacité de restauration, pas seulement l’existence. Si les snapshots cessent de s’actualiser, traitez cela comme un incident.
Tâche 14 : Faire une restauration test d’un fichier pour prouver la capacité de restauration
cr0x@server:~$ mkdir -p /tmp/restore-test && restic -r /mnt/backup/restic-repo restore latest --target /tmp/restore-test --include /data/important/report.csv
repository 9b2f1c12 opened (version 2, compression level auto)
restoring <Snapshot a1b2c3d4 of [/data] at 2026-01-22 09:00:14 by cr0x@server> to /tmp/restore-test
Summary: Restored 1 files/dirs (42.133 KiB) in 0:00
Ce que ça signifie : C’est le moment où « nous avons des sauvegardes » devient un fait. Vous avez restauré un vrai fichier avec succès.
Décision : Faites-en un exercice programmé avec sélection aléatoire de fichiers et résultats documentés.
Tâche 15 : Vérifier si votre cible de « sauvegarde » est réellement indépendante
cr0x@server:~$ mount | egrep "/data|/mnt/backup"
/dev/md0 on /data type ext4 (rw,relatime)
server:/export/backup on /mnt/backup type nfs4 (rw,relatime,vers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2)
Ce que ça signifie : Les sauvegardes vont vers NFS. L’indépendance dépend d’où se trouve ce NFS et qui peut le supprimer.
Décision : Si NFS est sur le même serveur, la même baie, ou accessible avec les mêmes identifiants admin, ce n’est pas suffisamment indépendant. Corrigez cela.
Tâche 16 : Vérifier la rétention et l’immutabilité au niveau système de fichiers (chattr)
cr0x@server:~$ sudo lsattr -d /mnt/backup
-------------e---- /mnt/backup
Ce que ça signifie : Pas de drapeaux d’immutabilité ici. Ça peut être acceptable, mais alors l’immutabilité doit provenir du système de sauvegarde ou de la cible de stockage.
Décision : Si le ransomware est dans votre modèle de menace (et il l’est), implémentez des verrous de rétention / immutabilité hors de la portée facile de l’admin principal.
Tâche 17 : Vérifier si vous n’êtes qu’à une faute de frappe de la suppression des sauvegardes (permissions)
cr0x@server:~$ namei -l /mnt/backup/restic-repo | tail -n 4
drwxr-xr-x root root /mnt
drwxr-xr-x root root /mnt/backup
drwxrwxrwx root root /mnt/backup/restic-repo
Ce que ça signifie : Dépôt de sauvegarde accessible en écriture par tous. Ce n’est pas une sauvegarde ; c’est un projet artistique communautaire.
Décision : Verrouillez les permissions, séparez les identifiants de sauvegarde, et envisagez des cibles append-only ou immuables.
Tâche 18 : Détecter un rebuild ou un scrub qui tue silencieusement les performances
cr0x@server:~$ sudo zpool iostat -v 1 3
capacity operations bandwidth
pool alloc free read write read write
-------------------------- ----- ----- ----- ----- ----- -----
tank 2.10T 1.40T 820 210 92.1M 18.2M
mirror-0 2.10T 1.40T 820 210 92.1M 18.2M
sdc - - 420 105 46.0M 9.1M
sdd - - 400 105 46.1M 9.1M
-------------------------- ----- ----- ----- ----- ----- -----
Ce que ça signifie : Des lectures soutenues élevées peuvent indiquer un scrub/resilver ou un changement de charge. Il faut corréler avec le statut du pool et les jobs cron.
Décision : Si cela coïncide avec une gêne utilisateur, reprogrammez les scrubs, ajustez la priorité de resilver, ou ajoutez de la capacité/capacité tampon.
Blague n°2 : Un rebuild RAID est l’équivalent stockage du « juste un petit changement en production ». Ce n’est jamais rapide, et ça change définitivement les choses.
Erreurs communes : symptômes → cause racine → correction
Cette section est volontairement spécifique. Un conseil générique ne survit pas à un incident ; il finit seulement cité dans le postmortem.
1) « L’ensemble est healthy, mais les fichiers sont corrompus »
- Symptômes : Erreurs applicatives en lisant des fichiers spécifiques ; mismatches de checksum au niveau app ; utilisateurs voient des médias corrompus ; RAID montre optimal.
- Cause racine : Corruption silencieuse sur disque/contrôleur/câble, ou l’application a écrit de mauvaises données. La parité/le miroir RAID l’a préservée.
- Correction : Utiliser un système de fichiers avec checksums (ZFS) ou checksums applicatifs ; lancer des scrubs ; restaurer les objets corrompus depuis des sauvegardes indépendantes ; remplacer le matériel défectueux.
2) « Nous ne pouvons pas reconstruire : un second disque a échoué pendant le rebuild »
- Symptômes : Le disque virtuel RAID5 échoue en plein rebuild ; des URE apparaissent ; plusieurs disques montrent des erreurs média.
- Cause racine : Parité simple plus disques volumineux plus charge de lecture de rebuild lourde ; marge insuffisante pour les erreurs de secteur latentes.
- Correction : Préférer RAID6/RAIDZ2 ou miroirs pour les grands ensembles ; conserver des hot spares ; exécuter des lectures de patrol/scrubs ; remplacer les disques de façon proactive ; assurer des sauvegardes restaurables avant rebuild.
3) « Les sauvegardes existent mais les restaurations sont trop lentes pour respecter le RTO »
- Symptômes : Le job de sauvegarde rapporte un succès ; la restauration prend des jours ; l’entreprise a besoin d’heures.
- Cause racine : Le RTO n’a jamais été conçu ; bande passante vers la cible de sauvegarde trop faible ; trop de données, pas de priorisation ; pas de plan de restauration par paliers.
- Correction : Définir RTO/RPO par jeu de données ; implémenter une récupération locale rapide (snapshots) plus des sauvegardes hors site ; prépositionner les jeux critiques ; pratiquer des restaurations partielles.
4) « Les snapshots nous ont sauvés… jusqu’à la perte du pool »
- Symptômes : Planning de snapshots confiant ; puis perte catastrophique du pool ; les snapshots ont disparu avec lui.
- Cause racine : Snapshots stockés dans le même domaine de défaillance que les données primaires.
- Correction : Répliquer les snapshots vers un système/compte différent ; ajouter de l’immutabilité ; considérer « même hôte » comme « même rayon d’impact ».
5) « Le ransomware a chiffré la production et les sauvegardes »
- Symptômes : Le dépôt de sauvegarde est supprimé/chiffré ; rétention purgée ; des identifiants légitimes ont été utilisés.
- Cause racine : Le système de sauvegarde est inscriptible/supprimable par les mêmes identifiants compromis en production ; pas d’immutabilité / pas d’air gap.
- Correction : Séparer les identifiants et activer MFA ; rôles sauvegarde en écriture seule ; verrou d’objet immuable ou cibles append-only ; copie hors ligne pour le pire scénario ; surveiller les événements de suppression.
6) « Les performances se sont effondrées après le remplacement d’un disque »
- Symptômes : Pics de latence après remplacement ; systèmes timeout ; rien d’autre n’a changé.
- Cause racine : Rebuild/resilver saturant l’IO ; throttling du contrôleur ; mode dégradé sur des ensembles parité.
- Correction : Planifier des fenêtres de rebuild ; limiter la vitesse de rebuild ; déplacer les charges ; ajouter des plateaux/SSDs ; garder de la marge ; ne pas reconstruire en période de pointe sauf si vous aimez le chaos.
7) « Le contrôleur est mort et nous ne pouvons pas importer l’ensemble »
- Symptômes : Les disques apparaissent mais les métadonnées d’ensemble ne sont pas reconnues ; l’outil du fournisseur ne voit pas le disque virtuel.
- Cause racine : Métadonnées RAID matériel liées à la famille/firmware du contrôleur ; défaillance du module cache ; confusion de config étrangère.
- Correction : Standardiser les contrôleurs et garder des pièces de rechange ; exporter les configs du contrôleur ; préférer le stockage défini par logiciel pour la portabilité ; surtout, avoir des sauvegardes qui ne requièrent pas l’existence du contrôleur.
Listes de contrôle / plan pas à pas : construire des sauvegardes qui survivent à la réalité
Voici le plan qui fonctionne quand vous êtes fatigué, en sous-effectif, et qu’on attend toujours de vous de ne pas vous tromper.
Il est volontairement opinionné parce que la production l’est.
Étape 1 : Classifier les données par conséquence métier
- Tier 0 : authentification/identité, facturation, données clients, base de données cœur.
- Tier 1 : outils internes, analytics, logs nécessaires pour la sécurité/forensique.
- Tier 2 : caches, artefacts de build, jeux de données reproductibles.
Si tout est « critique », rien ne l’est. Définissez RPO et RTO par tier. Écrivez-le là où la finance peut le voir.
Étape 2 : Choisir la règle de base puis la dépasser
La règle classique est 3-2-1 : trois copies des données, sur deux media/types différents, avec une copie hors site. C’est un point de départ, pas une médaille.
Pour les ransomwares, « hors site » doit aussi signifier « non supprimable par les mêmes identifiants ».
Étape 3 : Séparer volontairement les domaines de défaillance
- Matériel différent : pas « un répertoire différent ».
- Frontière administrative différente : comptes/roles séparés ; la production ne doit pas pouvoir supprimer les sauvegardes.
- Géographie différente : au moins une copie hors du site/baie/région que vous pouvez perdre.
Étape 4 : Utiliser les snapshots pour la vitesse, les sauvegardes pour la survie
Les snapshots locaux servent pour les récupérations rapides : suppressions accidentelles, mauvais déploiements, rollback rapide. Gardez-les fréquents et à courte rétention.
Les sauvegardes servent quand la machine, l’ensemble, ou le compte a disparu.
Étape 5 : Chiffrer et authentifier la pipeline de sauvegarde
- Chiffrez au repos et en transit (et gérez les clés comme si elles comptaient, parce que c’est le cas).
- Utilisez des identifiants dédiés pour les sauvegardes avec des permissions minimales.
- Privilégiez des chemins en écriture seule depuis la production vers la sauvegarde quand c’est possible.
Étape 6 : Faire de la rétention une politique, pas une vibe
- Court : horaire/quotidien pour rollback rapide.
- Moyen : hebdomadaire/mensuel pour besoins métiers/légaux.
- Long : trimestriel/annuel si requis, stocké à moindre coût et de façon immuable.
Étape 7 : Tester les restaurations comme si vous le pensiez vraiment
La sauvegarde la plus chère est celle que vous ne restaurez jamais jusqu’au jour où vous en avez besoin. Les tests de restauration doivent être planifiés, journalisés et assumés.
Faites tourner la responsabilité pour que le savoir ne vive pas dans la tête d’une seule personne.
Étape 8 : Surveiller les bonnes choses
- Fraîcheur des sauvegardes : dernier snapshot réussi par jeu de données.
- Intégrité des sauvegardes : vérification périodique ou restauration test.
- Événements de suppression : alertes sur suppressions inhabituelles de sauvegardes.
- Santé du stockage : SMART, état RAID, erreurs ZFS, résultats de scrub.
Étape 9 : Faire un exercice tabletop pour les scénarios horribles
Pratiquez :
- Suppression accidentelle (restaurer un répertoire).
- Ransomware (supposer que l’attaquant a des droits admin production).
- Panne de contrôleur (supposer que l’ensemble primaire est irrécupérable).
- Perte de site (supposer que toute la baie/région a disparu).
Étape 10 : Décidez à quoi sert le RAID (et arrêtez de lui demander d’être une sauvegarde)
Utilisez RAID/miroirs/codage d’effacement pour atteindre les objectifs de disponibilité et de performance. Utilisez des sauvegardes pour atteindre les objectifs de capacité de restauration.
Si votre choix de RAID est motivé par « nous n’avons pas besoin de sauvegardes », vous faites de l’architecture en mode souhait.
Une citation à garder au-dessus de votre moniteur
Idée paraphrasée : l’espoir n’est pas une stratégie.
— Général Jim Mattis (souvent cité dans les cercles d’ingénierie et d’opérations)
Si vous construisez du stockage sur de l’espoir, vous ne construisez pas du stockage. Vous construisez un futur rapport d’incident avec un long délai de réalisation.
FAQ
1) Si j’ai du RAID1, ai-je encore besoin de sauvegardes ?
Oui. Le RAID1 protège contre la défaillance d’un disque. Il ne protège pas contre la suppression, la corruption, le ransomware, les bugs de contrôleur, ou la perte de site.
Le RAID1 fait fonctionner le système pendant que la mauvaise chose se produit.
2) Les snapshots sont-ils une sauvegarde ?
Pas automatiquement. Les snapshots sont des références point-in-time, généralement stockées sur le même système. Ils deviennent « de type sauvegarde » seulement lorsqu’ils sont répliqués
vers une cible indépendante avec une rétention qu’on ne peut pas supprimer à la légère.
3) Le RAID6 est-il « suffisamment sûr » pour se passer de sauvegardes ?
Non. RAID6 réduit la probabilité de perte d’ensemble due à des disques pendant la reconstruction. Il ne fait rien contre les défaillances logiques (suppression, écrasement),
les maliciels, ou les événements catastrophiques. Les sauvegardes existent parce que la défaillance disque n’est pas la seule menace.
4) Qu’en est-il du stockage cloud avec redondance — est-ce que ça compte comme sauvegarde ?
La redondance du fournisseur cloud concerne typiquement la durabilité des objets stockés, pas votre capacité à récupérer de vos propres erreurs.
Si vous supprimez ou écrasez, le cloud le fera de façon fiable. Vous avez toujours besoin de versioning, de verrous de rétention et de copies indépendantes.
5) Quel est le plan de sauvegarde minimal viable pour une petite entreprise ?
Commencez par : sauvegardes quotidiennes vers une cible indépendante, au moins 30 jours de rétention, et une copie hors site. Ajoutez une rétention hebdomadaire/mensuelle si nécessaire.
Ensuite, planifiez des tests de restauration. Si vous ne faites qu’une seule chose avancée, faites les tests de restauration.
6) À quelle fréquence devons-nous tester les restaurations ?
Pour les systèmes critiques, un test mensuel est une base raisonnable, avec des restaurations partielles plus fréquentes (hebdomadaires c’est bien).
Après des changements majeurs — nouveau stockage, nouvelles clés de chiffrement, nouvel outil de sauvegarde — testez immédiatement.
7) Quelle est la différence entre réplication et sauvegarde ?
La réplication copie les données ailleurs, souvent en quasi-temps réel. C’est excellent pour la haute disponibilité et un RPO faible, mais ça peut répliquer instantanément
les mauvaises modifications. Les sauvegardes sont versionnées et conservées pour pouvoir revenir avant la défaillance. Beaucoup d’environnements utilisent les deux.
8) Comment protéger les sauvegardes contre les ransomwares ?
Séparez les identifiants et restreignez la suppression. Utilisez l’immutabilité / verrous de rétention sur la cible de sauvegarde. Gardez au moins une copie hors ligne ou dans un domaine admin séparé.
Surveillez les suppressions suspectes et désactivez l’accès au dépôt de sauvegarde depuis des hôtes à usage général.
9) ZFS élimine-t-il le besoin de sauvegardes ?
ZFS améliore l’intégrité avec des checksums et l’auto-guérison (avec redondance), et les snapshots sont excellents pour rollback rapide.
Mais ZFS ne vous empêche pas de supprimer des données, de les chiffrer, ou de perdre tout le pool. Vous avez toujours besoin de sauvegardes indépendantes.
10) Quel RPO/RTO devons-nous choisir ?
Choisissez en fonction de la douleur métier, pas de ce que l’équipe stockage souhaiterait. Pour les données Tier 0, un RPO de minutes/heures et un RTO de quelques heures peuvent être nécessaires.
Pour des tiers inférieurs, des jours peuvent être acceptables. L’important est que les chiffres soient conçus et testés, pas simplement déclarés.
Prochaines étapes à faire cette semaine
Le RAID est un outil pour rester en ligne face à certaines défaillances matérielles. Ce n’est pas une machine à remonter le temps. Ce n’est pas un témoin de tribunal. Il ne se soucie
pas de la correction des données ; il se soucie que les bits soient cohérents à travers les disques.
Si vous exploitez des systèmes de production, faites ces étapes cette semaine :
- Inventoriez votre stockage : niveau RAID, type de contrôleur, âges des disques, comportement de reconstruction.
- Notez RPO/RTO pour vos trois jeux de données principaux. Si vous ne pouvez pas, vous n’avez pas de plan de sauvegarde — vous avez un plan d’espoir.
- Vérifiez l’indépendance : confirmez que les sauvegardes vivent en dehors du domaine de défaillance primaire et hors de la portée des identifiants faciles à supprimer.
- Effectuez un test de restauration : un fichier, un répertoire, et (si vous êtes courageux) une restauration de base de données vers un environnement de test.
- Configurez des alertes pour la fraîcheur des sauvegardes et les anomalies de suppression, pas seulement pour la santé des disques.
Ensuite, et seulement ensuite, profitez de votre RAID. C’est utile quand vous le traitez honnêtement : comme de la redondance, pas comme une salvation.