Raid 10 sur Nas Iomega ix4-200d Hs Help Me :]

Bonsoir à tous,

je sollicite votre aide à tous les expert en RAID sous Unix, je suis quelque peut débutent :slight_smile: dans administration, je précise que malgré mes recherches sur le forum, et le suivi des recommandations je n’est pas réussi à restaurer mon Raid, par avance merci de votre aide.

informations matériels:

Nas Ioemga ix4-200d
4 seagate 1to firmeware CC37
firmeware HS sur le NAS
Raid 10 (1+0)

j’ai donc extrait les disques et monté dans une tour et installé une distribution Ubuntu mais je peut aussi travailler sous Debian :smile:

voici toutes les étapes que j’ai suivi:

mdadm -Asf && vgchange -ay pour faire remonter les disques jusque ici tout va bien.

parted -l (pour identifier la remonter des disques)

[code]Modèle: ATA WDC WD2500AAKX-6 (scsi)
Disque /dev/sda : 250GB
Taille des secteurs (logiques/physiques): 512B/512B
Table de partitions : gpt
Disk Flags:

Numéro Début Fin Taille Système de fichiers Nom Fanions
1 1049kB 538MB 537MB fat32 EFI System Partition démarrage, esp
2 538MB 242GB 242GB ext4
3 242GB 250GB 7732MB linux-swap(v1)

Modèle: ATA ST31000520AS (scsi)
Disque /dev/sdb : 1000GB
Taille des secteurs (logiques/physiques): 512B/512B
Table de partitions : msdos
Disk Flags:

Numéro Début Fin Taille Type Système de fichiers Fanions
1 512B 2089MB 2089MB primary ext2
2 2089MB 1000GB 998GB primary

Modèle: ATA ST31000520AS (scsi)
Disque /dev/sdc : 1000GB
Taille des secteurs (logiques/physiques): 512B/512B
Table de partitions : msdos
Disk Flags:

Numéro Début Fin Taille Type Système de fichiers Fanions
1 512B 2089MB 2089MB primary ext2
2 2089MB 1000GB 998GB primary

Modèle: ATA ST31000520AS (scsi)
Disque /dev/sdd : 1000GB
Taille des secteurs (logiques/physiques): 512B/512B
Table de partitions : msdos
Disk Flags:

Numéro Début Fin Taille Type Système de fichiers Fanions
1 512B 2089MB 2089MB primary ext2
2 2089MB 1000GB 998GB primary

Modèle: ST310005 20AS (scsi)
Disque /dev/sde : 1000GB
Taille des secteurs (logiques/physiques): 512B/512B
Table de partitions : msdos
Disk Flags:

Numéro Début Fin Taille Type Système de fichiers Fanions
1 512B 2089MB 2089MB primary ext2
2 2089MB 1000GB 998GB primary

Modèle: Grappe RAID logiciel Linux (md)
Disque /dev/md127 : 2089MB
Taille des secteurs (logiques/physiques): 512B/512B
Table de partitions : loop
Disk Flags:

Numéro Début Fin Taille Système de fichiers Fanions
1 0,00B 2089MB 2089MB ext2[/code]

je configure le fichier conf de mdadm avec la commande suivante :

je vérifie l’entrée dans le fichier conf:

le résultat me semble correct

# This file was auto-generated on Wed, 02 Nov 2016 15:17:16 +0100
# by mkconf $Id$
ARRAY /dev/md/20_0 level=raid1 num-devices=4 metadata=0.90 UUID=ab0d7fdf:373ee9f2:5d8fd52f:304e1b90
   devices=/dev/sdb1
ARRAY /dev/md1 num-devices=4 metadata=1.0 name=batz:1 UUID=2a4f36d2:ea62aea0:fdbb7d38:bdd9943d
   devices=/dev/sdb2,/dev/sdc2,/dev/sdd2,/dev/sde2

et relance inittramfs : update-initramfs -u

tjrs pas d’accès au données juste à une partition du disque de 2.1go l’autre partition reste inaccessible (930 go) ou je suppose sont stocker une parties des données

je vérifie l’état du RAID avec la commande suivante :

[code]cat /proc/mdstat

Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10]
md127 : active raid1 sdd1[1]
2040128 blocks [4/1] [U_]

md1 : inactive sde20 sdb23 sdc22 sdd21
3898888768 blocks super 1.0[/code]

Si j’ai bien compris j’ai 3 HD hs sur 4 :/…

j’essaye d’avoir plus info sur chaque disques


mdadm -D /dev/md127

/dev/md127:
        Version : 0.90
  Creation Time : Thu May  6 22:34:46 2010
     Raid Level : raid1
     Array Size : 2040128 (1992.65 MiB 2089.09 MB)
  Used Dev Size : 2040128 (1992.65 MiB 2089.09 MB)
   Raid Devices : 4
  Total Devices : 1
Preferred Minor : 127
    Persistence : Superblock is persistent

    Update Time : Fri Nov  4 15:07:06 2016
          State : clean, degraded nano /etc/mdadm/mdadm.conf
 Active Devices : 1
Working Devices : 1
 Failed Devices : 0
  Spare Devices : 0

           UUID : ab0d7fdf:373ee9f2:5d8fd52f:304e1b90
         Events : 0.378

    Number   Major   Minor   RaidDevice State
       0       0        0        0      removed
       1       8       49        1      active sync   /dev/sdd1
       4       0        0        4      removed
       6       0        0        6      removed

Et

mdadm -D /dev/md1
/dev/md1:
        Version : 1.0
     Raid Level : raid0
  Total Devices : 3
    Persistence : Superblock is persistent

          State : inactive

           Name : batz:1
           UUID : 2a4f36d2:ea62aea0:fdbb7d38:bdd9943d
         Events : 8334

    Number   Major   Minor   RaidDevicnano /etc/mdadm/mdadm.confe

       -       8       18        -        /dev/sdb2
       -       8       34        -        /dev/sdc2
       -       8       50        -        /dev/sdd2

voila j’espère ne pas avoir fait de bêtise, pouvais vous m’aider à récupérer quelque choses : ) ?

Note : tes balises de code sont mal placées, des morceaux de code et de texte normal sont mélangés.

Une bêtise est d’avoir forcé l’assemblage au lieu d’examiner tous les composants.

Qu’entends-tu par “faire remonter les disques” ?

Habituellement on ne met pas --verbose dans cette commande car les noms de périphériques des membres peuvent varier et l’UUID de l’ensemble suffit normalement à les identifier.

Par contre il me semble anormal que la description de md1 ne contienne pas de niveau de RAID (level) dans la sortie du scan ni dans /proc/mdstat.
mdadm -D indique du RAID 0 et non 10.

A noter que le RAID 10 de Linux/mdadm est un niveau de RAID à part entière et pas un empilage de RAID 0 et 1. Dans le second cas on verrait deux ensembles RAID 1 distincts assemblés en un ensemble RAID 0 (ou vice versa). En tout cas pas un unique ensemble RAID 0.

Certains fabricants de NAS se croient plus malins que tout le monde et utilisent des variantes propriétaires de RAID. Si c’est le cas, bon courage pour récupérer quelque chose.

J’observe que le scan a détecté 4 partitions membres de md1 mais seulement 3 ont été utilisées pour l’assemblage.

La regénération de l’initramfs est inutile pour les ensemble RAID qui ne contiennent pas la racine, /usr ou le swap utilisé pour l’hibernation.

Il manque la commande pour examiner les composants RAID :
mdadm -E /dev/sd[b-e]*

Bonsoir PascalHambourg,

Merci d’avoir pris le temps d’analysé mon problème, désoler pour les balises j’ai procéder à la correction.

n’ayant pas de place dans mon desktop, pour loger tous les disques j’ai du passé par un doc externe en USB.

J’ai suivi cette commande ( recommandation constructeur dans procédure pour récupérer les données ), via un live cd Ubuntu pour procéder à la récupération des data en mode graphique.

Je prend note de ne plus rajouter l’option --verbose par contre il me sembler logique de relancer" l’initramfs" pour la prise en compte des changement du fichier Mdadm.conf

j’ ai bien remarqué la même chose, mais je ne comprend par pourquoi non plus. [quote=“PascalHambourg, post:2, topic:71595”]
la description de md1 ne contienne pas de niveau de RAID (level) dans la sortie du scan ni dans /proc/mdstat.
[/quote]

par contre j’ai également fait la commande pour lister les UUID

[code]blkid

/dev/sdb1: UUID=“ab0d7fdf-373e-e9f2-5d8f-d52f304e1b90” TYPE=“linux_raid_member” PARTUUID=“0000b823-01”
/dev/sdb2:
UUID="2a4f36d2-ea62-aea0-fdbb-7d38bdd9943d"
UUID_SUB=“29970cd9-8e29-9bfb-c181-a58ff767c8c9” LABEL="batz:1"
TYPE=“linux_raid_member” PARTUUID=“0000b823-02”
/dev/sdc1: UUID=“ab0d7fdf-373e-e9f2-5d8f-d52f304e1b90” TYPE=“linux_raid_member” PARTUUID=“0008a4de-01”
/dev/sdc2:
UUID="2a4f36d2-ea62-aea0-fdbb-7d38bdd9943d"
UUID_SUB=“67d1e6c9-4f1b-36fd-2ee3-ab6ee0c921a6” LABEL="batz:1"
TYPE=“linux_raid_member” PARTUUID=“0008a4de-02”
/dev/sdd1: UUID=“ab0d7fdf-373e-e9f2-5d8f-d52f304e1b90” TYPE=“linux_raid_member” PARTUUID=“0000b111-01”
/dev/sdd2:
UUID="2a4f36d2-ea62-aea0-fdbb-7d38bdd9943d"
UUID_SUB=“9cbe3c84-1505-c161-b189-030df69a6d0f” LABEL="batz:1"
TYPE=“linux_raid_member” PARTUUID=“0000b111-02”
/dev/md127: UUID=“962870ab-97f9-4043-b97b-cc9416c0e7b7” TYPE=“ext2”
/dev/sde1: UUID=“ab0d7fdf-373e-e9f2-5d8f-d52f304e1b90” TYPE=“linux_raid_member” PARTUUID=“0009eb78-01”
/dev/sde2:
UUID="2a4f36d2-ea62-aea0-fdbb-7d38bdd9943d"
UUID_SUB=“39745100-cad2-e8c4-8e98-2a96f6c18a25” LABEL="batz:1"
TYPE=“linux_raid_member” PARTUUID=“0009eb78-02” [/code]

Peut tu me confirmer que seulement 1 disque est encore exploitable sur 4 au vus de la sortie du scan ??
si c’est bien le cas cela veux dire que potentiellement j’ai perdu la moitier des données.

cat /proc/mdstat Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] md127 : active raid1 sdd1[1] 2040128 blocks [4/1] [_U__] md1 : inactive sde2[0](S) sdb2[3](S) sdc2[2](S) sdd2[1](S) 3898888768 blocks super 1.0

A vrais dire je ne suis pas certain que ce soit un RAID 10 (made in Ioemga) effectivement au vus des info je pencherais plutôt sur un Raid 1 +0 ou 0+1 tel est la question …

Pas soucis pour le commande [quote=“PascalHambourg, post:2, topic:71595”]
Il manque la commande pour examiner les composants RAID : mdadm -E /dev/sd[b-e]*
[/quote]

je la fait au travail lundi matin et te renvoi le résultat(et oui voici une belle problématique à résoudre en tant qu’admin junioir).

J’espère trouvé une solution pour éviter de payé une société de récupération données.

Bonne fin Week-end

Non, rien ne me laisse penser cela.

Pour quoi faire ? Le rôle de l’initramfs se limite à monter la racine et /usr et à lire le swap servant à l’hibernation.

Bonjour PascalHambourg,

Voici le résultat de la commande

mdadm -E /dev/sd[b-e] /dev/sdb: MBR Magic : aa55 Partition[0] : 4080509 sectors at 1 (type 83) Partition[1] : 1949444658 sectors at 4080510 (type 83) /dev/sdc: MBR Magic : aa55 Partition[0] : 4080509 sectors at 1 (type 83) Partition[1] : 1949444658 sectors at 4080510 (type 83) /dev/sdd: MBR Magic : aa55 Partition[0] : 4080509 sectors at 1 (type 83) Partition[1] : 1949444658 sectors at 4080510 (type 83) /dev/sde: MBR Magic : aa55 Partition[0] : 4080509 sectors at 1 (type 83) Partition[1] : 1949444658 sectors at 4080510 (type 83)

Petit complément information,

j’ai voulu suivra ta recommandation sans l’option (–verbose) en prennat soin de supprimer les lignes pour repartir sur un fichier conf propre.

voici le résultat:

INACTIVE-ARRAY /dev/md1 metadata=1.0 name=batz:1 UUID=2a4f36d2:ea62aea0:fdbb7d38:bdd9943d ARRAY /dev/md/20_0 metadata=0.90 UUID=ab0d7fdf:373ee9f2:5d8fd52f:304e1b90

Ce n’est pas la commande que j’ai demandée.

Oups j’ai oublier * dans la commande, sorry

mdadm -E /dev/sd[b-e]*
mdadm: Unknown keyword INACTIVE-ARRAY
/dev/sdb:
   MBR Magic : aa55
Partition[0] :      4080509 sectors at            1 (type 83)
Partition[1] :   1949444658 sectors at      4080510 (type 83)
/dev/sdb1:
          Magic : a92b4efc
        Version : 0.90.00
           UUID : ab0d7fdf:373ee9f2:5d8fd52f:304e1b90
  Creation Time : Thu May  6 22:34:46 2010
     Raid Level : raid1
  Used Dev Size : 2040128 (1992.65 MiB 2089.09 MB)
     Array Size : 2040128 (1992.65 MiB 2089.09 MB)
   Raid Devices : 4
  Total Devices : 1
Preferred Minor : 127

    Update Time : Mon Nov  7 08:00:49 2016
          State : clean
 Active Devices : 1
Working Devices : 1
 Failed Devices : 2
  Spare Devices : 0
       Checksum : bd781db3 - correct
         Events : 394


      Number   Major   Minor   RaidDevice State
this     1       8       17        1      active sync   /dev/sdb1

   0     0       0        0        0      removed
   1     1       8       17        1      active sync   /dev/sdb1
   2     2       0        0        2      faulty removed
   3     3       0        0        3      faulty removed
/dev/sdb2:
          Magic : a92b4efc
        Version : 1.0
    Feature Map : 0x0
     Array UUID : 2a4f36d2:ea62aea0:fdbb7d38:bdd9943d
           Name : batz:1
  Creation Time : Tue Nov 16 14:10:36 2010
     Raid Level : raid5
   Raid Devices : 4

 Avail Dev Size : 1949444384 (929.57 GiB 998.12 GB)
     Array Size : 2924166528 (2788.70 GiB 2994.35 GB)
  Used Dev Size : 1949444352 (929.57 GiB 998.12 GB)
   Super Offset : 1949444640 sectors
   Unused Space : before=0 sectors, after=288 sectors
          State : clean
    Device UUID : 9cbe3c84:1505c161:b189030d:f69a6d0f

    Update Time : Tue Oct 11 22:22:01 2016
       Checksum : 107d7d56 - correct
         Events : 8334

         Layout : left-symmetric
     Chunk Size : 64K

   Device Role : Active device 1
   Array State : .AA. ('A' == active, '.' == missing, 'R' == replacing)
/dev/sdc:
   MBR Magic : aa55
Partition[0] :      4080509 sectors at            1 (type 83)
Partition[1] :   1949444658 sectors at      4080510 (type 83)
/dev/sdc1:
          Magic : a92b4efc
        Version : 0.90.00
           UUID : ab0d7fdf:373ee9f2:5d8fd52f:304e1b90
  Creation Time : Thu May  6 22:34:46 2010
     Raid Level : raid1
  Used Dev Size : 2040128 (1992.65 MiB 2089.09 MB)
     Array Size : 2040128 (1992.65 MiB 2089.09 MB)
   Raid Devices : 4
  Total Devices : 2
Preferred Minor : 20

    Update Time : Thu Nov  3 13:30:16 2016
          State : clean
 Active Devices : 2
Working Devices : 2
 Failed Devices : 2
  Spare Devices : 0
       Checksum : bd73245b - correct
         Events : 348


      Number   Major   Minor   RaidDevice State
this     0       8       33        0      active sync   /dev/sdc1

   0     0       8       33        0      active sync   /dev/sdc1
   1     1       8       17        1      active sync   /dev/sdb1
   2     2       0        0        2      faulty removed
   3     3       0        0        3      faulty removed
/dev/sdc2:
          Magic : a92b4efc
        Version : 1.0
    Feature Map : 0x0
     Array UUID : 2a4f36d2:ea62aea0:fdbb7d38:bdd9943d
           Name : batz:1
  Creation Time : Tue Nov 16 14:10:36 2010
     Raid Level : raid5
   Raid Devices : 4

 Avail Dev Size : 1949444384 (929.57 GiB 998.12 GB)
     Array Size : 2924166528 (2788.70 GiB 2994.35 GB)
  Used Dev Size : 1949444352 (929.57 GiB 998.12 GB)
   Super Offset : 1949444640 sectors
   Unused Space : before=0 sectors, after=288 sectors
          State : clean
    Device UUID : 39745100:cad2e8c4:8e982a96:f6c18a25

    Update Time : Tue Oct 11 22:22:01 2016
       Checksum : 8efe3684 - correct
         Events : 8334

         Layout : left-symmetric
     Chunk Size : 64K

   Device Role : spare
   Array State : .AA. ('A' == active, '.' == missing, 'R' == replacing)
/dev/sdd:
   MBR Magic : aa55
Partition[0] :      4080509 sectors at            1 (type 83)
Partition[1] :   1949444658 sectors at      4080510 (type 83)
/dev/sdd1:
          Magic : a92b4efc
        Version : 0.90.00
           UUID : ab0d7fdf:373ee9f2:5d8fd52f:304e1b90
  Creation Time : Thu May  6 22:34:46 2010
     Raid Level : raid1
  Used Dev Size : 2040128 (1992.65 MiB 2089.09 MB)
     Array Size : 2040128 (1992.65 MiB 2089.09 MB)
   Raid Devices : 4
  Total Devices : 1
Preferred Minor : 127

    Update Time : Fri Nov  4 15:03:55 2016
          State : clean
 Active Devices : 1
Working Devices : 1
 Failed Devices : 2
  Spare Devices : 0
       Checksum : bd748bc3 - correct
         Events : 316


      Number   Major   Minor   RaidDevice State
this     2       8       17        2      active sync   /dev/sdb1

   0     0       0        0        0      removed
   1     1       0        0        1      faulty removed
   2     2       8       17        2      active sync   /dev/sdb1
   3     3       0        0        3      faulty removed
/dev/sdd2:
          Magic : a92b4efc
        Version : 1.0
    Feature Map : 0x0
     Array UUID : 2a4f36d2:ea62aea0:fdbb7d38:bdd9943d
           Name : batz:1
  Creation Time : Tue Nov 16 14:10:36 2010
     Raid Level : raid5
   Raid Devices : 4

 Avail Dev Size : 1949444384 (929.57 GiB 998.12 GB)
     Array Size : 2924166528 (2788.70 GiB 2994.35 GB)
  Used Dev Size : 1949444352 (929.57 GiB 998.12 GB)
   Super Offset : 1949444640 sectors
   Unused Space : before=0 sectors, after=288 sectors
          State : clean
    Device UUID : 67d1e6c9:4f1b36fd:2ee3ab6e:e0c921a6

    Update Time : Tue Oct 11 22:22:01 2016
       Checksum : e9f92ec4 - correct
         Events : 8334

         Layout : left-symmetric
     Chunk Size : 64K

   Device Role : Active device 2
   Array State : .AA. ('A' == active, '.' == missing, 'R' == replacing)


Il manque un disque, je ne vois pas /dev/sde* alors qu’il était listé dans la sortie de la commande précédente.
Est-il encore présent, peut-être renommé ? Dans ce cas relancer la commande avec le nouveau nom.

vérification de la présence des disques

fdisk -l |egrep "^/dev/sd.*"
/dev/sda1         2048   1050623   1048576   512M EFI System
/dev/sda2      1050624 473294847 472244224 225,2G Linux filesystem
/dev/sda3    473294848 488396799  15101952   7,2G Partition d'échange Linux
/dev/sdb1                   1    4080509    4080509     2G 83 Linux
/dev/sdb2             4080510 1953525167 1949444658 929,6G 83 Linux
/dev/sdc1                   1    4080509    4080509     2G 83 Linux
/dev/sdc2             4080510 1953525167 1949444658 929,6G 83 Linux
/dev/sdd1                   1    4080509    4080509     2G 83 Linux
/dev/sdd2             4080510 1953525167 1949444658 929,6G 83 Linux
/dev/sdf1                   1    4080509    4080509     2G 83 Linux
/dev/sdf2             4080510 1953525167 1949444658 929,6G 83 Linux
mdadm -E /dev/sd[b-f]
mdadm: Unknown keyword INACTIVE-ARRAY
/dev/sdb:
   MBR Magic : aa55
Partition[0] :      4080509 sectors at            1 (type 83)
Partition[1] :   1949444658 sectors at      4080510 (type 83)
/dev/sdc:
   MBR Magic : aa55
Partition[0] :      4080509 sectors at            1 (type 83)
Partition[1] :   1949444658 sectors at      4080510 (type 83)
/dev/sdd:
   MBR Magic : aa55
Partition[0] :      4080509 sectors at            1 (type 83)
Partition[1] :   1949444658 sectors at      4080510 (type 83)
/dev/sdf:
   MBR Magic : aa55
Partition[0] :      4080509 sectors at            1 (type 83)
Partition[1] :   1949444658 sectors at      4080510 (type 83)

effectivement changement nom, relance de la commande intégrale

mdadm: Unknown keyword INACTIVE-ARRAY
/dev/sdb:
   MBR Magic : aa55
Partition[0] :      4080509 sectors at            1 (type 83)
Partition[1] :   1949444658 sectors at      4080510 (type 83)
/dev/sdb1:
          Magic : a92b4efc
        Version : 0.90.00
           UUID : ab0d7fdf:373ee9f2:5d8fd52f:304e1b90
  Creation Time : Thu May  6 22:34:46 2010
     Raid Level : raid1
  Used Dev Size : 2040128 (1992.65 MiB 2089.09 MB)
     Array Size : 2040128 (1992.65 MiB 2089.09 MB)
   Raid Devices : 4
  Total Devices : 1
Preferred Minor : 127

    Update Time : Mon Nov  7 10:08:27 2016
          State : clean
 Active Devices : 1
Working Devices : 1
 Failed Devices : 2
  Spare Devices : 0
       Checksum : bd783ba5 - correct
         Events : 398


      Number   Major   Minor   RaidDevice State
this     1       8       17        1      active sync   /dev/sdb1

   0     0       0        0        0      removed
   1     1       8       17        1      active sync   /dev/sdb1
   2     2       0        0        2      faulty removed
   3     3       0        0        3      faulty removed
/dev/sdb2:
          Magic : a92b4efc
        Version : 1.0
    Feature Map : 0x0
     Array UUID : 2a4f36d2:ea62aea0:fdbb7d38:bdd9943d
           Name : batz:1
  Creation Time : Tue Nov 16 14:10:36 2010
     Raid Level : raid5
   Raid Devices : 4

 Avail Dev Size : 1949444384 (929.57 GiB 998.12 GB)
     Array Size : 2924166528 (2788.70 GiB 2994.35 GB)
  Used Dev Size : 1949444352 (929.57 GiB 998.12 GB)
   Super Offset : 1949444640 sectors
   Unused Space : before=0 sectors, after=288 sectors
          State : clean
    Device UUID : 9cbe3c84:1505c161:b189030d:f69a6d0f

    Update Time : Tue Oct 11 22:22:01 2016
       Checksum : 107d7d56 - correct
         Events : 8334

         Layout : left-symmetric
     Chunk Size : 64K

   Device Role : Active device 1
   Array State : .AA. ('A' == active, '.' == missing, 'R' == replacing)
/dev/sdc:
   MBR Magic : aa55
Partition[0] :      4080509 sectors at            1 (type 83)
Partition[1] :   1949444658 sectors at      4080510 (type 83)
/dev/sdc1:
          Magic : a92b4efc
        Version : 0.90.00
           UUID : ab0d7fdf:373ee9f2:5d8fd52f:304e1b90
  Creation Time : Thu May  6 22:34:46 2010
     Raid Level : raid1
  Used Dev Size : 2040128 (1992.65 MiB 2089.09 MB)
     Array Size : 2040128 (1992.65 MiB 2089.09 MB)
   Raid Devices : 4
  Total Devices : 2
Preferred Minor : 20

    Update Time : Thu Nov  3 13:30:16 2016
          State : clean
 Active Devices : 2
Working Devices : 2
 Failed Devices : 2
  Spare Devices : 0
       Checksum : bd73245b - correct
         Events : 348


      Number   Major   Minor   RaidDevice State
this     0       8       33        0      active sync   /dev/sdc1

   0     0       8       33        0      active sync   /dev/sdc1
   1     1       8       17        1      active sync   /dev/sdb1
   2     2       0        0        2      faulty removed
   3     3       0        0        3      faulty removed
/dev/sdc2:
          Magic : a92b4efc
        Version : 1.0
    Feature Map : 0x0
     Array UUID : 2a4f36d2:ea62aea0:fdbb7d38:bdd9943d
           Name : batz:1
  Creation Time : Tue Nov 16 14:10:36 2010
     Raid Level : raid5
   Raid Devices : 4

 Avail Dev Size : 1949444384 (929.57 GiB 998.12 GB)
     Array Size : 2924166528 (2788.70 GiB 2994.35 GB)
  Used Dev Size : 1949444352 (929.57 GiB 998.12 GB)
   Super Offset : 1949444640 sectors
   Unused Space : before=0 sectors, after=288 sectors
          State : clean
    Device UUID : 39745100:cad2e8c4:8e982a96:f6c18a25

    Update Time : Tue Oct 11 22:22:01 2016
       Checksum : 8efe3684 - correct
         Events : 8334

         Layout : left-symmetric
     Chunk Size : 64K

   Device Role : spare
   Array State : .AA. ('A' == active, '.' == missing, 'R' == replacing)
/dev/sdd:
   MBR Magic : aa55
Partition[0] :      4080509 sectors at            1 (type 83)
Partition[1] :   1949444658 sectors at      4080510 (type 83)
/dev/sdd1:
          Magic : a92b4efc
        Version : 0.90.00
           UUID : ab0d7fdf:373ee9f2:5d8fd52f:304e1b90
  Creation Time : Thu May  6 22:34:46 2010
     Raid Level : raid1
  Used Dev Size : 2040128 (1992.65 MiB 2089.09 MB)
     Array Size : 2040128 (1992.65 MiB 2089.09 MB)
   Raid Devices : 4
  Total Devices : 1
Preferred Minor : 127

    Update Time : Fri Nov  4 15:03:55 2016
          State : clean
 Active Devices : 1
Working Devices : 1
 Failed Devices : 2
  Spare Devices : 0
       Checksum : bd748bc3 - correct
         Events : 316


      Number   Major   Minor   RaidDevice State
this     2       8       17        2      active sync   /dev/sdb1

   0     0       0        0        0      removed
   1     1       0        0        1      faulty removed
   2     2       8       17        2      active sync   /dev/sdb1
   3     3       0        0        3      faulty removed
/dev/sdd2:
          Magic : a92b4efc
        Version : 1.0
    Feature Map : 0x0
     Array UUID : 2a4f36d2:ea62aea0:fdbb7d38:bdd9943d
           Name : batz:1
  Creation Time : Tue Nov 16 14:10:36 2010
     Raid Level : raid5
   Raid Devices : 4

 Avail Dev Size : 1949444384 (929.57 GiB 998.12 GB)
     Array Size : 2924166528 (2788.70 GiB 2994.35 GB)
  Used Dev Size : 1949444352 (929.57 GiB 998.12 GB)
   Super Offset : 1949444640 sectors
   Unused Space : before=0 sectors, after=288 sectors
          State : clean
    Device UUID : 67d1e6c9:4f1b36fd:2ee3ab6e:e0c921a6

    Update Time : Tue Oct 11 22:22:01 2016
       Checksum : e9f92ec4 - correct
         Events : 8334

         Layout : left-symmetric
     Chunk Size : 64K

   Device Role : Active device 2
   Array State : .AA. ('A' == active, '.' == missing, 'R' == replacing)
/dev/sdf:
   MBR Magic : aa55
Partition[0] :      4080509 sectors at            1 (type 83)
Partition[1] :   1949444658 sectors at      4080510 (type 83)
/dev/sdf1:
          Magic : a92b4efc
        Version : 0.90.00
           UUID : ab0d7fdf:373ee9f2:5d8fd52f:304e1b90
  Creation Time : Thu May  6 22:34:46 2010
     Raid Level : raid1
  Used Dev Size : 2040128 (1992.65 MiB 2089.09 MB)
     Array Size : 2040128 (1992.65 MiB 2089.09 MB)
   Raid Devices : 4
  Total Devices : 2
Preferred Minor : 127

    Update Time : Thu Nov  3 11:18:13 2016
          State : clean
 Active Devices : 2
Working Devices : 2
 Failed Devices : 1
  Spare Devices : 0
       Checksum : bd73059b - correct
         Events : 278


      Number   Major   Minor   RaidDevice State
this     3       8       65        3      active sync

   0     0       0        0        0      removed
   1     1       0        0        1      faulty removed
   2     2       8       33        2      active sync   /dev/sdc1
   3     3       8       65        3      active sync
/dev/sdf2:
          Magic : a92b4efc
        Version : 1.0
    Feature Map : 0x0
     Array UUID : 2a4f36d2:ea62aea0:fdbb7d38:bdd9943d
           Name : batz:1
  Creation Time : Tue Nov 16 14:10:36 2010
     Raid Level : raid5
   Raid Devices : 4

 Avail Dev Size : 1949444384 (929.57 GiB 998.12 GB)
     Array Size : 2924166528 (2788.70 GiB 2994.35 GB)
  Used Dev Size : 1949444352 (929.57 GiB 998.12 GB)
   Super Offset : 1949444640 sectors
   Unused Space : before=0 sectors, after=288 sectors
          State : clean
    Device UUID : 29970cd9:8e299bfb:c181a58f:f767c8c9

    Update Time : Tue Oct 11 22:22:01 2016
       Checksum : 3c243f71 - correct
         Events : 8334

         Layout : left-symmetric
     Chunk Size : 64K

   Device Role : spare
   Array State : .AA. ('A' == active, '.' == missing, 'R' == replacing)



la réponse ne te conviens pas ?

Si, mais il m’a fallu un peu de temps pour l’étudier.

Comme tu as dû le voir, le niveau de RAID des grandes partitions est identifié comme du RAID 5 et non du RAID 10 comme tu le pensais initialement ou du RAID 0 comme affiché par mdadm -D. La taille totale de l’ensemble est cohérente pour 4 disques en RAID 5 : (4 - 1) * 1 Go = 3 Go.

Du côté des mauvaises nouvelles, il n’y a que deux membres marqués actifs, le 0 et le 1 qui sont actuellement /dev/sdb2 et /dev/sdd2. Les deux autres sont marqués “spare” (en réserve). Un ensemble RAID 5 ne peut fonctionner avec deux membres actifs en moins, donc il reste dans l’état inactif. Je ne sais pas pourquoi deux des membres se sont retrouvés en spare. S’ils avaient eu des erreurs, ils auraient dû être marqués “faulty” (F) et non “spare” (S).

Ton objectif est-il de retrouver les données ou de remettre le RAID en fonctionnement ?

PS : Le changement de nom d’un des disques illustre pourquoi il ne faut pas utiliser l’option --verbose pour ajouter les définitions d’ensembles RAID existants dans /etc/mdadm/mdadm.conf. Cela ajoute une option devices avec la liste des noms de périphériques des membres du RAID qui fait que mdadm ne recherchera ensuite des membres que dans ces périphériques lors de l’auto-assemblage.

Mon Objectif principal est de récupérer les données.

Après avoir fait quelques tests pour essayer de reproduire la situation, j’ai compris que l’état de /dev/md1 apparemment incohérent avec l’examen des superblocs des partitions membres par mdadm --examine (pas le bon niveau de RAID…) rapporté dans /proc/mdstat et la sortie de mdadm -D dans tes premiers messages était dû à l’assemblage incrémental automatique (inachevé car il manque 2 membres actifs). La bonne nouvelle, c’est que la commande mdadm -Asf que tu as exécutée n’a pas d’effet sur un ensemble RAID assemblage incrémental, ce qui est confirmé par la date de dernière mise à jour des superblocs au 11 octobre 2016 donc tu n’as pas aggravé la situation.

Par contre je n’arrive toujours pas à comprendre comment l’ensemble RAID 5 s’est retrouvé dans cet état depuis le 11 octobre avec deux membres marqués en “spare” alors qu’il manque un membre actif pour que l’ensemble soit opérationnel. Quand j’ai marqué deux membres “faulty”, l’ensemble RAID s’est mis dans l’état “failed” (normal) et mdadm a refusé de rajouter des membres en “spare”. D’autre part les superblocs des membres “faulty” n’étaient plus mis à jour.

Ici les superblocs des 4 membres ont la même date de mise à jour (Update Time) et le même état des membres (Array State) indiquant que les membres 1 et 2 sont actifs et les membres 0 et 3 sont manquants (missing).

Le wiki RAID, mentionne deux méthodes pour réparer un ensemble RAID. La première est de forcer l’assemblage avec l’option --force. Dans ton cas il faudra d’abord arrêter l’ensemble à cause cause de l’assemblage incrémental partiel. Mais je ne vois pas comment ça pourrait marcher avec deux membres marqués en spare, sans rôle actif. La seconde méthode en dernier recours est de recréer l’ensemble avec les mêmes paramètres et l’option --assume-clean pour ne pas toucher aux données. Il faut aussi lister les membres dans l’ordre des rôles initiaux sinon les données seront dans le désordre.

N’ayant pas réussi à reproduire la situation de ton RAID 5, je n’a pas pu tester de scénario de récupération. Quand j’ai testé l’assemblage forcé avec --force, j’avais deux membres déclarés en “faulty” avec un rôle actif marqué dans leur superbloc, pas en “spare”. L’un des deux a été remis en actif dans son rôle initial (el’autre en spare pour reconstruction automatique à la prochaine écriture).

Bonjour PascalHambourg,

Merci d’avoir analyser mon problème,

pour résumer en clair et, si je suis les recommandations du Wiki Raid et les tiennes,

Hypothèse A

a) je doit stoper l’ensemble du RAID (a cause de assemblage incrémentiel partiel) comme suis

b) forcer l’assemblage

c) suivre la reconstruction si fonctionnel avec

pas sur que cela fonctionne à cause du manque de membres actifs. cella te semble correct ?

**Hypothèse B[quote=“PascalHambourg, post:16, topic:71595”]
recréer l’ensemble avec les mêmes paramètres et l’option --assume-clean pour ne pas toucher aux données. Il faut aussi lister les membres dans l’ordre des rôles initiaux sinon les données seront dans le désordre.
[/quote]

**
je ne vois pas trop comment procéder, une petit aide serais la bien venus :slight_smile:

Ce que j’écris ne concerne que md1, pas md127 qui est en RAID 1 avec un membre actif donc il est fonctionnel.

tu est sur ? au vus de ce que je vois ici

mdadm: Unknown keyword INACTIVE-ARRAY
/dev/sdb:
   MBR Magic : aa55
Partition[0] :      4080509 sectors at            1 (type 83)
Partition[1] :   1949444658 sectors at      4080510 (type 83)
/dev/sdb1:
          Magic : a92b4efc
        Version : 0.90.00
           UUID : ab0d7fdf:373ee9f2:5d8fd52f:304e1b90
  Creation Time : Thu May  6 22:34:46 2010
     Raid Level : raid1
  Used Dev Size : 2040128 (1992.65 MiB 2089.09 MB)
     Array Size : 2040128 (1992.65 MiB 2089.09 MB)
   Raid Devices : 4
  Total Devices : 1
Preferred Minor : 127
    Update Time : Mon Nov  7 10:08:27 2016
      State : clean
 Active Devices : 1
Working Devices : 1
 Failed Devices : 2
  Spare Devices : 0

Seulement 1 “devices” active sur 4 non ?

Pour md1 , a ma connaissance la seul maniéré de pouvoir les réactivés, serais de les déclarer en “faulty” et les réparer pour permettre la reconstruction du raid 5 quand pense tu ?

si je suis la dernière et ultime recommandation du wiki raid je ne trouve pas comment récupérer les “options origines” as tu une idée ?

C’est ce que j’expliquais : un membre actif est suffisant pour démarrer un ensemble RAID 1. Pour le resynchroniser il suffit de retirer les membres failed puis de rajouter les 3 membres manquants. De toute façon tu as écrit que cet ensemble ne contenait pas de données utiles.

Si tu parles des deux membres marqués “spare”, je ne suis pas sûr que cela fonctionne car ils n’ont pas de rôle actif, mdadm ne saura pas lequel réactiver en position 0 et 3. Dans tous mes essais mdadm refuse d’ajouter des membres à un ensemble FAILED ou INACTIVE, même en spare.

Avant toute tentative, je recommande d’utiliser mdadm --dump pour faire une copie des métadonnées des 4 partitions membres de l’ensemble RAID 5, et une copie de la sortie de mdadm --examine sur ces 4 partitions également. Les options de création s’y trouvent (–metadata=1.0 --level=5 --raid-devices=4 --size=974722176 --layout=left-symmetric --chunk=64…). Ne pas oublier --assume-clean et --readonly pour ne pas modifier les données.

Il serait aussi intéressant d’étudier les diagnostics SMART des 4 disques avec smartctl -a à la recherche de défaillances matérielles qui auraient pu causer la défaillance du RAID.

Dans tous les cas, tu auras deux difficultés à résoudre :

  • Identifier les rôles (positions 0 à 3) de chaque partition membre. Les deux partitions marquées “active” ont les rôles 1 et 2, mais les deux marquées “spare” n’ont pas cette information.
  • Identifier quelle est la partition qui a été désactivée en premier. Si l’ensemble RAID 5 a continué à fonctionner en mode dégradé, ses données ne sont plus à jour. Il ne faudra donc pas l’utiliser pour réactiver ou recréer l’ensemble RAID (la remplacer par “missing” pour la création) sinon le contenu de l’ensemble ainsi assemblé risque d’être incohérent.

Merci pour ton aide, j’attends Laval de mon chef pour aller plus loin. je te tiens informé.

Entendu.

Pour information, j’ai testé la recréation d’un ensemble RAID 5 de 4 membres avec les mêmes paramètres et l’option --assume-clean pour préserver les données. Si on remet les membres dans l’ordre de leurs rôles initiaux, le système de fichiers est cohérent (vérifié avec fsck) et le contenu est lisible.

Dans ton cas, il y a en plus l’inconnue de l’état des données.