RAIDZ1 vs RAID 5 : que se passe-t-il réellement lors d’une récupération de données ?

Lorsqu’une personne contacte un spécialiste en récupération de données au sujet d’une grappe RAID défaillante, la réponse à la question « de quel niveau RAID s’agit‑il ? » conditionne l’ensemble des opérations ultérieures. RAIDZ1 et RAID 5 reposent sur la même idée fondamentale — répartir la parité sur les disques de façon à tolérer la perte d’un disque sans perte de données — mais ils se comportent très différemment en cas de défaillance. Ces différences deviennent particulièrement évidentes lorsqu’on est confronté à une grappe dégradée. Cet article analyse ce que ces choix d’architecture impliquent pour la probabilité de défaillance, la difficulté de récupération et les outils réellement efficaces dans chaque cas.

Contenu

1. Comment chaque ensemble est réellement construit
2. Le write hole (trou d'écriture) et la corruption silencieuse
3. Capacité et performances
4. Comparaison des modes de défaillance
5. Risque de reconstruction avec des disques de grande capacité
6. Récupération des données d'un RAID‑Z1
7. Récupération de données sur RAID 5
8. RS RAID Retrieve : récupération logicielle RAID pour les deux configurations
9. Lequel choisir — et quand cela compte pour la récupération

Les deux configurations tolèrent la perte d’un seul disque. La ressemblance s’arrête là — surtout dès qu’un problème survient.

Comment chaque ensemble est réellement construit

RAID 5 répartit les données et la parité en bandes de largeur fixe sur l’ensemble des disques membres — typiquement 64 Ko ou 128 Ko, définies par le contrôleur et jamais modifiées. Toute écriture portant sur moins d’une bande complète déclenche le classique cycle lecture‑modification‑écriture : lecture des anciennes données, lecture de l’ancienne parité, calcul de la nouvelle parité, puis réécriture des deux.

Ce cycle est la cause principale du write hole (incohérence d’écriture) et de plusieurs autres problèmes, notamment la corruption silencieuse, décrits ci‑dessous.

RAIDZ1 est un type de vdev propre à ZFS — la couche pool est indissociable du système de fichiers. ZFS regroupe les blocs d’un enregistrement en une bande de largeur variable qui s’étend simultanément sur tous les disques. Il n’existe pas d’écriture partielle : chaque écriture correspond toujours à une bande complète. Cela supprime entièrement le cycle lecture‑modification‑écriture et élimine le risque de write hole.

Un vdev RAIDZ1 ne peut pas être agrandi après sa création. Il est possible d’ajouter un nouveau vdev au pool, mais le vdev original reste fixe. En revanche, de nombreuses implémentations de RAID 5 autorisent l’extension en ligne — une flexibilité qui peut parfois engendrer de nouvelles corruptions.

Le write hole (trou d’écriture) et la corruption silencieuse

Le write hole est spécifique au RAID 5 : si l’alimentation est coupée entre l’écriture des nouvelles données et la mise à jour de la parité, les blocs de données et la parité ne sont plus cohérents. La plupart des contrôleurs acceptent silencieusement cette incohérence au redémarrage suivant et déclarent l’ensemble sain — la parité est simplement erronée pour cette stripe (bande). Personne ne s’en aperçoit tant qu’un second disque ne tombe en panne lors de la reconstruction ; à ce stade, cette stripe ne peut pas être reconstituée et une perte de données survient sans aucun avertissement préalable.

ZFS évite ce problème grâce à la sémantique copy-on-write (COW) : les données ne sont jamais écrites par-dessus des blocs existants. Si l’alimentation tombe en panne en cours d’écriture, ZFS abandonne la transaction incomplète au montage suivant. L’agrégat reste toujours cohérent dès sa mise en ligne.

Le second problème d’intégrité est la corruption silencieuse des données (bitrot). Les disques restituent parfois des données erronées sans déclencher d’erreur. Le RAID 5 ne dispose d’aucune somme de contrôle pour comparer et accepte ce que le disque renvoie. ZFS calcule une somme de contrôle pour chaque bloc à l’écriture et la vérifie à la lecture — lorsqu’un bloc échoue, ZFS le reconstruit à partir de la parité et réécrit les données corrigées. Sur un RAID 5, la même corruption est transmise silencieusement à l’application.

La corruption silencieuse est plus fréquente qu’on ne le croit sur des baies en service depuis trois ans ou plus. Les ensembles RAID 5 composés de disques anciens la révèlent souvent uniquement lorsqu’une tentative de récupération met en évidence des incohérences de parité sur des dizaines de stripes — aucune d’entre elles n’ayant déclenché d’alerte du contrôleur.

Capacité et performances

Les deux configurations utilisent la même formule de capacité : (N − 1) × taille du disque, avec un minimum de trois disques. Cinq disques de 8 To fournissent 32 To d’espace utilisable dans les deux cas. Les différences portent sur le comportement en écriture :

• RAID 5 avec cache matériel protégé par batterie (BBU) gère bien les charges de travail mixtes — le cache absorbe les pics et déplace le cycle lecture‑modification‑écriture hors du chemin critique. Sans ce cache, la latence d’écriture augmente sensiblement pour les petites écritures aléatoires.
• RAIDZ1 offre de bonnes performances pour les accès séquentiels avec de grands enregistrements — stockage multimédia, sauvegardes, images de machines virtuelles. Les petites écritures aléatoires sont son point faible : chaque écriture génère une bande complète, ce qui rend les charges intensives en IOPS (bases de données, etc.) peu adaptées sans L2ARC et SLOG sur des NVMe rapides.
• Le débit de lecture séquentiel est à peu près comparable — chaque matrice lit en parallèle sur plusieurs disques, de sorte qu’aucune des deux solutions n’a d’avantage significatif sur ce point.

Comparaison des modes de défaillance

Le tableau ci‑dessous présente les scénarios les plus couramment rencontrés lors de la récupération de données et de la reconstruction RAID en conditions réelles.

Risque de reconstruction avec des disques de grande capacité

Sur des disques supérieurs à environ 4–8 To, la protection par parité simple devient un risque opérationnel sérieux. Le processus de reconstruction lit chaque secteur de chaque disque survivant — sur un disque de 16–20 To, cela prend de nombreuses heures sous une charge d’E/S élevée. Les disques d’entreprise spécifient un taux d’URE d’environ 1 erreur pour 10¹⁵ bits ; les disques grand public font en général dix fois pire. Pour une grappe de quatre disques de 12 To, une reconstruction lit ~36 To — rencontrer une URE est plausible, pas rare.

ZFS présente un avantage modeste : le resilvering ne relit que les blocs alloués. Une grappe remplie à 40 % ne reconstruit qu’environ 40 % des données. La reconstruction d’un RAID 5 lit toujours la capacité totale du disque, quel que soit le volume de données présent — différence significative en termes de durée et de risque pour des grappes partiellement remplies.

Récupération des données d’un RAID‑Z1

La récupération d’un RAID‑Z1 bénéficie de la nature auto-descriptive de ZFS. Chaque disque contient quatre copies d’étiquettes (labels) incluant le GUID du pool, la configuration des vdev et le numéro du groupe de transactions. Branchez les disques sur n’importe quelle machine exécutant ZFS : zpool import identifie et monte le pool — aucune connaissance du système d’origine n’est requise. Une défaillance de contrôleur qui rend un RAID 5 inopérant n’a aucune incidence sur un pool ZFS, dès lors que les disques restent accessibles physiquement.

Scénarios de récupération RAID‑Z1 courants, classés par ordre de difficulté :

• Erreurs de checksum ou d’E/S lors d’un scrub — ZFS marque le vdev comme dégradé et répare les blocs affectés à partir de la parité. Remplacez le disque dégradé via zpool replace, puis lancez zpool scrub. Le resilver (reconstruction) ne restaure que les blocs impactés.
• Métadonnées ZFS corrompues (uberblock, MOS, répertoire d’objets) — ZFS conserve plusieurs copies et peut revenir à un groupe de transactions antérieur. L’utilitaire zdb expose l’état interne du pool et constitue le point de départ pour une analyse forensique.
• Le pool est totalement impossible à importer (deux disques ou plus défaillants, ou labels endommagés sur plusieurs disques) — des outils logiciels de récupération deviennent nécessaires. Il faut un outil qui comprenne les pointeurs de blocs ZFS, la compression et la géométrie de bande à largeur variable, et non un utilitaire traitant l’ensemble comme un périphérique en bandes à largeur fixe.

Pour un guide détaillé de récupération de pools ZFS dans les environnements TrueNAS, voir Comment récupérer des données d’un RAID‑Z dans TrueNAS.

Récupération de données sur RAID 5

La difficulté de la récupération de données sur RAID 5 varie fortement car les paramètres de l’ensemble ne sont pas stockés dans un format lisible universellement. Les contrôleurs matériels conservent l’ordre des disques, la taille de stripe, l’algorithme de parité et le décalage des blocs dans des métadonnées propriétaires ou dans une NVRAM embarquée. Si le contrôleur tombe en panne, il faut soit un remplaçant identique (parfois avec la même version de firmware), soit un logiciel capable de reconstruire la configuration à partir des données brutes des disques. Le RAID logiciel 5 géré par mdadm est plus portable — le superbloc présent sur chaque disque membre contient les paramètres de l’ensemble. Le superbloc lui-même reste toutefois un point de vulnérabilité : s’il est écrasé, la reconstitution devient entièrement manuelle.

Les étapes critiques pour toute récupération RAID 5, dans l’ordre :

• Créer des images secteur par secteur de chaque disque avant toute intervention. Travailler sur des images plutôt que sur des disques en service permet de rejouer une opération en cas d’erreur. C’est l’étape la plus importante.
• Ne laissez pas le contrôleur lancer une reconstruction automatiquement. Si un disque survivant rencontre une erreur de lecture irrécupérable (URE) pendant la reconstruction, la bande est perdue définitivement. Désactivez la reconstruction automatique tant que vous n’avez pas d’images.
• Reconstituer l’ordre des disques — un ordre incorrect produit un ensemble apparemment valide mais corrompu. Le schéma de rotation de la parité du RAID 5 conventionnel (symétrie gauche) permet de vérifier cet ordre sans conjectures.
• Identifier la taille du stripe — valeurs courantes : 64 Ko, 128 Ko et 256 Ko. La valeur correcte fait apparaître des signatures de système de fichiers aux décalages attendus. Les outils de récupération automatisent entièrement cette étape.

Pour un examen détaillé des scénarios de panne, y compris la conduite à tenir lorsqu’un contrôleur reconfigure l’ensemble après le remplacement d’un disque, voir Comment récupérer des données d’un RAID 5.

RS RAID Retrieve : récupération logicielle RAID pour les deux configurations

Lorsque l’ensemble ne peut pas être reconstitué par le système d’exploitation — contrôleur défaillant, superbloc endommagé ou disques déplacés d’un NAS vers une autre machine — la reconstruction logicielle est l’étape appropriée avant d’envoyer les disques en laboratoire.

RS Raid Retrieve

Récupération de données à partir de baies RAID endommagées

Télécharger

Disponible pour: Windows, macOS, Linux

RS RAID Retrieve prend en charge les deux types d’ensembles sans exiger que l’utilisateur connaisse les paramètres au préalable. Principales fonctionnalités utiles pour la récupération de données :

• Détection automatique des paramètres pour RAID 5 — le logiciel teste des configurations candidates (ordres des disques, tailles de stripe, algorithmes de parité) et propose celle qui produit un système de fichiers cohérent et montable. Cela évite les essais‑erreurs susceptibles d’entraîner des corruptions supplémentaires lorsque la récupération est tentée sans paramètres vérifiés.
• Reconstruction de pool ZFS pour RAIDZ1 — lit les étiquettes de pool sur chaque disque, identifie le GUID du pool et la configuration des vdev, et reconstitue la géométrie de l’ensemble. La reconstruction réussit même si certaines étiquettes sont endommagées, tant qu’un quorum d’étiquettes lisibles subsiste.
• Extraction partielle au‑delà du seuil de tolérance aux pannes — pour des ensembles RAID 5 ou RAID 6 comportant plus de disques défaillants que ne le permet la parité, le logiciel extrait les blocs présents sur les disques survivants. En pratique, cela permet souvent de récupérer la majorité des données alors que la situation semblait irrécupérable.
• Fonctionne avec des images disque — une copie forensique de chaque disque élimine le risque d’une seconde panne pendant la tentative de récupération.

Lequel choisir — et quand cela compte pour la récupération

Le choix a des implications pour la récupération au‑delà de l’architecture. Sélectionnez en fonction de votre environnement :

• Optez pour RAIDZ1 si vous utilisez déjà ZFS (TrueNAS, Proxmox, installations Linux personnalisées). Les sommes de contrôle intégrées, la cohérence copy‑on‑write (COW) et la portabilité indépendante du contrôleur réduisent toutes la probabilité d’une situation irrécupérable. La panne d’un contrôleur est sans effet pour un pool ZFS.
• Privilégiez le RAID 5 si votre infrastructure repose sur un contrôleur RAID matériel et que vous ne disposez pas d’une infrastructure ZFS. Effectuez des vérifications de cohérence régulières, vérifiez les données SMART de tous les disques avant toute reconstruction, et maintenez une sauvegarde à jour — confirmez sa validité avant de lancer une opération de reconstruction.

Pour l’une ou l’autre configuration, le facteur déterminant pour la réussite de la récupération est ce que vous faites durant la première heure. Arrêtez immédiatement toute écriture. N’initialisez pas, ne reformatez pas et n’exécutez pas fsck / chkdsk sur les disques bruts. Créez d’abord des images disque bit‑à‑bit — puis évaluez s’il faut poursuivre une récupération logicielle ou faire appel à un laboratoire de récupération de données en fonction du nombre de disques défaillants et de tout dommage physique.

RAIDZ1 et RAID 5 partagent le même risque fondamental : une seconde défaillance pendant la reconstruction entraîne une perte de données. Pour des disques supérieurs à 8 To ou des données réellement irremplaçables, les configurations à double parité — RAIDZ2 ou RAID 6 — offrent une marge de sécurité que la parité simple ne peut garantir.