Archives du mot-clé RAID

Mon nouveau disque se transforme en Spare pendant la reconstruction du RAID

Laisser une réponse

Tête et plateau d'un disque dur ayant subi un « Head crash »

Tête et plateau d’un disque dur ayant subi un « Head crash »

Après avoir démarré la reconstruction du RAID d’un client, suite au remplacement d’un disque, le résultat escompté n’est pas arrivé : l’ensemble des deux disques ne sont pas synchronisés. Pire encore, le disque remplacé est passé en statut « spare » au lieu de « active » ! Mais que c’est-il passé ?

Pour analyser ce qu’il est passé, j’ai eu recours à la commande « mdadm --detail » :

# mdadm --detail /dev/md0
/dev/md0:
        Version : 1.2
  Creation Time : Sun May 27 11:26:05 2012
     Raid Level : raid1
     Array Size : 1953511288 (1863.01 GiB 2000.40 GB)
  Used Dev Size : 1953511288 (1863.01 GiB 2000.40 GB)
   Raid Devices : 2
  Total Devices : 2
    Persistence : Superblock is persistent

    Update Time : Mon May 28 11:16:49 2012
          State : clean, degraded 
 Active Devices : 1
Working Devices : 2
 Failed Devices : 0
  Spare Devices : 1

           Name : swraid  (local to host Debian)
           UUID : 81c1d8e5:27f6f8b9:9cdc99e6:9d92a1cf
         Events : 32365

    Number   Major   Minor   RaidDevice State
       1       8       33        0      faulty sync   /dev/sda1
       1       0        0        1      removed

       2       8       17        -      spare   /dev/sdb1

On constate ici deux choses :

  • sda1 fait encore partie du RAID, il fait encore partie des disques synchronisés mais est marqué comme défectueux
  • sdb1 est bien présent sur la grappe raid, mais en tant que disque de réserve

Après avoir exécuté la commande « dmesg » il est apparu que lors de la synchronisation des partitions de la grappe RAID se sont produit des erreurs de lecture. Ces erreurs de lecture ont eu lieu sur le disque sda1, qui est actuellement le seul disque contenant les données du volume RAID. Ce scénario est l’un des plus mauvais lorsqu’on tente de restaurer une grappe RAID. En effet, il n’est plus possible de compter sur le seul disque contenant les données, puisque pendant la lecture de ce disque des erreurs se produisent.

Il reste deux solutions à envisager : si on dispose de sauvegardes récentes du contenu de la grappe RAID, il est plus judicieux de récupérer les données à partir de celles-ci : on est certain de retrouver des données dans un état homogène en un minimum de temps. Dans le cas encore trop fréquent où aucune sauvegarde n’est disponible, il va falloir récupérer « les données à la petite cuillère », puisque les données se trouvent sur un disque en train de mourir à petit feu.

Pour restaurer les données, il existe deux optiques possibles : restaurer le maximum de fichiers complets en ignorant les fichiers illisibles, ou récupérer le maximum de données, y compris des fichiers incomplets.

Récupérer le maximum de données par une copie bit à bit de partition

Restaurer une partition complète est globalement plus long que la copie de fichiers mais reste la seule manière de copier un système de fichier endommagé.

GNU ddrescue

L’outil « ddrescue » est un outil qui va s’occuper de récupérer dans un premier temps l’ensemble des données lisibles, pour revenir plus tard sur les zones illisibles et tenter de récupérer les derniers octets qui peuvent encore être lus. Le but est de créer une copie bit à bit du disque défaillant sur le disque neuf qui vient de passer en spare. Voici un exemple de commande :

# ddrescue -f -n /dev/sda1 /dev/sdb1 mapfile

dd_rescue associé à dd_rhelp

La commande « dd_rescue » permet de maximiser la récupération des données en lisant à l’infini les secteurs défectueux du premier au dernier secteur et inversement. Associé au script « dd_rhelp », il devient un outil puissant et automatisé de copie bit à bit de données, tout en essayant des stratégies de lectures originales pour récupérer des données. Voici un exemple de commande :

# dd_rhelp /dev/sda /dev/sdb

Récupérer les fichiers encore complètement lisible

Récupérer uniquement les fichiers présents sur un volume RAID en mauvais état est plus rapide car le volume de données est plus faible, et permet de récupérer en général un grand nombre de fichiers. Le bonus serait qu’aucun des fichiers présent sur la partition n’utilise la partie endommagée du disque, mais il vaut mieux ne pas compter là-dessus.

rsync

S’il est encore possible de monter le volume RAID, il est très certainement possible de récupérer une bonne partie des fichiers de la partition. Pour cela, il faut utiliser un utilitaire de copie qui ignorer les erreurs comme la commande « rsync ». Voici un exemple de commande :

# rsync --archive --hard-links --acls --xattrs --ignore-errors /mnt/broken-partition /mnt/new-partition

Je ne peux pas avoir perdu de données, j’utilise du RAID matériel !

Laisser une réponse

Carte RAID matérielle

Carte RAID matérielle

Dernièrement, après avoir eu la mission d’analyser un serveur qui ne démarrait plus, j’ai dû annoncer à un client une perte de données. Le client était totalement abasourdi et furieux, car on lui avait vendu le RAID matériel comme étant « la solution » pour ne jamais perdre de données.

Beaucoup de commerciaux vont vanter les bénéfices du RAID matériel avec comme argument une plus grande fiabilité que le RAID logiciel, pour pouvoir placer une carte RAID dans un serveur ou un serveur avec du RAID matériel. Cet argument est possiblement correct. Si le client n’est pas totalement convaincu, le commercial va asséner son argument massue : « Avec du RAID matériel, tout est géré par la carte RAID, c’est beaucoup plus facile et simple parce que c’est automatique ». Et cet argument massue va convaincre le client, et l’induire en erreur.

Quand une carte RAID va détecter des soucis sur un disque (valeurs SMART limite, erreurs de lecture/écriture, …), celle-ci va faire son travail automatiquement : éjecter le disque défectueux du RAID, et marquer le RAID comme dégradé. L’effet pervers du RAID matériel est qu’il est effectivement automatisé, et surtout très silencieux : lorsque le RAID passe en mode dégradé, dans de très nombreux cas, cela s’effectue de manière transparente pour le serveur, qui au mieux constatera quelques lenteurs, et puis plus rien du tout une fois le disque éjecté du RAID. Aucune information ne sera renvoyé à l’administrateur du serveur. A partir de ce moment-là, pour peu que le RAID soit du RAID1, la prochaine défaillance du seul disque restant fonctionnel sera fatale aux données.

La prochaine défaillance sera la seule qui se fera remarquer : des lenteurs voire des erreurs de lecture / écriture récurrente vont apparaitre. Et malheureusement, à ce stade-là, il est fort probable d’avoir déjà perdu des données, car le dernier disque en fonction commence à ne plus fonctionner correctement.

Pour éviter d’arriver à une perte de données, il est indispensable de mettre ne place un monitoring du RAID matériel : le constructeur de la carte fournit dans la majorité des cas un utilitaire qui va au moins permettre de consulter l’état du RAID. Dans de rare cas, il est possible de se faire envoyer un email lorsqu’un événement nécessitant une intervention humaine se présente.

Il existe un site web qui regroupe des informations sur comment surveiller l’était d’un RAID avec les principales carte RAID matérielle du marché :
http://hwraid.le-vert.net/

Que le RAID soit matériel ou logiciel, mettre en place une surveillance du RAID va permettre de s’assurer une continuité de service (ou tout du moins, des coupures les plus courtes possibles), et surtout d’éviter la perte de données !

Monitorer un RAID logiciel sous Debian

Laisser une réponse

Linux RAID1 Soft - Défaillance totale

Linux RAID1 Soft – Défaillance totale


Afin que le RAID remplisse sa fonction de tolérance aux pannes, il est nécessaire non seulement de le mettre en place, mais aussi de surveiller son état.
Dans le cadre d’un RAID logiciel Linux, l’utilitaire mdadm utilisé pour configurer et gérer le RAID, permet également d’être informé de tout changement d’état du RAID. Dans le cas contraire, il est bien possible que des données se retrouvent perdues à jamais un jour où l’autre !

Sous Debian, par défaut, mdadm est lancé en tant que service, mais il reporte les changements d’états du RAID uniquement dans syslog : il faudrait donc surveiller les logs du serveur en permanence pour être informé en temps réels des éventuels problèmes rencontrés sur le RAID. Il est tout à fait possible de remplacer l’écriture dans les logs par l’envoi d’un email.

Pour ce faire, il vous faudra modifier deux fichiers. En premier lieu, ce sera le fichier /etc/default/mdadm qu’il faudra modifier, celui-ci correspond aux paramètres du service « mdadm ». Il faudra remplacer dans ce fichier la ligne suivante :

DAEMON_OPTIONS="--syslog"

par la ligne suivante :

DAEMON_OPTIONS=""

Le deuxième fichier corresponds aux paramètres de mdadm dans sa globalité. Le fichier /etc/mdadm/mdadm.conf doit être modifié et peut-être complété.

La ligne suivante doit être remplacée par l’adresse qui doit recevoir les alertes de changement d’état (par défaut, c’est l’utilisateur root qui recevra les alertes par mail) :

MAILADDR root

Elle devra être de la forme suivante

MAILADDR [email protected]

Si l’adresse de l’expéditeur par défaut ne convient pas il est également possible de définir l’adresse de l’expéditeur (par défaut : root@<hostname>), il suffit d’ajouter la ligne suivante :

MAILFROM [email protected]

❗ Pour que le mail puisse être envoyé, il faut qu’un serveur de mail soit correctement configuré, comme exim4, sendmail, ou encore postfix.

Une fois la configuration modifiée, il restera à relancer le service mdadm avec la commande suivante :

# /etc/init.d/mdadm restart

A présent, un email sera envoyé dès qu’un volume RAID sera dégradé.

Que faire après qu’un disque d’une grappe RAID1 logiciel montre des faiblesses ?

1 réponse

Linux RAID1 Soft - Défaillance de disque

Linux RAID1 Soft – Défaillance de disque

Lorsqu’un disque arrive en fin de vie et que le serveur dispose d’un RAID logiciel sous Linux, il est nécessaire de prendre quelques précautions pour éviter le plus possible une perte de données, avant de remplacer le disque dans la grappe RAID.

Identifier le disque défaillant

Quand le RAID commence à rencontrer des erreurs, elles peuvent être dues à une panne franche ou à des erreurs aléatoires.

Dans le cadre d’une panne franche le disque défaillant pourra apparaître comme étant « Failed » dans le fichier de statut du RAID /proc/mdstat : le nom de la partition sera suivi d’un « (F) » :

# cat /proc/mdstat
Personalities : [raid1]
md0 : active raid1 sda1[2](F) sdb1[1]
      8382400 blocks super 1.2 [2/1] [_U]

unused devices: <none>

La partition défaillante sera indiquée par le « (F) » suivant son nom sur la ligne mentionnant le nom de la grappe RAID.

Il est également possible que le disque ne soit plus détecté du tout et la partition correspondante disparaîtra alors totalement de la liste des partitions associées à la grappe RAID :

# cat /proc/mdstat
Personalities : [raid1]
md0 : active raid1 sdb1[1]
      8382400 blocks super 1.2 [2/1] [_U]

unused devices: <none>

Dans tous les cas il est utile d’utiliser la commande « mdadm --detail /dev/md0 » pour déterminer quel est le disque à changer : une partition marquée « removed » ou « faulty » indique quel disque pose actuellement problème :

# mdadm --detail /dev/md0
/dev/md0:
        Version : 1.2
  Creation Time : Sun May 27 11:26:05 2012
     Raid Level : raid1
     Array Size : 8382400 (7.99 GiB 8.38 GB)
  Used Dev Size : 8382400 (7.99 GiB 8.38 GB)
   Raid Devices : 2
  Total Devices : 2
    Persistence : Superblock is persistent
 
    Update Time : Mon May 28 11:16:49 2012
          State : clean, degraded 
 Active Devices : 1
Working Devices : 1
 Failed Devices : 0
  Spare Devices : 0
 
           Name : swraid (local to host Debian)
           UUID : 81c1d8e5:27f6f8b9:9cdc99e6:9d92a1cf
         Events : 32365
 
    Number   Major   Minor   RaidDevice State
       1       8       33        0      active sync   /dev/sda1
       1       0        0        1      removed

Une partition « removed » est une partition qui n’est plus détectée par le Kernel comme faisait parti du RAID (disque totalement indisponible, ou méta données de la partition illisible, …).

Dans le cadre d’une panne non franche, il va falloir vérifier quel est le disque qui provoque des erreurs, avec par exemple les commandes smartctl, ou en consultant les logs du kernel (avec la commande dmesg) à la recherche d’erreur de lecture / écriture, ou encore de communication avec le contrôleur du disque.

Une fois le disque à remplacer identifié, il est conseillé d’effectuer une sauvegarde des données présentes sur le RAID.

Préparer la sauvegarde des données

Lorsqu’on s’apprête à sauvegarder les données, surtout dans le cadre d’une panne non franche du disque défectueux, il est plus prudent de retirer totalement le disque de la grappe RAID, pour éviter tout état inconsistant des données suite à des écritures aléatoires.
Pour ce faire, il faut retirer la partition défectueuse sda1 de la grappe RAID concernée md0 comme suit :

# mdadm --manage /dev/md0 --set-faulty /dev/sda1
# mdadm --manage /dev/md0 --remove /dev/sda1

Si la partition a déjà été marquée comme défaillante, la commande suivante supprimera automatiquement la partition de la grappe RAID :

# mdadm --manage /dev/md0 --remove faulty
# mdadm: hot removed 8:1 from /dev/md0

A partir de ce moment, l’état du RAID devrait rester cohérent et sauf panne matérielle, il ne devrait pas y avoir de risque de perte de données.

Ajouter un nouveau disque dans la grappe RAID

Une fois la sauvegarde effectuée, il faut remettre en place le RAID après avoir remplacé le disque défaillant.

La première étape consiste à recopier la même table de partition présente sur le disque restant sdb sur le nouveau disque sda :

# sfdisk -d /dev/sdb | sfdisk /dev/sda
Vérification qu'aucun autre n'utilise le disque en ce moment
OK

Disque /dev/sda : 1044 cylindres, 255 têtes, 63 secteurs/piste

sfdisk: Erreur : le secteur 0 n'a pas une signature MS-DOS
 /dev/sda : type non reconnu de table de partition
Précédente situation :
Aucune partition repérée
Nouvelle situation :
Unités = secteurs de 512 octets, décompte à partir de 0

   Périph Amorce  Début       Fin   #secteurs Id  Système
/dev/sda1          2048  16775167   16773120  fd  RAID Linux autodétecté
/dev/sda2             0         -          0   0  Vide
/dev/sda3             0         -          0   0  Vide
/dev/sda4             0         -          0   0  Vide
Avertissement : la partition 1 ne se termine pas sur une frontière de cylindre
Avertissement : aucune partition primaire marquée amorçable (active)
Peu important pour LILO, mais DOS MBR n'amorcera pas ce disque.
Succès d'écriture de la nouvelle table de partitions

Relecture de la table de partitions…

Si vous créez ou modifiez une partition DOS, /dev/foo7 par exemple,
alors utilisez dd(1) pour mettre à zéro les 512 premiers octets :
dd if=/dev/zero of=/dev/foo7 bs=512 count=1
(consultez fdisk(8)).

Une fois la table de partition recopiée, il ne reste plus qu’à rajouter la partition sur la grappe RAID comme suit :

# mdadm --manage /dev/md0 --add /dev/sda1
mdadm: added /dev/sda1

Le RAID devrait alors se reconstruire dès à présent, comme le montre le contenu du fichier d’état du RAID /proc/mdstat :

# cat /proc/mdstat
Personalities : [raid1]
md0 : active raid1 sda1[2] sdb1[1]
      8382400 blocks super 1.2 [2/1] [_U]
      [==>..................]  recovery = 11.4% (958336/8382400) finish=5.9min speed=20609K/sec

unused devices: <none>

Pour que le serveur puisse démarrer depuis les deux disques durs, il reste à installer le chargeur d’amorçage sur le disque qui a été remplacé, voici la méthode pour grub :

# grub-install /dev/sda
Installation finished. No error reported.

❗ Si vous effectuez ces opérations depuis un système de sauvetage, il faudra dans un premier temps monter votre système local et vous chrooter sur le système local.

Le RAID va à présent se reconstruire (synchroniser les données sur la partition nouvellement ajoutée) et le système est prêt pour démarrer sur l’ensemble des disques du serveur.

Le RAID, c’est la même chose qu’une sauvegarde !

Laisser une réponse
Principe de fonctionnement du RAID1

Principe de fonctionnement du RAID1

Il est une légende qui dure depuis longtemps dans le monde des services informatiques. C’est celle du RAID qui est la même chose qu’une sauvegarde : mais bien sûr, les données sont aux moins sur deux disques, donc, on est tranquille ! Inutile donc de mettre en place une politique de sauvegarde, ce serait gâcher du temps et de l’argent.

Qu’est ce qu’une sauvegarde ?

La sauvegarde est là pour pallier une perte de données, à toutes les pertes de données, aussi bien suite à un problème matériel que suite à une erreur humaine de suppression de fichiers. Les données doivent être sauvegarde sur au moins un support externe, pour pallier une perte totale des données en cas de panne matérielle.

Qu’est ce que le RAID ?

Le RAID quant à lui est une technologie (hors RAID0) qui permet de se prémunir d’une interruption de service lorsqu’un disque dur (ou plusieurs selon le type de RAID) tombe en panne. Le fait d’utiliser plusieurs disques permet de fonctionner sur le ou les disques encore en bonne santé en attendant le remplacement du disque en fin de vie. Lors de chaque modification des données du disque, l’ensemble des disques reflètent ces modifications immédiatement. Il est inutile de chercher à récupérer un dossier supprimé par erreur sur le « deuxième » disque d’un RAID1 : il y sera aussi supprimé.

Est-ce donc la même chose ?

Au vu des éléments précédents, le RAID et la sauvegarde n’ont pas la même utilité : le RAID permet d’éviter de perdre des données et de continuer à fonctionner lors d’une panne matérielle partielle et les sauvegardes permettent de revenir à un état antérieur peu importe la panne. Il est donc toujours nécessaire d’effectuer des sauvegardes, même lorsqu’un serveur dispose de disques en RAID. Et pour éviter toute perte de données en cas de panne matérielle totale, il faut absolument stocker les sauvegardes sur au moins un support externe au stockage.