Récupération de données sur serveur RAID 5
Votre serveur RAID 5 est un système de stockage fortement sécurisé et dédié aux données très sensibles. Il peut malheureusement arriver que malgré les protections mise en place pour sécuriser votre serveur RAID 5, celui ci ne soit plus opérationnel. La configuration en Raid 5, si elle permet une protection relative en offrant la possibilité de supporter la panne d'un disque dur, présente tout de même une faiblesse notamment lorsque plus de 2 disques durs tombent en panne simultanément.
Cette faiblesse mentionnée plus haut est liée au fait que l'on recommande le plus souvent d'utiliser des disques durs identiques pour mettre en place un serveur RAID 5. Il s'agit là du talon d'achille du système car en cas de défaut matériel sur un modèle de disque dur, et cela quelque soit la raison, la probabilité pour pour que la défaillance se répercute sur tous les disques durs est très élevée.
En tout état de cause, en cas de panne ou de défaillance au niveau du boot, il est plus prudent de nous laisser faire car nous saurons comment procéder pour restituer toutes vos précieuses données. Nous ne comptons plus les serveurs RAID 5 qui nous parviennent dans un état lamentable avec par exemple tous les disques durs réinitialisés ou avec une reconstruction (rebuild) hasardeuse qui n'a pas abouti causant parfois la perte définitive des données.
La règle d'or en matière de récupération de données sur serveur RAID 5 est la suivante : en cas de doute, laissez faire nos experts.
Il est évident que la défaillance d'un serveur RAID 5 est déstabilisante. Ce n'est pas une raison pour perdre son sang froid et commettre l'irréparable.
Dans ce domaine, l'expérience et surtout le savoir-faire sont fondamentaux. Pour preuve, le Musée du Quai Branly de Paris à du faire face à une sérieuse panne de serveur RAID 5 avec bien évidemment à la clé la mise en péril de toutes les données. Une situation inenvisageable compte tenu de l'importance des données. Heureusement, grâce à notre savoir-faire et technologie nous avons pu récupérer toutes les données du musée et les restituer dans leur intégralité. De nombreux clients dont notamment le groupe Bourgeat-Matfer ont également pu bénéficier de notre savoir-faire.
Dans plus de 90% des cas les données de serveurs RAID 5 sont récupérables si le matériel nous est confié directement après la panne ! La technologie et la configuration des serveurs étant particulièrement complexe, toutes interventions inadaptées conduisent la plupart du temps à la perte définitive de données. Un drame que nous pouvons vous éviter.
COMMENT RÉCUPÉRER VOS DONNÉES SUR SERVEUR RAID 5 ?
Si vous venez de subir une perte de données sur serveur RAID 5, il est important que vous sachiez comment récupérer vos données.
Pour cela, il vous suffit de venir déposer votre serveur RAID 5 dans l'un de nos centres de dépôt. Nous vous établirons un devis sous 24/48 heures. En cas d'impossibilité de vous déplacer, n'hésitez pas à solliciter notre service gratuit de prise en charge.
Nous sommes leader de la récupération données par cartographie magnétique et nous vous proposons des prestations adaptées pour récupérer vos données sur votre serveur RAID 5.
Quelque soit votre problématique de perte de données et son degré d'urgence, nous sommes là pour vous apporter une solution. N'hésitez pas à faire appel à nos services.
Pour récupérer vos données sur serveur RAID 5, contactez-nous par téléphone au 09 83 70 00 00 / 09 83 43 43 52 ( Du lundi au vendredi de 9h à 17h ) ou par courriel.
Expert en récupération de données sur configuration RAID 5, DAFOTEC a déjà récupéré les données de nombreux serveurs dont notamment :
MUSEE PARISIEN DU QUAI BRANLY SERVEUR DE FICHIERS RAID 5 : DONNEES INTEGRALEMENT RECUPEREES GROUPE INTERNATIONAL MATFER-BOURGEAT SERVEUR DE FICHIERS NAS RAID 5 : DONNEES INTEGRALEMENT RECUPEREES DREAL PACA SERVEUR DE FICHIERS RAID 5 : DONNEES RECUPEREES COFELY INEO SERVEUR DE FICHIERS RAID 5 : DONNEES RECUPEREES |
![]() |
![]() |
|
![]() |
|
![]() |
![]() |
|
PANNES |
TARIFS |
Les prix finaux de nos prestations sont déterminés lors du diagnotic en laboratoire en fonction du degré de difficulté estimé pour récupérer vos données |
|
RAID 0, RAID 5, RAID 6 |
Forfait tout compris à partir de 450 € HT
|
CONTENU DE NOS PRESTATIONS |
Prestation complète de récupération de données + Restitution de vos données sur support de données externe + Retour |
Frais de retour de matériel si refus devis ou si impossibilité de récupérer les données |
12,54 € HT par disque dur |
EXT
Ext (Extended File System) a été lancé en 1992 comme le tout premier format spécialement conçu pour Linux. Cependant, il présentait encore des limitations de performance sérieuses et a été rapidement supplanté par Ext2. Ce système de fichiers et ses versions ultérieures Ext3 et Ext4 sont devenus le choix par défaut pour une grande majorité des distributions Linux.
Ext2 s'est avéré plus efficace grâce à sa structure, qui repose sur le concept d'inodes. Un tel descripteur d'index conserve les attributs d'un certain objet, comme un fichier ou un répertoire, et pointe vers les emplacements de ses données sous-jacentes. L'espace dans Ext2 est divisé en blocs qui forment des unités plus grandes appelées Groupes de Blocs. Les informations sur tous les Groupes de Blocs sont maintenues par la Table des Descripteurs située juste après le Superbloc. Chaque Groupe de Blocs conserve les inodes dans sa propre Table d'Inodes. Il surveille également l'état de ses blocs et de ses inodes à l'aide des Bitmaps de Blocs et d'Inodes. En revanche, le nom d'un fichier ou d'un répertoire ne fait pas partie de son inode – les noms sont mappés aux numéros d'inode correspondants via des répertoires, mis en œuvre comme un type particulier de fichiers.
La plupart des systèmes de fichiers Linux sont similaires en ce que le nom n'est pas considéré comme un attribut mais plutôt défini comme un alias pour un fichier dans un certain répertoire. Un objet de fichier peut être lié depuis de nombreux emplacements et exister sous différents noms (les soi-disant liens durs). Cela peut entraîner des difficultés sérieuses et même insurmontables pour la récupération des noms de fichiers après une suppression de fichier ou un problème logique.
Ext3 est en fait une version améliorée d'Ext2 qui prend en charge le journalisation. Le journal dans Ext3 est organisé comme un fichier journal, qui enregistre toutes les modifications du système de fichiers et le protège contre la corruption en cas de crash.
Ext4 est une amélioration par rapport à Ext3, qui a changé la méthode d'allocation des données des blocs individuels aux extensions. L'idée derrière cela est d'écrire la majorité des données d'un fichier dans une zone continue, puis de noter seulement l'adresse de son premier bloc et le nombre de blocs dans une séquence. Jusqu'à quatre étendues peuvent être stockées directement dans l'inode, tandis que les autres sont organisées en B+tree. De plus, Ext4 diffère l'opération jusqu'à ce que les données soient effectivement enregistrées sur le disque, ce qui permet de minimiser la fragmentation.
Dans l'ensemble, il est considéré comme l'un des types de systèmes de fichiers généralistes les plus flexibles, ayant également gagné une réputation de solide stabilité.
F2FS
F2FS (Flash-Friendly File System) est un autre format moderne introduit par Samsung Electronics en 2012. Il a été conçu spécifiquement pour les dispositifs de stockage basés sur la mémoire flash NAND, et est donc principalement utilisé dans les smartphones modernes et les supports de stockage amovibles.
F2FS fonctionne sur la base de l'approche du système de fichiers structuré en journal (LFS - Log-Structured File System) et prend en compte des particularités du stockage flash telles que le temps d'accès constant et le nombre limité de cycles de réécriture des données. Au lieu de créer un seul grand bloc pour l'écriture, F2FS assemble les blocs en morceaux séparés (jusqu'à 6) qui sont écrits simultanément.
Il divise son espace de stockage en segments de taille fixe. Les segments consécutifs forment une section, et plusieurs sections constituent une zone. L'allocation des données dans ces sections est effectuée à l'aide de nœuds. Ces nœuds sont de trois types : directs, indirects et inodes. Un inode stocke des métadonnées, y compris le nom, la taille et d'autres propriétés du fichier ; un nœud direct indique l'emplacement de ses blocs de données, tandis qu'un nœud indirect pointe vers des blocs dans d'autres nœuds. Les adresses physiques de ces nœuds peuvent être trouvées dans la Table d'Adresses des Nœuds (NIT). Le contenu lui-même est stocké dans la Zone Principale. Les sections de cette zone séparent les blocs de données des blocs de nœuds avec des informations de service. L'état d'utilisation de tous les blocs est enregistré par la Table d'Information des Segments (SIT). La Zone de Résumé des Segments (SSA) spécifie quels blocs sont attribués à quels nœuds.
Lorsqu'il n'y a plus de segments libres, F2FS effectue un nettoyage en arrière-plan lorsque le système est inactif. L'algorithme de nettoyage sélectionne les segments à "victimiser" en fonction du nombre de blocs utilisés selon la SIT ou de leur ancienneté.
L'organisation décrite permet à F2FS de bien fonctionner sur le stockage à état solide. Cependant, jusqu'à présent, il a été principalement appliqué sur des dispositifs portables et est rarement rencontré sur des machines de bureau ou des serveurs.
JFS
JFS (Journaled File System) a été créé par IBM en 1990. La version originale, parfois appelée JFS1, a été implémentée dans le système d'exploitation AIX de l'entreprise. Plus tard, JFS2 a été publié et porté sur Linux après qu'il soit devenu open-source.
Un volume JFS est composé de régions appelées Groupes d'Allocation, et chacune d'elles contient un ou plusieurs FileSets. Tous les fichiers et répertoires sont décrits par leurs inodes individuels, tandis que le contenu des données est représenté par une ou plusieurs étendues. Toutes les étendues sont indexées par un arbre B+ dédié. Le contenu des petits répertoires est stocké directement dans leurs inodes, tandis que les répertoires plus grands sont organisés sous forme d'arbres B+. Les arbres B+ contrôlent également l'utilisation de l'espace de stockage : le premier arbre stocke les blocs de départ des étendues libres, et le deuxième lève le nombre d'étendues libres. JFS comprend également une zone de journal distincte et écrit dedans chaque fois qu'une modification des métadonnées se produit.
En général, JFS est considéré comme un système de fichiers rapide et fiable. Cependant, il ne subit que peu d'améliorations et tombe progressivement en désuétude, étant surpassé par des options plus modernes.
ReiserFS
ReiserFS est un format alternatif sous Linux, optimisé pour le stockage d'un grand nombre de petits fichiers. Il a été initialement conçu par Namesys en 2001 et a introduit plusieurs nouvelles fonctionnalités qui étaient très innovantes à l'époque de sa présentation. Cependant, finalement, sa maintenance a été confiée à des bénévoles en raison de certains problèmes techniques.
ReiserFS est organisé autour de l'arbre S+, composé de nœuds internes et de nœuds de feuilles. Cette structure est utilisée pour gérer tous les fichiers, répertoires et métadonnées. Elle contient des éléments de quatre types de base : les éléments directs, indirects, de répertoire et de statut. Les éléments directs contiennent les données réelles, les éléments indirects ne font que lier à certains blocs de données, les éléments de répertoire représentent les entrées dans un répertoire, et les éléments de statut contiennent les propriétés des fichiers et des dossiers. Chaque élément possède une clé unique utilisée pour le localiser dans l'arbre. Cette clé comprend l'identifiant, l'adresse et le type de l'élément.
Les fichiers et fragments de fichiers qui ne remplissent pas tout le bloc sont combinés et stockés directement dans les nœuds de feuilles de l'arbre S+. Ce mécanisme est appelé "tail-packing", et il aide à réduire la quantité d'espace gaspillé et la fragmentation. De plus, ReiserFS ne fait pas directement de modifications dans l'arbre S+ – il les écrit d'abord dans le Journal, puis les copie à l'emplacement requis sur le stockage.
En somme, ReiserFS possède de bonnes capacités de recherche et permet une allocation compacte des petits fichiers. Cependant, ce format n'est plus activement supporté et il est très peu probable qu'il reste pertinent dans un avenir proche.
XFS
Introduction à XFS
XFS est l'un des systèmes de fichiers les plus robustes déployés sous Linux. Il a été initialement conçu par Silicon Graphics Inc. et publié en 1994 sur leur plateforme UNIX basée sur IRIX. Par la suite, le système de fichiers a été remis à la communauté open-source, qui, en 2001, l'a intégré au noyau Linux. Depuis, il a fait son chemin dans toutes les grandes distributions Linux. Celles basées sur Red Hat choisissent même ce format par défaut lors de l'installation, comme CentOS, RHEL et Rocky Linux.
Créé avec des dispositifs à haute capacité à l'esprit, XFS est surtout connu pour ses hautes performances lorsqu'il s'agit de traiter de grandes quantités de données. Ce système de fichiers se trouve généralement sur des serveurs, des baies de stockage, et moins fréquemment sur des PC grand public. Sa popularité a également augmenté avec l'utilisation généralisée des boîtiers NAS, une grande part de ceux-ci étant fournis avec XFS dès leur fabrication, y compris des marques comme Buffalo LinkStation et TeraStation, NetGear, LaCie, Iomega et autres.
Malgré son âge avancé, le système de fichiers est toujours en développement. Il a subi plusieurs modifications, et nous avons maintenant la troisième génération de XFS qui est largement utilisée depuis quelques années :
1ère génération XFS – XFS simple de SGI pour le système IRIX basé sur UNIX ; 2ème génération XFS – XFS Linux plus ancien au format étendu, actuellement appliqué principalement dans les unités NAS ; 3ème génération XFS – XFS Linux (génération 3), la version la plus récente utilisée dans les systèmes modernes basés sur Linux, où le format des métadonnées sur disque a été modifié pour une identification et une vérification plus faciles.
XFS peu créer un volume de 18 exaoctets et de gérer des fichiers individuels aussi grands que 9 exaoctets. Le nombre de fichiers est limité uniquement par la quantité d'espace disponible. Le système de fichiers peut croître tant qu'il y a des blocs non alloués et peut même s'étendre sur plusieurs dispositifs physiques.
En tant que système de fichiers journalisé, XFS enregistre les modifications avant qu'elles ne soient validées dans ses structures internes, ce qui garantit sa cohérence générale en cas de plantage ou de perte de puissance.
Structure de base du système de fichiers
XFS a une organisation orientée par les extensions. Plutôt que d'allouer son espace en blocs individuels, il les combine en unités contiguës de longueurs variables appelées Ext. Un fichier unique peut être composé de plusieurs étendues lorsque une plage contiguë sur le stockage n'est pas disponible pour lui. Cependant, XFS s'efforce de garder leur nombre aussi petit que possible et tente de fusionner les étendues au fur et à mesure de la croissance du fichier. Les informations relatives à un fichier (métadonnées du fichier) sont stockées dans son inode. Ces inodes sont alloués en morceaux, 64 par morceau.
Le système de fichiers lui-même peut être divisé en jusqu'à trois parties distinctes :
Section des données : Cette section contient les métadonnées du système de fichiers et les données des fichiers utilisateurs. L'espace de stockage qu'elle contient est subdivisé en groupes d'allocation égaux. La taille minimale d'un groupe d'allocation est de 16 Mo et la taille maximale est d'environ 1 To. Chaque groupe d'allocation contrôle de manière autonome l'utilisation de l'espace dans ses limites. Par conséquent, les processus concurrents peuvent effectuer des allocations à travers le système de fichiers en parallèle sans interférer les uns avec les autres.
Section du journal : Cette zone stocke les modifications des métadonnées du système de fichiers. L'entrée dans le journal pour chaque élément structurel consiste en des informations d'en-tête le décrivant et une copie de sa nouvelle image telle qu'elle doit apparaître sur le disque. L'entrée est conservée dans le journal jusqu'à ce que ces changements soient réellement validés dans la section des données. En cas de plantage, le journal peut être lu pour terminer les opérations interrompues et restaurer la cohérence du système de fichiers.
Section temps réel : Cette section optionnelle stocke uniquement les données des fichiers temps réel – ceux ayant des exigences spéciales en matière de vitesse I/O. Elle est généralement placée sur un dispositif de stockage à haute performance. La section est divisée en un certain nombre d'étendues de taille fixe. L'allocation dans cette section se fait de manière plus simple et est gérée à l'aide d'un bitmap linéaire.
Avantages et inconvénients de XFS
Grâce à sa conception, XFS excelle dans l'organisation des gros fichiers, des répertoires et des volumes ainsi que dans la gestion de vastes quantités de fichiers. Il offre également de nombreuses fonctionnalités qui le rendent optimal pour les grands systèmes de calcul et autres environnements nécessitant un système de fichiers fiable et performant. Parmi ces fonctionnalités, on peut citer :
Réduction de la fragmentation et de l'éparpillement des fichiers : XFS s'efforce de stocker les fichiers de manière aussi contiguë que possible. Le concept d'étendues lui permet d'allouer efficacement des plages libres de blocs adjacents, tandis que les arbres B+ facilitent la recherche d'étendues libres.
Adaptabilité aux systèmes de stockage multi-composants : XFS peut s'étendre sur plusieurs dispositifs de stockage et possède son propre gestionnaire de volumes. Pour les configurations de disques en grappe (par exemple, RAID 5), il est possible de définir la taille de chaque unité de bande et le nombre d'unités par bande lors de la création du système de fichiers. XFS utilisera ces informations pour placer les données en fonction des spécifications du stockage et atteindre ainsi de meilleures performances.
Opérations I/O parallèles rapides : XFS est optimisé pour un accès parallèle. Comme mentionné précédemment, il divise l'espace de stockage en groupes d'allocation indépendants. Chaque groupe d'allocation se comporte presque comme un système de fichiers séparé contrôlant l'utilisation de l'espace de son propre groupe et écrivant ses propres métadonnées. Par conséquent, ces groupes d'allocation peuvent être adressés simultanément par le noyau, et plusieurs opérations parallèles n'affectent pas les performances.
Haute probabilité de récupération : XFS utilise la journalisation des métadonnées, ce qui facilite sa récupération après des plantages système ou des pannes de courant. Les données utilisateur, en cas de perte, ont également de bonnes chances d'être récupérées.
Cependant, ce système de fichiers robuste présente plusieurs points faibles. Tout d'abord, XFS n'utilise pas de sommes de contrôle (checksums). Par conséquent, il ne peut pas garantir que les données stockées restent toujours intactes. Certains fichiers peuvent être corrompus, et les secteurs endommagés peuvent être découverts trop tard, entraînant une perte de données importante. En outre, XFS ne journalise pas les modifications des données utilisateur, comme il le fait pour ses structures internes. Par conséquent, une extinction inattendue du système d'exploitation peut entraîner la perte d'informations provenant de fichiers récemment créés ou modifiés.
En résumé, bien que présentant quelques défauts mineurs, XFS est un système de fichiers fiable et polyvalent. Ainsi, il peut être un excellent choix de format, surtout pour les solutions de stockage volumineuses.
ZFS
Le système de fichiers ZFS est un système de fichiers extrêmement puissant, un gestionnaire de volumes et un contrôleur RAID logiciel tout en un.
ZFS et ses équivalents des niveaux RAID.
ZFS a ses propres dénominations pour ses implémentations RAID logicielles. Elles sont intrinsèquement identiques aux niveaux RAID traditionnels, les seules différences mineures venant de la résilience accrue de ZFS grâce à la nature de son architecture. Nous allons voir les équivalents ZFS de chaque niveau RAID.
Équivalents des niveaux RAID avec ZFS :
ZFS a des niveaux RAID similaires à un RAID matériel traditionnel, mais avec des noms et des implémentations différents. Il utilise des RAIDs plus petits dans des partitions appelées "VDevs" (dispositifs virtuels). Lorsque vous assemblez plusieurs VDevs, vous créez un "zpool", après quoi les VDevs ne peuvent plus être retirés.
RAID0 - Également connu sous le nom de Striping, le RAID0 répartit vos données sur plusieurs disques pour obtenir la vitesse accrue de la lecture et de l’écriture simultanées. C'est le niveau RAID offrant les meilleures performances et l’utilisation la plus efficace de l’espace, mais il ne procure aucune sécurité des données. En cas de défaillance d'un disque, tout votre pool de stockage peut être perdu ! ZFS appelle cela un VDev striped et offre une protection légèrement plus grande contre la corruption silencieuse (perte de consistence) des données par rapport à un RAID0 standard grâce à son auto-répération avec les sommes de contrôle.
Cependant, cette configuration entraînera toujours la perte du pool en cas de défaillance d’un disque, ce qui fait de ce niveau un mauvais choix pour quiconque ne veut pas prendre un grand risque de perdre toutes ses données.
RAID1 - Ce niveau fait un miroir des données entre les disques, pour avoir essentiellement une sauvegarde locale de toutes vos données. Sur ZFS, cela se fait simplement en faisant un miroir entre les VDevs. Avec ZFS, vous pouvez faire des miroirs autant de fois que vous le souhaitez pour protéger votre système contre la défaillance d'un disque. Le RAID1 est souvent utilisé avec d'autres niveaux RAID ou pour les disques de démarrage, car son efficacité en termes d’espace est moins bonne que celle des niveaux RAID à parité.
RAID5 - Dans ZFS, RAID5 s'appelle RAIDZ1. RAID5 utilise un bloc de parité qui lui permet de reconstruire les données perdues en cas de défaillance d’un disque. Il effectue également le même striping des données sur plusieurs disques comme le RAID0. Cela permet d'obtenir de très bonnes performances. C’est l'un des niveaux RAID les plus populaires en raison de sa combinaison de performances et de sécurité des données. RAID5 protège vos données contre une défaillance de disque, mais si un autre disque tombe en panne avant que la reconstruction ne soit terminée, tout le pool peut être perdu. RAIDZ1 présente un avantage par rapport au RAID5 car il a résolu le syndrome de "trou d’écriture" (Write-hole phenomenon) qui affecte généralement les niveaux RAID avec parité et striping.
RAID6 - RAID6 est similaire à RAID5, mais avec deux disques de parité au lieu d’un. L'équivalent de ZFS est RAIDZ2. C'est un niveau RAID relativement sûr car il peut résister à deux défaillances de disques et continuer à se reconstruire, ce qui signifie que si un disque tombe en panne, vous pouvez toujours supporter une autre défaillance de disque avant ou pendant la reconstruction sans perdre tout votre pool ! Tout comme RAIDZ1, RAIDZ2 ne souffre pas du syndrome de "trou d’écriture" (Write-hole phenomenon) que RAID6 peut rencontrer si aucune solution spécifique n'a été mise en place . ZFS dispose également d'un niveau RAIDZ3, qui offre 3 blocs de parité au lieu de deux, cela permet de supporter 3 défaillances de disques dur et de bénéficier de la reconstruction automatique du pool.
RAID10 & RAID01, lequel est le meilleur ?
RAID10 combine le mirroring et le striping. Les disques sont d'abord mis en miroir, puis chaque paire miroir est "stripée" à travers l'ensemble pour créer un disque virtuel unique. Cela offre les avantages de redondance du RAID1 et de performance du RAID0. Le seul inconvénient du RAID10 est l’utilisation inefficace de sa capacité. Toutes les données sont stockées deux fois, de sorte que la capacité effective est réduite de moitié par rapport à un RAID0 (tout comme RAID1 !). Le RAID10 dans ZFS est simplement le striping des VDevs en miroir.
RAID01 est le même qu’un RAID10, mais en sens inverse mais en pire ! Il stripe d'abord les données à travers des pools de disques, puis effectue un miroir de ces pools. Les performances sont identiques à un RAID10, mais la probabilité de perdre votre pool est bien plus élevée. De plus, les performances lors de la reconstruction sont bien pires, augmentant ainsi le risque de défaillance de disque. Au fur et à mesure que vous ajoutez des disques à un RAID01, la probabilité de perdre votre pool avec deux disques défaillants n'est jamais inférieure à 50%. Avec un RAID10, plus vous ajoutez de disques, plus cette probabilité tend vers 0%.
RAID50 & RAID60 dans ZFS
Qu'est-ce que RAID50 ?
Le RAID50 est essentiellement plusieurs pools RAID5 séparés (avec un disque de parité dans chacun), avec un RAID0 ajouté au-dessus pour "striping" des données à travers ces pools. Vous pouvez supporter une défaillance de disque pour chaque pool RAID5. Cela offre une redondance bien plus grande qu'un simple RAID5, mais avec une moins bonne efficacité de disponiblité des données, car vous devez réserver un disque de parité pour chaque pool. Votre pool entier peut toujours échouer si deux disques de l'un des pools RAID5 tombent en panne. Le RAID50 est vu par certains comme un compromis en termes de performances et de taille entre RAID10 et RAID5. RAID50 diminue également votre capacité de stockage car il nécessite d'utiliser des blocs de parité supplémentaires pour chaque pool RAID5 que vous utilisez. Dans ZFS, cela se fait en créant plusieurs volumes RAIDZ1 et en les "stripant" les uns avec les autres.
Qu'est-ce que RAID60 ?
Comme pour le RAID50, RAID60 est constitué de plusieurs pools RAID6, "stripés" les uns sur les autres. Cela peut consommer beaucoup de capacité de stockage, car chaque pool RAID6 nécessite deux disques de parité. Il offre également une énorme redondance, car deux disques peuvent tomber en panne dans n'importe lequel des pools RAID6 et l'ensemble du pool peut toujours être reconstruit. Tant que trois disques d'un même pool ne tombent pas en panne, les données peuvent encore être reconstruites, offrant une grande protection contre les pannes de disques. Dans ZFS, RAID60 équivaut à plusieurs pools RAIDZ2 "stripés" entre eux. C’est une option très gourmande en termes d’espace, car vous échangez de l’espace de stockage contre une grande redondance. L'un des plus gros problèmes que certaines personnes rencontrent avec les niveaux RAID "striping et parité" (RAID5, RAID6, RAID50, et RAID60) est ce que l'on appelle le phénomène du "trou d’écriture". Si de l'énergie est perdue pendant une écriture, les données sont corrompues et ne peuvent pas être reconstruites, en raison d’incohérences entre les données et les informations de parité correspondantes. RAIDZ ne souffre pas de ce problème. Il a cependant des lectures plus lentes en raison de la somme de contrôle, limitée à la vitesse d'un seul disque. Il peut y avoir des ralentissements lors de la lecture de petits morceaux de données de manière aléatoire avec RAIDZ. Nous sommes expert en récupération de données sur RAID ZFS, n'hésitez pas à nous consulter si vous rencontrer un problème avec votre système de fichiers ZFS.
Syndrome du "trou d'écriture" ( Write-Hole phenomenon)
Le syndrome du "trou d'écriture" peut se produire si une coupure de courant intervient pendant une écriture. Il peut également se produire si un ou plusieurs disques constituant le RAID, ont une défaillance pendant le fonctionement du RAID et plus particulièrement en phase d'écriture. Ce phénomène affecte tous les types de configuration RAID et plus particulièrement sur les RAID5, RAID6 et RAID1. Suite au syndrome, il est impossible de déterminer quels blocs de données ou blocs de parité ont été écrits sur les disques et lesquels ne l'ont pas été. Dans cette situation, les données de parité ne correspondent pas aux autres données dans le stripe. De plus, il est impossible de savoir avec certitude quelles données sont incorrectes - la parité ou l'un des blocs de données.
Trou d'écriture dans RAID5
Le "trou d'écriture" est largement reconnu pour affecter un RAID5, et la plupart des discussions sur l'effet du "trou d'écriture" se réfèrent au RAID5. Il est important de savoir que d'autres types de configurations sont également affectées.
Si les données utilisateur ne sont pas écrites complètement, généralement un système de fichiers corrige les erreurs lors du redémarrage. Si un système de fichiers ne supporte pas la journalisation, les erreurs seront corrigées lors de la prochaine vérification de cohérence (chkdsk ou fsck).
Si la parité (dans RAID5) ou la copie miroir (dans RAID1) n’est pas écrite correctement, cela ne sera pas remarqué avant qu'un des disques de la configuaration échoue. En cas de défaillance d'un disque, il faut remplacer le disque défectueux et démarrer la reconstruction du RAID. Dans ce cas, l'un des blocs serait récupéré de manière incorrecte. Si une récupération RAID est nécessaire en raison d’une défaillance du contrôleur, un décalage de parité n'a pas d'importance.
Un décalage de parité ou de données miroir peut être récupéré sans intervention de l'utilisateur, si à un moment ultérieur un stripe complet est écrit dans un RAID5, ou si le même bloc de données est écrit à nouveau dans un RAID1. Dans ce cas, l'ancienne parité incorrecte n'est pas utilisée, mais de nouvelles données de parité correctes seront calculées puis écrites. De plus, de nouvelles données de parité seront écrites si vous forcez la resynchronisation de la config (cette option est disponible pour de nombreux contrôleurs RAID et NAS).
En général, une coupure de courant pendant l'écriture est rare, ce qui n'est pas le cas de la perte de performance d'un disque qui peut généré un trou d'écriture qui génère des problèmes d'inconsitence du RAID.
Trou d'écriture dans RAID1
Comme pour le RAID5, l’effet du trou d’écriture peut se produire dans un RAID1. Même si un disque est désigné comme principal, et que les opérations d'écriture sont arrangées de manière à ce que les données soient toujours écrites sur ce disque en premier, garantissant qu'il contient la copie la plus récente des données, deux difficultés subsistent :
Un disque dur peut mettre en cache les données par lui-même. Ce cache peut violer l'agencement effectué par le contrôleur.
Si le disque désigné comme principal échoue, des trous d'écriture peuvent déjà exister sur le second disque et il serait impossible de les identifier sans les données du premier disque.
Trou d'écriture dans RAID6
Théoriquement, un phénomène de trou d'écriture peut aussi se produire dans un RAID6. Le trou d'écriture dans un RAID5/RAID1 se produit lorsqu’un des disques membres ne correspond pas aux autres et, par la nature du RAID5/RAID1 à redondance simple, il est impossible de savoir lequel des disques est défectueux. Le trou d'écriture dans un RAID6 se produit lorsque deux disques ne correspondent pas aux autres simultanément. Une telle situation peut se produire, par exemple, si l'alimentation est coupée en plein milieu de l'écriture d'un stripe complet ou en cas de disque défectueux.
Trou d'écriture dans des configurations RAID complexes
Les RAID complexes héritent de la vulnérabilité du trou d’écriture des types RAID sur lesquels ils sont basés.
Le RAID 10 hérite du trou d'écriture d'un RAID 1. Si une des copies miroir a été écrite mais que la seconde ne l’a pas été, il est impossible de savoir laquelle est correcte. Dans un RAID 50, qui peut être représenté comme un ensemble de configurations RAID5, le trou d'écriture peut se produire dans chacun de ces configurations. De même, le RAID 10 et le RAID 60 sont vulnérables, bien que la probabilité soit moindre.
Comment éviter le "trou d'écriture" ?
Afin d'éviter complètement le trou d'écriture, il est nécessaire de garantir la stabilité des écritures, ce qui demande une absence de coupure de courant et un suivi constant de l'état de fonctionnement des disques.
Une autre option pour éviter un trou d'écriture est d'utiliser ZFS, qui est un hybride d'un système de fichiers et d'un RAID. ZFS utilise "copy-on-write" pour garantir la constance des écritures. Cependant, cette technologie nécessite un type particulier de RAID (RAID-Z) qui ne peut pas être réduit à une combinaison des types RAID courants (RAID 0, RAID 1 ou RAID 5).
Comment réduire l'effet négatif d'un "trou d'écriture" ?
En pratique , le risque de perdre des données à cause d'un trou d'écriture peut être réduit à un niveau acceptable, même pour les configs classiques, tels que RAID 1 et RAID 5.
Alimenter avec une source ininterrompue d’énergie. Vous pouvez utiliser un onduleur pour l'ensemble du RAID. La seconde option consiste à utiliser une unité de sauvegarde par batterie (BBU) connectée directement à un contrôleur RAID. Cette batterie permet de sauvegarder le contenu du cache d'écriture d'un contrôleur en cas de coupure de courant. Toutes les opérations d'écriture, qui sont dans le cache et non terminées en raison d'une coupure de courant, seront effectuées lorsque l'alimentation sera rétablie. La BBU protège uniquement le cache du contrôleur, pas le cache d'écriture des disques durs.
Synchroniser votre configuration régulièrement. La synchronisation est un processus où les valeurs de parité (pour un RAID5) ou d'autres données fournissant de la redondance (pour RAID6, RAID7, ou RAID DP) sont recalculées. Dans un RAID1, les données d’un disque sont copiées sur l’autre lors de la synchronisation. La synchronisation efface tous les trous d'écriture accumulés pendant l'opération. Une fois la synchronisation terminée, les données redondantes correspondront exactement aux données utilisateur. De plus, la synchronisation permet de détecter les secteurs défectueux dans les zones rarement utilisées du pool, car pendant la synchronisation, tous les secteurs du pool sont lus et écrits. Les contrôleurs matériels modernes permettent généralement de synchroniser un pool selon un agenda. Les RAIDs créés sous Windows ne peuvent pas être synchronisés par agenda.
Si des SSD sont utilisés dans le RAID, vous pouvez généralement désactiver le cache d'écriture et obtenir encore des performances suffisantes pour votre tâche spécifique. Désactiver le cache d'écriture n'évite pas totalement le trou d'écriture, mais réduit la probabilité de perdre des données et la quantité de données pouvant être perdues en raison d'une coupure de courant ou d'une défaillance matérielle.
Comment récupérer des données depuis un RAID Btrfs ?
Qu'est-ce que Btrfs ?
Btrfs (abréviation de "B-tree file system") est un système de fichiers Linux basé sur des structures B-tree. C'est un système concurrent de ZFS. De nos jours, Btrfs est largement utilisé dans les appareils NETGEAR modernes. Le système de fichiers Btrfs présente plusieurs caractéristiques distinctives telles que la copie sur écriture, les instantanés et la compression intégrée.
Symptômes de dysfonctionnement du système de fichiers Btrfs
En cas de défaillance du système de fichiers Btrfs dans les appareils NAS, il est généralement impossible d'accéder au volume ou aux dossiers partagés, vous pouvez également voir le volume et les dossiers partagés mais ne pas accéder aux données. D'autres possibilités incluent un NAS qui refuse de démarrer, l'incapacité de lire certains fichiers depuis le NAS ou des échecs lors de la copie d'un fichier sur le NAS alors qu'il reste encore de l'espace libre.
Récupération de données sur sytème de fichiers ZFS. Plus de 70 To de récupéré pour un de nos clients. Nous intervenons sur les problématiques liées à ce système de fichier que notre configuaration soit du RAIDZ, RAIDZ2, ou RAIDZ3.
Récupération Btrfs
Bien que le système de fichiers Btrfs dispose de diverses fonctionnalités de contrôle qui aident à éviter la perte de données, Btrfs, comme tout autre système de fichiers, peut échouer. Le système de fichier Btrfs est toujours en cours de développement et n’est donc pas abouti. La prise en charge de RAID5 et RAID6 par Btrfs est assez récente.
Dans Btrfs, les configurations RAID5 et RAID6 sont implémentées au niveau des chunks plutôt qu'au niveau des périphériques. C'est pourquoi il existe un nombre impressionnant d'ensembles RAID indépendants sur un ensemble de disques Btrfs. En raison de cette spécificité, les approches de récupération RAID classiques ne fonctionnent pas car elles sont conçues pour traiter un seul RAID créé sur plusieurs disques. De plus, s'il n'y a pas de métadonnées concernant la localisation des chunks – si elles sont détruites ou écrasées – il est impossible de récupérer les fichiers et dossiers dans le système de fichiers Btrfs. Vous pourrez récupérer certains noms de fichiers et dossiers ainsi que leurs attributs, mais sans contenu. Quant à la récupération RAW (dite "carving"), même dans le cas chanceux d'un fichier non fragmenté, elle ne pourra pas être réussie en raison de la taille des bandes trop petites – ce que vous pourrez récupérer ne sera que quelques dizaines de kilo-octets.
Quoi qu'il en soit, il n'existe pas beaucoup d'outils de récupération pour Btrfs, en particulier pour les volumes RAID5 et RAID6. ReclaiMe est le premier logiciel capable de récupérer des données sur des volumes Btrfs, y compris RAID5 et RAID6, et même des configurations avec un disque manquant. Donc, si vous vous trouvez dans une situation où vous ne pouvez pas accéder aux données stockées sur un volume Btrfs et que vous avez besoin d'un lecteur Btrfs fiable, essayez ReclaiMe. Sachez qu’avant de lancer un logiciel de récupération Btrfs, vous devez connecter tous les disques d'un volume Btrfs défaillant séparément à un PC, de préférence via les ports SATA de la carte mère.
Btrfs, en tant que système de fichiers de nouvelle génération, intègre de nombreuses fonctionnalités avancées qui assurent une grande résilience, une réparation instantanée des erreurs logiques et une administration simplifiée. Btrfs comme sont prédecessuer Mdadm est sensible au syndrome du trou d'écriture.
En pratique, ce système de fichiers peut remplacer à lui seul la gestion traditionnelle des volumes sous Linux et l'outil RAID logiciel mdadm : on peut créer un Btrfs sur plusieurs périphériques tout en lui donnant les capacités de tolérance aux pannes des niveaux RAID 1, RAID 5, RAID 6 ou RAID 10.
Cependant, il est important de comprendre que, bien que Btrfs améliore considérablement la sécurité des données stockées, il ne peut pas totalement prévenir leur perte.
En ce qui concerne la récupération des données perdus à partir d'un RAID Btrfs, la spécificité de la manière dont les données sont configurées rend le processus de restauration beaucoup plus complexe. Un RAID standard est généralement traité en deux étapes distinctes. La reconstruction de la configuration RAID et des éléments du système de fichiers, tandis que l’espace disque est divisé par le système de fichiers en un ensemble de blocs de données numérotés de manière consécutive, de sorte qu'il suffit de connaître la localisation du premier bloc et la taille du bloc pour déterminer la localisation des autres. En revanche, Btrfs organise les blocs de données sur les disques RAID de manière arbitraire et suit la correspondance entre les blocs et les adresses physiques des disques auxquels ils sont assignés à l'aide d'une table des Chunks spécifique. Cela rend le système beaucoup plus flexible, mais empêche de déterminer l'emplacement des blocs de données en cas de dommage ou de perte des deux copies de la table des Chunks. Cependant, si au moins une copie est intacte, il est possible d’interpréter la table des Chunks et de reconstruire une configuration RAID Btrfs et cela quelque soit sa complexité.