Analyse
Comprendre ce que le RAID protège vraiment
Un RAID répartit les données sur plusieurs disques selon une configuration précise. Selon le niveau choisi, il peut améliorer la disponibilité, accélérer certaines lectures ou tolérer une panne disque. Cette redondance est utile, mais elle ne signifie pas que les données sont protégées dans tous les scénarios.
La redondance reproduit fidèlement les écritures que le système accepte, y compris une suppression, un chiffrement ou une corruption applicative. Elle n'offre ni historique ni retour dans le temps. Une baie parfaitement saine peut donc contenir plusieurs exemplaires cohérents du même état devenu inutilisable.
La redondance donne parfois du temps. Elle permet de remplacer un disque dans un cadre maîtrisé. Mais ce temps doit être utilisé pour vérifier les sauvegardes, documenter l'état et éviter les opérations automatiques quand plusieurs signaux sont déjà mauvais.
Le mot « dégradé » ne donne pas une tolérance universelle. En RAID 5, il peut ne rester aucune marge avant un second défaut ; en RAID 6, deux parités existent mais tous les membres seront fortement relus ; en RAID 10, le risque dépend du miroir touché. Les profils propriétaires ajoutent leurs propres bandes et métadonnées.
La tolérance annoncée ne couvre qu'un modèle de panne
| Configuration | Tolérance habituelle en fonctionnement | Limite structurante |
|---|---|---|
| RAID 1 | Perte d'un membre du miroir | Mauvaise écriture reproduite sur les copies |
| RAID 5 | Perte d'un disque | Aucune marge si un second membre échoue pendant le rebuild |
| RAID 6 | Perte de deux disques | Reconstruction longue et mêmes risques logiques |
| RAID 10 | Certaines pannes dans des miroirs distincts | Perte possible si les mauvais membres d'une paire échouent |
Ces indications ne valent que si les autres membres, la configuration et le contrôleur sont cohérents. Elles ne constituent pas une garantie de récupération et ne couvrent ni la suppression, ni le chiffrement, ni la corruption applicative.
La récupération de données sur système RAID dépend de l'état de chaque membre, de la géométrie et des écritures déjà effectuées. La présence d'un RAID ne garantit ni une copie indépendante ni la reconstruction complète des données.
Analyse
Identifier les scénarios qui dépassent la redondance
Un RAID peut perdre des données quand plusieurs disques deviennent instables, surtout pendant une reconstruction. La lecture intensive des disques restants peut révéler des secteurs faibles qui passaient inaperçus en fonctionnement normal. Le volume peut alors passer de dégradé à inaccessible.
La géométrie ne réside pas toujours uniquement sur les disques. Le contrôleur ou le NAS peut imposer un ordre, une taille de bande, une rotation de parité, un décalage, un cache et une version de métadonnées. Un déplacement vers un autre châssis peut alors importer, convertir ou réinitialiser l'ensemble au lieu de simplement le relire.
Les pertes logiques sont fréquentes : suppression de dossiers, formatage, volume recréé, droits modifiés, base corrompue ou machine virtuelle incohérente. Le RAID continue alors à faire son travail : il réplique l'état du volume, même si cet état est mauvais.
Dans un hyperviseur, retrouver la banque de données ne suffit pas : une VM dépend de son descripteur, de ses disques, de l'ordre des snapshots et parfois de journaux transactionnels. Une chaîne rompue peut laisser chaque gros fichier visible sans fournir un état démarrable. La validation doit atteindre le service hébergé.
Les sauvegardes connectées au même système peuvent être touchées aussi. Une tâche planifiée peut recopier une corruption, une suppression ou un chiffrement. Le RAID continue à stocker l'état demandé, même si cet état détruit la version utile. C'est pourquoi la sauvegarde doit être séparée, historisée et testée.
Les pannes communes contournent la redondance
Une surtension, une température excessive, une erreur de micrologiciel, un contrôleur défaillant ou un lot de disques vieillissant dans les mêmes conditions peut affecter plusieurs membres à la fois. Le RAID est conçu autour d'hypothèses de panne ; lorsque tous les membres partagent la même cause, la multiplication des disques ne crée pas une copie indépendante.
Un volume disponible n'est pas une sauvegarde. La preuve attendue est un état daté, restaurable sur une infrastructure séparée et validé avec les données métier prioritaires.
Analyse
Ne pas lancer une reconstruction sans contexte
La reconstruction est l'opération la plus mal comprise. Elle peut être normale après le remplacement d'un disque, mais elle devient risquée si l'état global n'est pas clair. Remplacer le mauvais disque, perdre l'ordre, ignorer un second disque faible ou relancer plusieurs reconstructions peut aggraver la perte.
Avant retrait, chaque baie est photographiée et reliée au numéro de série, au statut, à la capacité et à l'heure de l'alerte. On conserve aussi contrôleur, journaux et membres précédemment sortis. Cet historique permet de distinguer un disque ancien d'un remplacement récent lorsque plusieurs ensembles possibles semblent cohérents.
Il faut aussi tester les sauvegardes dans un espace séparé. Une sauvegarde trop ancienne ou corrompue ne doit pas être découverte après une reconstruction qui a modifié le volume source. Le test doit porter sur les fichiers réellement critiques.
Le feu vert avant rebuild repose sur des faits
Avant de reconstruire, l'administrateur doit pouvoir répondre à ces questions :
- Quel membre est sorti, à quelle heure et pour quelle erreur exacte ;
- Quels autres membres présentent des défauts de lecture ou d'interface ;
- Quel est l'ordre physique et quel remplacement a déjà eu lieu ;
- Une sauvegarde séparée des données prioritaires a-t-elle été restaurée ;
- L'opération écrira-t-elle sur les seuls exemplaires encore disponibles ?
Si une réponse manque et que les données comptent davantage que la remise en service immédiate, préserver les membres est la décision la plus réversible.
Les assistants d'administration optimisent généralement le retour à un volume redondant. Leur bouton « réparer » peut choisir un membre source, réécrire des métadonnées ou lancer un resync sans exposer toutes les hypothèses. Si l'unique sauvegarde n'est pas restaurable, l'objectif change : conserver les états divergents avant de restaurer la disponibilité.
Après une coupure électrique, la configuration, l'ordre des disques et leurs états divergents doivent être établis avant toute reprise. Tant que ces éléments ne sont pas compris, chaque écriture sur le RAID peut réduire les options.
Analyse
Diagnostiquer le volume par couches
Un diagnostic RAID sérieux regarde plusieurs couches : disques physiques, contrôleur ou NAS, métadonnées RAID, système de fichiers, volumes logiques, fichiers, bases et priorités métier. Un volume qui remonte ne prouve pas que les données sont intactes.
Une acquisition séparée de chaque membre crée une carte des secteurs absents et stabilise l'analyse. Les copies peuvent ensuite être assemblées avec plusieurs hypothèses d'ordre ou de parité sans modifier les superblocs originaux. Cette étape est particulièrement utile lorsqu'un rebuild précédent s'est interrompu et que les membres ne portent plus le même instant logique.
La restitution doit être validée. Une arborescence visible ne suffit pas si les fichiers sont partiels, les bases incohérentes ou les machines virtuelles inutilisables. Le contrôle doit être fait avec les utilisateurs capables de reconnaître les périodes, dossiers et applications attendus.
Une base est contrôlée avec ses fichiers de données, journaux et mécanismes de cohérence ; une VM avec sa configuration et sa chaîne de disques. Copier leur conteneur ne valide pas le contenu. Le verdict distingue donc blocs reconstruits, système de fichiers montable et application réellement exploitable.
Datastrophe aborde le RAID comme un ensemble de dépendances. L'objectif n'est pas de sauver une configuration pour elle-même, mais de restituer des données exploitables sur un support sain, avec les limites documentées.
Du secteur au service métier
Le contrôle avance du bas vers le haut : stabilité et copie des disques, cohérence de l'assemblage RAID, montage non destructif du système de fichiers, extraction des volumes logiques, puis validation des VM, bases et fichiers. Une parité cohérente n'assure pas qu'une base l'est ; une arborescence correcte n'assure pas que les blocs d'un fichier sont complets.
Analyse
Prévenir avec sauvegardes et documentation
La prévention repose sur une idée simple : le RAID et la sauvegarde n'ont pas le même rôle. Le RAID améliore la disponibilité du volume. La sauvegarde permet de revenir à un état séparé, daté, contrôlé et restaurable. Les deux doivent être pensés ensemble.
Une fiche d'une page suffit si elle est tenue à jour : topologie, emplacements et numéros de série, contrôleur, volumes hébergés, dernier remplacement, sauvegarde correspondante et procédure d'arrêt. Elle doit être exportée hors de la baie pour rester accessible lorsque l'interface ne démarre plus.
Les alertes doivent déclencher une action réelle. Un disque dégradé, une reconstruction longue, une sauvegarde en échec ou une erreur de base ne doit pas rester dans un journal non lu. La redondance n'est utile que si elle laisse le temps d'agir.
La prévention doit aussi tester le scénario de restauration, pas seulement le remplacement d'un disque. L'exercice utile consiste à remettre un échantillon de données sur un environnement indépendant, vérifier son usage et mesurer la période perdue. Cela révèle les exclusions et les dépendances bien avant une panne réelle.
Le plan nomme séparément la personne qui confirme le membre fautif, celle qui teste la restauration et celle qui autorise l'arrêt métier. Il précise aussi où trouver un disque compatible et qui photographie la baie. Cette séparation réduit le risque qu'une même urgence déclenche simultanément remplacement, rebuild et restauration destructive.
Un RAID peut donc perdre des données, mais cette limite peut être maîtrisée. Préserver l'ordre, tester les sauvegardes, éviter les reconstructions aveugles et documenter les dépendances donnent de meilleures chances qu'une confiance abstraite dans la redondance.
Sources techniques primaires et limites
La documentation du noyau Linux sur les ensembles MD décrit superblocs, rôles, assemblage et états d’un RAID logiciel. Elle ne permet pas d’appliquer automatiquement une géométrie ou une génération à une baie propriétaire, et ne justifie aucune reconstruction sur les membres originaux.
Faire qualifier le dossier « RAID et perte de données : limites de la redondance »
Transmettez à Datastrophe tous les membres actifs, retirés et de secours avec leur ordre de slot, le contrôleur et son cache, les configurations, les cartes d’erreurs et les volumes prioritaires. Les codes, clés et éléments d’authentification autorisés sont communiqués par un canal distinct ; ils ne sont jamais inscrits sur le support ni dans le colis.
Datastrophe réalise directement le diagnostic, les contrôles d’intégrité et la récupération dans son laboratoire, avec sa propre équipe. Le diagnostic et le devis sont gratuits. Le transport privé aller et retour est systématiquement pris en charge ; le transporteur déplace uniquement le colis scellé, sans accéder aux données ni les traiter.
Avant tout paiement, le client reçoit le prix proposé et une liste contrôlée. Chaque élément y est classé, dans cet ordre, recoverable_verified, partial, detected_unverified ou unrecoverable. Seuls les éléments recoverable_verified, dont le contenu a été contrôlé et jugé exploitable, sont présentés comme récupérables. Le client paie seulement après avoir accepté la liste et le prix ; la préparation du résultat et la restitution interviennent ensuite.
Si aucune donnée exploitable n’est vérifiée, si la récupération échoue ou si le client refuse la liste ou le prix, aucun frais standard n’est dû. La seule exception concerne une pièce rare, coûteuse et non remboursable : elle ne peut être commandée qu’après une proposition séparée, explicite et chiffrée.