# [raid] Récup d'un raid5 suite à changement d'OS (résolu)

## manu.acl

Bonjour tout le monde.

J'avais un bon petit raid5 sur 4 disques SATA de 500Go sur une très très vieille Gentoo.

Mais mon vieux disque IDE qui contenait mon OS m'a lâché ce w-e.

Sur le coup je me dis "pas de soucis, le raid5 n'a rien".

Hop, je change le disque décédé, je réinstalle un Linux en catastrophe (une debian pour aller vite).

Et là surprise, je n'arrive plus à monter mon raid.  :Sad: 

```
# mdadm -C /dev/md0 -l5 -n4 -p ls -c 32 /dev/sda1 /dev/sdb1 /dev/sdc1 /dev/sdd1

mdadm: /dev/sda1 appears to contain an ext2fs file system

    size=1465151808K  mtime=Sat Feb 14 13:26:24 2009

mdadm: /dev/sda1 appears to be part of a raid array:

    level=raid5 devices=4 ctime=Mon Feb 16 00:23:43 2009

mdadm: /dev/sdb1 appears to be part of a raid array:

    level=raid5 devices=4 ctime=Mon Feb 16 00:23:43 2009

mdadm: /dev/sdc1 appears to be part of a raid array:

    level=raid5 devices=4 ctime=Mon Feb 16 00:23:43 2009

mdadm: /dev/sdd1 appears to contain an ext2fs file system

    size=1196781888K  mtime=Sat Feb 14 13:26:24 2009

mdadm: /dev/sdd1 appears to be part of a raid array:

    level=raid5 devices=4 ctime=Mon Feb 16 00:23:43 2009

Continue creating array? y

mdadm: array /dev/md0 started.

# mount /dev/md0 /mnt/raid5/

mount: wrong fs type, bad option, bad superblock on /dev/md0,

       missing codepage or helper program, or other error

       In some cases useful info is found in syslog - try

       dmesg | tail  or so
```

J'ai essayé les manips qu'on trouve sur cette page en googleant un peu, mais ça ne donne rien...

J'ai beau chercher, je ne trouve toujours rien qui fait avancer la situation. Et j'ai vraiment besoin des données détenues par ces disques...

Un petit coup de pouce ne serait pas de refus.  :Rolling Eyes: Last edited by manu.acl on Fri Feb 20, 2009 1:20 pm; edited 1 time in total

----------

## scherz0

 *manu.acl wrote:*   

> 
> 
> ```
> # mdadm -C /dev/md0 -l5 -n4 -p ls -c 32 /dev/sda1 /dev/sdb1 /dev/sdc1 /dev/sdd1
> 
> ...

 

Si j'ai bien compris, tu voulais assembler la matrice existante, c'est à dire utiliser mdadm -A.

Avec mdadm -C, tu as créè une nouvelle matrice, et ré-initialisé les superblocks (d'ou les messages d'avertissement de mdadm "appears to be part of a raid array").  Vraiment désolé pour toi  :Sad: 

Je ne pense pas que tout soit perdu, mais je n'ai pas d'idée pour l'instant.  Je peux seulement te conseiller de ne plus toucher à rien avant d'être certain de la procédure à appliquer.

----------

## manu.acl

Et bien en fait j'ai suivi les conseils du créateur de mdadm.

Je suis tombé sur un fofo où un gars postait son dialogue avec lui.

Il n'arrivait pas à reconstruire son raid et l'a donc contacté par email, il lui a donné cette commande qui a fonctionné pour lui.

Je n'arrive pas à retrouver l'url.

Et toujours à partir de la même source, la commande mdadm -C ne toucherait pas au contenu des disques.

```
# fdisk -lu /dev/md0

Disk /dev/md0: 1500.3 GB, 1500315451392 bytes

2 heads, 4 sectors/track, 366287952 cylinders, total 2930303616 sectors

Units = sectors of 1 * 512 = 512 bytes

Disk identifier: 0x00000000

Disk /dev/md0 doesn't contain a valid partition table
```

 :Sad: 

----------

## manu.acl

Même en essayant de monter les partitions individuellement via leur emplacement physique : 

```
# fdisk -lu /dev/sda

Disk /dev/sda: 500.1 GB, 500107862016 bytes

255 heads, 63 sectors/track, 60801 cylinders, total 976773168 sectors

Units = sectors of 1 * 512 = 512 bytes

Disk identifier: 0x0cc0626e

   Device Boot      Start         End      Blocks   Id  System

/dev/sda1              63   976768064   488384001   fd  Linux raid autodetect

# expr 63 \* 512

32256

# losetup -f

/dev/loop0

# losetup -o 32256 /dev/loop0 /dev/sda

# mount -o ro -t ext3 /dev/loop0 /mnt/raid5/

mount: wrong fs type, bad option, bad superblock on /dev/loop0,

       missing codepage or helper program, or other error

       In some cases useful info is found in syslog - try

       dmesg | tail  or so
```

Il me semble bien que c'est normalement faisable de monter individuellement les partitions d'un raid ?

Le dmesg conseillé par mount :

```
# dmesg | tail

[ 5086.554800]  disk 1, o:1, dev:sdb1

[ 5086.554800]  disk 2, o:1, dev:sdc1

[ 5086.554800]  disk 3, o:1, dev:sdd1

[ 5086.554800] md: recovery of RAID array md0

[ 5086.554800] md: minimum _guaranteed_  speed: 1000 KB/sec/disk.

[ 5086.554800] md: using maximum available idle IO bandwidth (but not more than 200000 KB/sec) for recovery.

[ 5086.554800] md: using 128k window, over a total of 488383936 blocks.

[ 5086.603032] EXT3-fs: group descriptors corrupted!

[ 6684.370843] EXT3-fs error (device loop0): ext3_check_descriptors: Block bitmap for group 1920 not in group (block 264241664)!

[ 6684.370843] EXT3-fs: group descriptors corrupted!
```

----------

## scherz0

 *manu.acl wrote:*   

> Et toujours à partir de la même source, la commande mdadm -C ne toucherait pas au contenu des disques.

 

Pas au contenu, mais cette commande initialise le superblock de chaque élément de la matrice.  Et l'emplacement du superblock sur chaque device depend de la version, donc par cette opération il est possible que certaines données aient été perdues.

As-tu essayé mdadm -A avant d'utiliser le mode création ?  Et que disait mdadm -E /dev/sd[abcd]1 avant ?

 *Quote:*   

> Il me semble bien que c'est normalement faisable de monter individuellement les partitions d'un raid ?

 

D'un raid1 oui, puisque chaque élément contient une copie complète.  Mais un élément d'un raid5 à 4 disques ne contient qu'1/3 des données...

 *Quote:*   

> 
> 
> ```
> # mdadm -C /dev/md0 -l5 -n4 -p ls -c 32 /dev/sda1 /dev/sdb1 /dev/sdc1 /dev/sdd1 
> ```
> ...

 

Le raid5 précédent était-il bien 32k / left-symmetric ?

----------

## manu.acl

 *scherz0 wrote:*   

> As-tu essayé mdadm -A avant d'utiliser le mode création ?  Et que disait mdadm -E /dev/sd[abcd]1 avant ?

 

```
# mdadm -A /dev/md0

mdadm: no devices found for /dev/md0

# mdadm -E /dev/sd[abcd]1

/dev/sda1:

          Magic : a92b4efc

        Version : 00.90.00

           UUID : 61648701:76cc8f5b:9d4deba6:47ca997f (local to host debian)

  Creation Time : Mon Feb 16 12:17:32 2009

     Raid Level : raid5

  Used Dev Size : 488383936 (465.76 GiB 500.11 GB)

     Array Size : 1465151808 (1397.28 GiB 1500.32 GB)

   Raid Devices : 4

  Total Devices : 5

Preferred Minor : 0

    Update Time : Mon Feb 16 12:17:32 2009

          State : clean

 Active Devices : 3

Working Devices : 4

 Failed Devices : 1

  Spare Devices : 1

       Checksum : 16c42807 - correct

         Events : 1

         Layout : left-symmetric

     Chunk Size : 32K

      Number   Major   Minor   RaidDevice State

this     0       8        1        0      active sync   /dev/sda1

   0     0       8        1        0      active sync   /dev/sda1

   1     1       8       17        1      active sync   /dev/sdb1

   2     2       8       33        2      active sync   /dev/sdc1

   3     3       0        0        3      faulty

   4     4       8       49        4      spare   /dev/sdd1

/dev/sdb1:

          Magic : a92b4efc

        Version : 00.90.00

           UUID : 61648701:76cc8f5b:9d4deba6:47ca997f (local to host debian)

  Creation Time : Mon Feb 16 12:17:32 2009

     Raid Level : raid5

  Used Dev Size : 488383936 (465.76 GiB 500.11 GB)

     Array Size : 1465151808 (1397.28 GiB 1500.32 GB)

   Raid Devices : 4

  Total Devices : 5

Preferred Minor : 0

    Update Time : Mon Feb 16 12:17:32 2009

          State : clean

 Active Devices : 3

Working Devices : 4

 Failed Devices : 1

  Spare Devices : 1

       Checksum : 16c42819 - correct

         Events : 1

         Layout : left-symmetric

     Chunk Size : 32K

      Number   Major   Minor   RaidDevice State

this     1       8       17        1      active sync   /dev/sdb1

   0     0       8        1        0      active sync   /dev/sda1

   1     1       8       17        1      active sync   /dev/sdb1

   2     2       8       33        2      active sync   /dev/sdc1

   3     3       0        0        3      faulty

   4     4       8       49        4      spare   /dev/sdd1

/dev/sdc1:

          Magic : a92b4efc

        Version : 00.90.00

           UUID : 61648701:76cc8f5b:9d4deba6:47ca997f (local to host debian)

  Creation Time : Mon Feb 16 12:17:32 2009

     Raid Level : raid5

  Used Dev Size : 488383936 (465.76 GiB 500.11 GB)

     Array Size : 1465151808 (1397.28 GiB 1500.32 GB)

   Raid Devices : 4

  Total Devices : 5

Preferred Minor : 0

    Update Time : Mon Feb 16 12:17:32 2009

          State : clean

 Active Devices : 3

Working Devices : 4

 Failed Devices : 1

  Spare Devices : 1

       Checksum : 16c4282b - correct

         Events : 1

         Layout : left-symmetric

     Chunk Size : 32K

      Number   Major   Minor   RaidDevice State

this     2       8       33        2      active sync   /dev/sdc1

   0     0       8        1        0      active sync   /dev/sda1

   1     1       8       17        1      active sync   /dev/sdb1

   2     2       8       33        2      active sync   /dev/sdc1

   3     3       0        0        3      faulty

   4     4       8       49        4      spare   /dev/sdd1

/dev/sdd1:

          Magic : a92b4efc

        Version : 00.90.00

           UUID : 61648701:76cc8f5b:9d4deba6:47ca997f (local to host debian)

  Creation Time : Mon Feb 16 12:17:32 2009

     Raid Level : raid5

  Used Dev Size : 488383936 (465.76 GiB 500.11 GB)

     Array Size : 1465151808 (1397.28 GiB 1500.32 GB)

   Raid Devices : 4

  Total Devices : 5

Preferred Minor : 0

    Update Time : Mon Feb 16 12:17:32 2009

          State : clean

 Active Devices : 3

Working Devices : 4

 Failed Devices : 1

  Spare Devices : 1

       Checksum : 16c42839 - correct

         Events : 1

         Layout : left-symmetric

     Chunk Size : 32K

      Number   Major   Minor   RaidDevice State

this     4       8       49        4      spare   /dev/sdd1

   0     0       8        1        0      active sync   /dev/sda1

   1     1       8       17        1      active sync   /dev/sdb1

   2     2       8       33        2      active sync   /dev/sdc1

   3     3       0        0        3      faulty

   4     4       8       49        4      spare   /dev/sdd1
```

C'est les infos actuelles pour le -E par contre.  :Neutral: 

J'aime pas trop le faulty.

 *Quote:*   

> Le raid5 précédent était-il bien 32k / left-symmetric ?

 Il me semble bien... je l'ai créé il y a un bon bout de temps à vrai dire... je dois me retaper la doc de mdadm tous les 36 du mois, quand j'ai un pépin.  :Confused: 

J'ai récupéré l'ancien fichier mdadm.conf avec un accès chanceux sur l'ancien disque :

```
# cat old/etc/mdadm/mdadm.conf

DEVICE partitions

ARRAY /dev/md0 level=raid5 num-devices=4 spares=1 UUID=30ba8639:3983e0f2:7cd1d11f:121afdd9
```

l'UUID a en effet changé.

----------

## manu.acl

Certains parlent de testdisk

```
TESTDISK(1)                                            Administration Tools                                           TESTDISK(1)

NAME

       testdisk - Scan and repair disk partitions

SYNOPSIS

       testdisk [/log] [/debug] [/dump]

       testdisk /list [/log]

DESCRIPTION

          TestDisk checks and recovers lost partitions

          It works with :

          - BeFS (BeOS)

          - BSD disklabel (FreeBSD/OpenBSD/NetBSD)

          - CramFS, Compressed File System

          - DOS/Windows FAT12, FAT16 and FAT32

          - HFS and HFS+, Hierarchical File System

          - JFS, IBM’s Journaled File System

          - Linux Ext2 and Ext3

          - Linux Raid

            RAID 1: mirroring

            RAID 4: striped array with parity device

            RAID 5: striped array with distributed parity information

            RAID 6: striped array with distributed dual redundancy information

          - Linux Swap (versions 1 and 2)

          - LVM and LVM2, Linux Logical Volume Manager

          - Mac partition map

          - Novell Storage Services NSS

          - NTFS (Windows NT/2K/XP/2003/Vista)

          - ReiserFS 3.5, 3.6 and 4

          - Sun Solaris i386 disklabel

          - Unix File System UFS and UFS2 (Sun/BSD/...)

          - XFS, SGI’s Journaled File System

OPTIONS

       /log   create a testdisk.log file

       /debug add debug information

       /dump  dump raw sectors

       /list  display current partitions

SEE ALSO

       fdisk(1), photorec(1).

AUTHOR

       TestDisk 6.9, Data Recovery Utility, February 2008

       Christophe GRENIER <grenier@cgsecurity.org>

       http://www.cgsecurity.org

2008                                                         February                                                 TESTDISK(1)
```

Quelqu'un l'a déjà utilisé ?

----------

## manu.acl

Es-ce qu'un dd bourrin vers une nouvelle partition pourrait être utile ?...

Je ne sais plus où chercher.  :Sad: 

----------

## kwenspc

anigel, El_Goretto à la rescousse?  :Neutral: 

----------

## manu.acl

 *kwenspc wrote:*   

> anigel, El_Goretto à la rescousse? 

 Des pseudos d'anciens... ça me redonne un peu d'espoir.  :Wink: 

J'ai vu des miracles sur ce fofo.  :Rolling Eyes: 

----------

## scherz0

 *manu.acl wrote:*   

> 
> 
> ```
> # dmesg | tail
> 
> ...

 

 :Shocked:  Je n'avais pas vu ça...  Je pense qu'un 1 des 4 disques (celui qui a été reconstruit) ne contient plus de données utiles.  Si tu refais des tentatives de création, je te conseille fortement de désactiver la reconstruction, sous peine de perdre un 2ème disque !

Une solution raisonnable serait peut-être de faire une copie (même partielle) de chacun des disques, puis de faire des tentatives d'assemblage sur ces copies.  Évidemment, en cas de copie partielle, le résutat sera un FS tronqué, mais le but est seulement de retrouver les paramétres originaux (ordre des disques, géométrie, taille de bloc, etc.).

Une fois les paramètres connus avec certitude, créer la matrice avec ces paramètres (en désactivant la reconstuction, pour éviter le pire).

EDIT : évidement, dès que tu auras la certitude que la matrice est assemblée correctement (vérification du FS, montage read-only, vérification du contenu, etc.), lancer la reconstruction dès que possible !Last edited by scherz0 on Tue Feb 17, 2009 5:58 pm; edited 1 time in total

----------

## El_Goretto

 *kwenspc wrote:*   

> anigel, El_Goretto à la rescousse? 

 

Oui oui, testdisk c'est le bien  :Smile: 

En théorie testdisk c'est safe, mais je ne l'ai utilisé que dans le cas d'une "disparition" de partition LVM. C'est plus ou moins foolproof (en tout cas les gens en panique arrivent à l'utiliser...), mais je te conseille de lire les 2-3 pages du wiki testdisk avant de te lancer.

+1 pour désactiver la reconstruction RAID (comment faire par contre, aucune idée), et lancer testdisk via un liveCD genre le sublime sysrescueCD.

----------

## scherz0

 *El_Goretto wrote:*   

> +1 pour désactiver la reconstruction RAID (comment faire par contre, aucune idée), et lancer testdisk via un liveCD genre le sublime sysrescueCD.

 

--assume-clean

 *Quote:*   

> It  can be useful when trying to recover from a major failure as you can be sure that no data will be affected unless  you actually write to the array

 

----------

## manu.acl

Bon, j'ai fait une analyse de /dev/md0 avec testdisk :

```
TestDisk 6.9, Data Recovery Utility, February 2008

Christophe GRENIER <grenier@cgsecurity.org>

http://www.cgsecurity.org

Disk /dev/md0 - 1500 GB / 1397 GiB - CHS 366287952 2 4

     Partition               Start        End    Size in sectors

* HFS                  171195996   0  1 171236317   1  4     322576

P HFS                  254112831   0  1 254112831   1  4          8 [?  p ffBD~Y~Y%D~Y~Y^AD]

h^U]S                  279073593   1  1 293011961   1  4  111506948 [

Structure: Ok.  Use Up/Down Arrow keys to select partition.

Use Left/Right Arrow keys to CHANGE partition characteristics:

*=Primary bootable  P=Primary  L=Logical  E=Extended  D=Deleted

Keys A: add partition, L: load backup, T: change type,

     Enter: to continue

HFS, 165 MB / 157 MiB
```

Je suppose que c'est la dernière qui m'intéresse.  :Wink: 

Par contre, je n'ai pas vraiment la capacité pour sauvegarder les 1.5To sur d'autres supports... j'ai peur d'aller trop vite et refaire une bourde...

Et j'ai fait "Ctrl+C" dans Putty pour copier le résultat de l'analyse qui a duré 6h... c'est reparti pour la nuit.

----------

## scherz0

 *manu.acl wrote:*   

> Bon, j'ai fait une analyse de /dev/md0 avec testdisk :

 

Es-tu conscient que /dev/md0 contient 1/4 de random, et que le reste est complètement mélangé ?  J'espère que tu sais ce que tu fais.

Tant que tu ne fais aucune autre modification, tes disques contiennent encore probablement toutes tes données (sauf si les nouvelles metadonnées ont été écrites à un endroit différent).  Mais si tu fais des modifications sur /dev/md0, tu risques de perdre les données originales...

 *Quote:*   

> 
> 
> ```
> 
> Disk /dev/md0 - 1500 GB / 1397 GiB - CHS 366287952 2 4
> ...

 

Ton raid5 original était vraiment partitionné ? En quoi la dernière partition semble plus intéressante ? Cette table des partitions semble extraite de /dev/urandom  :Confused: 

Je ne connais pas testdisk donc j'abandonne le sujet et te souhaite bonne chance.  Mais à ta place, j'essairais avant tout de résoudre le problème de façon rationnelle et sans précipitation.  Si toutes les données sont encore là, il suffit de les réassembler correctement.

----------

## manu.acl

Certes... de toutes manières je ne compte pas faire d'autres modifications avant d'être sur que cela fonctionne...

----------

## anigel

Plop,

Bon, déjà, soyons clairs : ça pue. Sans vouloir être défaitiste tu es mal engagé. Déjà quand je lis "une très très vieille Gentoo", ça me dit : LVM1. Or toute les distribs récentes tournent sur LVM2, dont le format de données est différent. Donc déjà tu risque d'avoir des soucis avec ça. Dans tous les cas, ne faire aucune manip destructrice avec les outils actuels.

Ensuite, pour bidouiller les RAIDs, j'aime bien utiliser systemrescuecd (en fait je l'utilise pour tout ou presque, mais là en l'occurrence c'est particulièrement adapté).

Ensuite, d'après les infos que tu nous fournis, je pense que je ferais les manips suivantes :

D'abord repérer le disque neuf, sur lequel les données sont donc manquantes (puisque non encore synchronisé). Imaginons que ce soit /dev/sda1 dans ton cas. On va, dans l'ordre, arrêter le sous-système RAID, supprimer l'empreinte de ton disque défectueux (qui n'existe plus physiquement dans la machine) du groupe RAID, puis relancer le RAID en mode dégradé.

```
mdadm --stop /dev/md0

mdadm --manage --remove /dev/md0 /dev/sda1

mdadm --run /dev/md0
```

A ce stade, tu dois pouvoir utiliser ton RAID-5 en mode dégradé (= il n'y a plus de sécurité RAID). Si ce n'est pas le cas ça sent mauvais. Ensuite, il suffit juste de rajouter le nouveau device à ton RAID (pendant qu'il tourne, ça ne pose pas de souci).

Je reviendrai sur ce sujet dans la soirée, tiens-nous au courant ?

----------

## anigel

J'oubliais : merci de poster ici en complément le résultat complet de "fdisk -l", en précisant le device qui a été remplacé.

Merci.

----------

## manu.acl

```
# mdadm --stop /dev/md0 

mdadm: stopped /dev/md0

# mdadm --manage --remove /dev/md0 /dev/sdd1

mdadm: cannot get array info for /dev/md0
```

/dev/sdd étant le dernier disque que j'ai ajouté au raid.

```
# fdisk -l

Disk /dev/sda: 500.1 GB, 500107862016 bytes

255 heads, 63 sectors/track, 60801 cylinders

Units = cylinders of 16065 * 512 = 8225280 bytes

Disk identifier: 0x0cc0626e

   Device Boot      Start         End      Blocks   Id  System

/dev/sda1               1       60801   488384001   fd  Linux raid autodetect

Disk /dev/sdb: 500.1 GB, 500107862016 bytes

255 heads, 63 sectors/track, 60801 cylinders

Units = cylinders of 16065 * 512 = 8225280 bytes

Disk identifier: 0x7399bb29

   Device Boot      Start         End      Blocks   Id  System

/dev/sdb1               1       60801   488384001   fd  Linux raid autodetect

Disk /dev/sdc: 500.1 GB, 500107862016 bytes

255 heads, 63 sectors/track, 60801 cylinders

Units = cylinders of 16065 * 512 = 8225280 bytes

Disk identifier: 0x28850edc

   Device Boot      Start         End      Blocks   Id  System

/dev/sdc1               1       60801   488384001   fd  Linux raid autodetect

Disk /dev/sdd: 500.1 GB, 500107862016 bytes

255 heads, 63 sectors/track, 60801 cylinders

Units = cylinders of 16065 * 512 = 8225280 bytes

Disk identifier: 0x352282a0

   Device Boot      Start         End      Blocks   Id  System

/dev/sdd1               1       60801   488384001   fd  Linux raid autodetect
```

----------

## scherz0

J'allais écrire de ne surtout pas faire ce qu'a suggéré anigel, mais trop tard...

Je te conseille fortement de ne pas appliquer aveuglément les suggestions un peu rapides que tu pourras trouver sur ce forum ou ailleurs.

Il ne s'agit évidemment pas de remplacer un disque défectueux dans un raid5.  Par ailleurs, on ne peut pas supprimer un élément d'une matrice stoppée, en tout cas pas aussi simplement. D'ou le message 

```
mdadm: cannot get array info for /dev/md0
```

Encore une fois, ne fais plus aucune manipulation sur la matrice telle que tu l'as recrée.  Elle ne correspond visiblement pas aux paramètres originaux et à chaque modification, tu écriras de la bouillie sur tes 4 disques.  Maintenant qu'elle est stoppée, laisse la comme ça et reprends les choses dans l'ordre.

EDIT : concernant LVM1, si ton raid5 était géré ainsi, ça ne posera aucun problème.  lvm 2.x lit et écrit les métadonnées de type 1.

----------

## anigel

 *scherz0 wrote:*   

> J'allais écrire de ne surtout pas faire ce qu'a suggéré anigel, mais trop tard...

 

Trop tard pour... ? Les commandes que j'ai donné ici ne font rien si la matrice ne correspond pas à ce à quoi le système s'attend (ce qui est le cas, je voulais vérifier). Et si il a déjà recréé une matrice par-dessus l'ancienne, alors seule la composition de la matrice en question est affectée, tant que l'espace RAID ainsi créé n'est pas formaté ou utilisé. Ca rejoint d'ailleurs ce que lui a conseillé le créateur de mdadm :

 *manu.acl wrote:*   

> Et toujours à partir de la même source, la commande mdadm -C ne toucherait pas au contenu des disques.

 

mdadm -C ne fait que re-créer les descripteurs de device, et enregistrer la composition du RAID sur le disque. manu a donc ce soir un RAID tout neuf, heureusement non formaté, mais formé de 4 devices dont un qui ne contient rien d'utile, voire même qui peut poser problème dans le cadre de la récupération de données. Les 3 autres devices contiennent toujours ses données.

Maintenant, ma suggestion serait de supprimer ce RAID foireux, et d'en re-créer un sur 4 disques, dont un marqué "missing". Ainsi le disque marqué "missing" n'entrera pas en ligne de compte dans le calcul des parités pour la lecture du RAID-5, et manu devrait pouvoir relire ses données, à condition que son raid soit exactement constitué de la même façon que le précédent (et là, attention : l'ordre dans lequel on déclare les devices est important). Ensuite seulement il  ajoutera au RAID le nouveau disque neuf, afin de faire re-calculer les parités proprement.

 *scherz0 wrote:*   

> Je te conseille fortement de ne pas appliquer aveuglément les suggestions un peu rapides que tu pourras trouver sur ce forum ou ailleurs.

 

Dans l'absolu, j'approuve totalement  :Wink: .

 *scherz0 wrote:*   

> Il ne s'agit évidemment pas de remplacer un disque défectueux dans un raid5.  Par ailleurs, on ne peut pas supprimer un élément d'une matrice stoppée, en tout pas pas aussi simplement. D'ou le message 
> 
> ```
> mdadm: cannot get array info for /dev/md0
> ```
> ...

 

Je dirais plutôt : maintenant qu'elle est stoppée, et qu'on a confirmation que la conf actuelle ne correspond à rien tel quel sur le disque, alors tu peux essayer de la re-construire "sur 3 pattes". Tu n'écris "de la bouillie" que sur les zones du disque dédiées au management du RAID et à son identification par le pilote md, en aucun cas sur tes données (en tous cas pas tant que tu travaille sur un nombre de disques identiques à celui de départ).

Sinon, avant de donner les commandes kivonbien, j'attends que Sherz0 confirme ou non mes suggestions, il a l'air de maîtriser, et vu la gravité de la situation, mieux vaut 2 avis qu'un seul.

----------

## scherz0

Anigel, désolé pour mon intervention un peu brutale mais quand j'ai lu ça

 *anigel wrote:*   

> A ce stade, tu dois pouvoir utiliser ton RAID-5 en mode dégradé

 

je craignais que Manu imagine que tout allait être réglé en 2 minutes et fasse des manipulations irréversibles.  En tant que n00b je dois insister lourdement pour tenter d'être convaincant  :Wink: 

 *Quote:*   

> Trop tard pour... ?

 

...pour lui dire de ne toucher à rien.  J'étais inquiet que Manu puisse copier texto la commande et sortir sda1, avant éventuellement de le réintégrer.  Avec ce genre de manip' il aurait pu finir par provoquer une nouvelle synchro sur un autre élément que sdd1.

 *Quote:*   

> Les commandes que j'ai donné ici ne font rien si la matrice ne correspond pas à ce à quoi le système s'attend (ce qui est le cas, je voulais vérifier).

 

Je ne comprends pas ce que tu voulais vérifier. Actuellement il a une matrice cohérente et fonctionelle au niveau du système (évidemment, elle ne contient rien d'intéressant dans cet état).  La commande --remove n'a pas fonctionné uniquement parce que la matrice était stoppée.

 *Quote:*   

> mdadm -C ne fait que re-créer les descripteurs de device, et enregistrer la composition du RAID sur le disque.

 

En faisant ça, il a perdu ses métadonnées originales, et accessoirement dézingué sdd1 puisque par défaut, ça active la matrice et démarre la synchro...  Ça fait beaucoup d'écritures pour une commande qui "ne touche pas au contenu des disques".  Je serais curieux de voir le forum en question, parce que ça me parait sidérant qu'on puisse conseiller ça sans indiquer qu'il faut d'abord sauvegarder les métadonnées.

 *Quote:*   

> Maintenant, ma suggestion serait de supprimer ce RAID foireux, et d'en re-créer un sur 4 disques, dont un marqué "missing". Ainsi le disque marqué "missing" n'entrera pas en ligne de compte dans le calcul des parités pour la lecture du RAID-5, et manu devrait pouvoir relire ses données, à condition que son raid soit exactement constitué de la même façon que le précédent (et là, attention : l'ordre dans lequel on déclare les devices est important). Ensuite seulement il ajoutera au RAID le nouveau disque neuf, afin de faire re-calculer les parités proprement.
> 
> [...]
> 
> Je dirais plutôt : maintenant qu'elle est stoppée, et qu'on a confirmation que la conf actuelle ne correspond à rien tel quel sur le disque, alors tu peux essayer de la re-construire "sur 3 pattes". Tu n'écris "de la bouillie" que sur les zones du disque dédiées au management du RAID et à son identification par le pilote md, en aucun cas sur tes données (en tous cas pas tant que tu travaille sur un nombre de disques identiques à celui de départ).

 

J'ai insisté à plusieurs reprises sur le fait qu'il risquait d'écrire de la bouillie sur ses disques parce que je le voyais mal barré, par exemple à chercher une table de partitions sur un device supposé contenir un FS   :Confused: 

 *Quote:*   

> Sinon, avant de donner les commandes kivonbien, j'attends que Sherz0 confirme ou non mes suggestions

 

J'adhère complètement : depuis mardi je suggère à peu près la même chose  :Wink:  https://forums.gentoo.org/viewtopic-p-5485979-highlight-.html#5485979

Pour l'instant la seule certitude, c'est que sda1 contient le premier "chunk".  D'après les messages de Manu (avril 2008), sdd1 devrait être numéro 4.  Il est probable que sdb1 et sdc1 soient 2 et 3.

Manu, tu as indiqué que 32k était "de mémoire" le paramètre de ton raid5 ; peux-tu confirmer que ce n'était pas un paramètre que tu as recopié sur le forum que tu citais ?  Avec les versions récentes de mdadm, le défaut est 64k.

----------

## manu.acl

 *scherz0 wrote:*   

> Pour l'instant la seule certitude, c'est que sda1 contient le premier "chunk".  D'après les messages de Manu (avril 2008), sdd1 devrait être numéro 4.  Il est probable que sdb1 et sdc1 soient 2 et 3.
> 
> Manu, tu as indiqué que 32k était "de mémoire" le paramètre de ton raid5 ; peux-tu confirmer que ce n'était pas un paramètre que tu as recopié sur le forum que tu citais ?  Avec les versions récentes de mdadm, le défaut est 64k.

 Ah oui, j'avais zappé l'étape de l'upgrade matériel du serveur en avril 2008...  :Rolling Eyes: 

Joli réflexe scherz0, je devrais parfois faire pareil pour mes propres posts.  :Surprised: 

J'avais en effet recréé un raid tout neuf à ce moment là et transféré les données de l'ancien raid en IDE vers le nouveau en SATA avec une simple commande cp.

----------

## manu.acl

 *Quote:*   

> Manu, tu as indiqué que 32k était "de mémoire" le paramètre de ton raid5 ; peux-tu confirmer que ce n'était pas un paramètre que tu as recopié sur le forum que tu citais ? Avec les versions récentes de mdadm, le défaut est 64k.

 Bien vu, j'étais resté sur les paramètres de l'ancien raid...

Le nouveau est en effet en 64k, j'ai recréé la matrice

```
# mdadm -C /dev/md0 -l5 -n4 -p ls -c 64 /dev/sda1 /dev/sdb1 /dev/sdc1 /dev/sdd1 

mdadm: /dev/sda1 appears to contain an ext2fs file system

    size=1465151808K  mtime=Sat Feb 14 13:26:24 2009

mdadm: /dev/sda1 appears to be part of a raid array:

    level=raid4 devices=4 ctime=Mon Feb 16 16:09:01 2009

mdadm: /dev/sdb1 appears to be part of a raid array:

    level=raid4 devices=4 ctime=Mon Feb 16 16:09:01 2009

mdadm: /dev/sdc1 appears to be part of a raid array:

    level=raid4 devices=4 ctime=Mon Feb 16 16:09:01 2009

mdadm: /dev/sdd1 appears to contain an ext2fs file system

    size=1196781888K  mtime=Sat Feb 14 13:26:24 2009

mdadm: /dev/sdd1 appears to be part of a raid array:

    level=raid4 devices=4 ctime=Mon Feb 16 16:09:01 2009

Continue creating array? y

mdadm: array /dev/md0 started.

# mount /dev/md0 /mnt/raid5/

# ls /mnt/raid5

apache  cyber  lost+found
```

Merci pour le coup de main, il faudrait que je prenne des notes sur les modifs de ma machine, ça m'éviterai de faire des bourdes.  :Rolling Eyes: 

----------

## scherz0

 :Shocked:  Tu n'as pas vérifié le FS avant de monter ?  sdd1 ayant été abimé, il fallait créer la matrice avec le 4ème emplacement "vide".  Puis l'ajouter, mais plus tard...

Je ne peux pas exclure que ton FS soit très corrompu...Last edited by scherz0 on Fri Feb 20, 2009 11:28 am; edited 1 time in total

----------

## manu.acl

Le FS est bon, je pense plutôt à une autre fausse manip de ma part quant à son statut.  :Rolling Eyes: 

----------

## scherz0

Effectivement, la reconstuction va se faire exclusivement vers sdd1.  Mais à ta place je crois que j'aurais été un peu plus prudent  :Smile: 

Quand tu auras la certitude d'avoir tout récupéré, tu pourras éditer ce sujet et y indiquer (résolu)  :Wink: 

----------

## manu.acl

 *scherz0 wrote:*   

> Effectivement, la reconstuction va se faire exclusivement vers sdd1.  Mais à ta place je crois que j'aurais été un peu plus prudent 
> 
> Quand tu auras la certitude d'avoir tout récupéré, tu pourras éditer ce sujet et y indiquer (résolu) 

 J'attends la fin de la reconstruction et je fais ça.  :Wink: 

----------

## anigel

 *scherz0 wrote:*   

> Anigel, désolé pour mon intervention un peu brutale mais quand j'ai lu ça
> 
>  *Quote:*   A ce stade, tu dois pouvoir utiliser ton RAID-5 en mode dégradé 
> 
> je craignais que Manu imagine que tout allait être réglé en 2 minutes et fasse des manipulations irréversibles.  En tant que n00b je dois insister lourdement pour tenter d'être convaincant .

 

Pour un "n00b" comme tu dis, tu en connais un rayon  :Wink: . Et on est toujours le n00b de quelqu'un d'autre, donc je me méfie. Et j'ai bien fait, puisque manifestement je me suis mélangé les pinceaux sur ma première explication, claire comme du jus de chaussette (en suivant les liens donnés plus haut j'ai lu les pages que manu avait consulté, il y est question de LVM, et j'en ai ensuite parlé alors que ça n'a rien à voir avec le problème). Mais je manque de sommeil ces derniers temps, alors je déraille plus facilement  :Wink: .

 *scherz0 wrote:*   

>  *Quote:*   mdadm -C ne fait que re-créer les descripteurs de device, et enregistrer la composition du RAID sur le disque. 
> 
> En faisant ça, il a perdu ses métadonnées originales, et accessoirement dézingué sdd1 puisque par défaut, ça active la matrice et démarre la synchro...  Ça fait beaucoup d'écritures pour une commande qui "ne touche pas au contenu des disques".  Je serais curieux de voir le forum en question, parce que ça me parait sidérant qu'on puisse conseiller ça sans indiquer qu'il faut d'abord sauvegarder les métadonnées.

 

J'aurais dû directement lui conseiller de faire une reconstruction de sa grappe avec un "missing" au lieu de sdd1, ça aurait été plus clair, pour la même prise de risques et un résultat similaire ou plus rapide, tu as raison. Mais au fond on ne risquait pas grand-chose avec sdd1, puisqu'il ne contenait rien de cohérent vis-à-vis de la grappe RAID.

 *manu.acl wrote:*   

> Merci pour le coup de main, il faudrait que je prenne des notes sur les modifs de ma machine, ça m'éviterai de faire des bourdes. 

 

Bon réflexe  :Wink: .

 *manu.acl wrote:*   

> J'attends la fin de la reconstruction et je fais ça. 

 

Alors ?

----------

## manu.acl

 *anigel wrote:*   

>  *manu.acl wrote:*   J'attends la fin de la reconstruction et je fais ça.  
> 
> Alors ?

 Alors ça marche.  :Wink: 

Mais je me bats avec samba maintenant... même avec la même config de l'ancien serveur je n'arrive pas à me connecter depuis windows.

Alors qu'avec smbclient depuis le serveur même ça marche très bien.  :Confused: 

[edit]

héhé, j'avais pas monté md0.  :Laughing: 

Je suis grave des fois...

----------

