Récupérer les données RAID 5 après créé un nouveau tableau au lieu de réutiliser

Question

Les gens s'il vous plaît aider - je suis un nouveaub avec un mal de tête majeur à portée de main (situation parfaite de tempête).

J'ai un disque dur de 3 1 To sur mon Ubuntu 11.04 configuré en tant que logiciel RAID 5. Les données avaient été copiées chaque semaine sur un autre disque dur distinct du disque dur de l'ordinateur jusqu'à ce que cela ait complètement échoué et a été jeté. Quelques jours de retour, nous avons eu une panne de courant et après le redémarrage de ma boîte ne monte pas le raid. Dans ma sagesse infinie, j'ai entré

mdadm --create -f...

commande au lieu de

mdadm --assemble

et n'a pas remarqué la parodie que j'avais fait jusqu'à après. Il a commencé le tableau dégradé et procédé à la construction et la synchronisation qui a pris environ 10 heures. Après que j'étais de retour, j'ai vu que le tableau est en marche avec succès, mais le raid n'est pas

Je veux dire que les disques individuels sont partitionnés (type de partition f8 ) mais le md0 L'appareil n'est pas. Réalisant dans l'horreur Ce que j'ai fait, j'essaie de trouver des solutions. Je viens de prier pour que --create n'a pas écrasé de tout le contenu du pilote dur.

Quelqu'un pourrait-il m'aider avec ceci - les données qui se trouvent sur le lecteur est très importante et unique ~ 10 ans de photos, docs, etc.

Est-il possible que, en spécifiant les disques durs participants dans un mauvais ordre, peut faire mdadm écrasez-vous? quand je fais

mdadm --examine --scan

Je reçois quelque chose comme ARRAY /dev/md/0 metadata=1.2 UUID=f1b4084a:720b5712:6d03b9e9:43afe51b name=<hostname>:0

Fait intéressant assez de nom utilisé pour être 'raid "et non l'hôte Hame avec: 0 annexé.

Voici les entrées de configuration "désinfectées":

DEVICE /dev/sdf1 /dev/sde1 /dev/sdd1 CREATE owner=root group=disk mode=0660 auto=yes HOMEHOST <system> MAILADDR root ARRAY /dev/md0 metadata=1.2 name=tanserv:0 UUID=f1b4084a:720b5712:6d03b9e9:43afe51b Here is the output from mdstat cat /proc/mdstat Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] md0 : active raid5 sdd1[0] sdf1[3] sde1[1] 1953517568 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU] unused devices: <none> fdisk shows the following: fdisk -l Disk /dev/sda: 80.0 GB, 80026361856 bytes 255 heads, 63 sectors/track, 9729 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x000bf62e Device Boot Start End Blocks Id System /dev/sda1 * 1 9443 75846656 83 Linux /dev/sda2 9443 9730 2301953 5 Extended /dev/sda5 9443 9730 2301952 82 Linux swap / Solaris Disk /dev/sdb: 750.2 GB, 750156374016 bytes 255 heads, 63 sectors/track, 91201 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x000de8dd Device Boot Start End Blocks Id System /dev/sdb1 1 91201 732572001 8e Linux LVM Disk /dev/sdc: 500.1 GB, 500107862016 bytes 255 heads, 63 sectors/track, 60801 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x00056a17 Device Boot Start End Blocks Id System /dev/sdc1 1 60801 488384001 8e Linux LVM Disk /dev/sdd: 1000.2 GB, 1000204886016 bytes 255 heads, 63 sectors/track, 121601 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x000ca948 Device Boot Start End Blocks Id System /dev/sdd1 1 121601 976760001 fd Linux raid autodetect Disk /dev/dm-0: 1250.3 GB, 1250254913536 bytes 255 heads, 63 sectors/track, 152001 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x00000000 Disk /dev/dm-0 doesn't contain a valid partition table Disk /dev/sde: 1000.2 GB, 1000204886016 bytes 255 heads, 63 sectors/track, 121601 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x93a66687 Device Boot Start End Blocks Id System /dev/sde1 1 121601 976760001 fd Linux raid autodetect Disk /dev/sdf: 1000.2 GB, 1000204886016 bytes 255 heads, 63 sectors/track, 121601 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0xe6edc059 Device Boot Start End Blocks Id System /dev/sdf1 1 121601 976760001 fd Linux raid autodetect Disk /dev/md0: 2000.4 GB, 2000401989632 bytes 2 heads, 4 sectors/track, 488379392 cylinders Units = cylinders of 8 * 512 = 4096 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 524288 bytes / 1048576 bytes Disk identifier: 0x00000000 Disk /dev/md0 doesn't contain a valid partition table

Par suggestions, j'ai nettoyé les superblocs et j'ai ré-créé le tableau avec --assume-clean option mais sans chance du tout.

Y a-t-il un outil qui m'aidera à faire revivre au moins certaines des données? Quelqu'un peut-il me dire quoi et comment le MDADM --Créate fait lorsqu'il est synchronisé pour détruire les données afin que je puisse écrire un outil pour non-faire ce qui a été fait?

Après la nouvelle création du raid i exécuté fsck.ext4/dev/md0 et voici la sortie

root @ tserv:/etc/mdadm # fsck.ext4/dev/md0 e2fsck 1.41.14 (22 déc-2010) FSCK.EXT4: Superblock invalide, des blocs de sauvegarde en essayant ... FSCK.EXT4: Numéro de mauvaise magie en super- Bloc en essayant d'ouvrir/dev/md0

Le superbloc n'a pas pu être lu ou ne décrit pas un système de fichiers ext2 correct. Si le périphérique est valide et contient réellement un système de fichiers ext2 (et non échange ou ufs ou autre chose), le superblock est corrompu et vous pouvez essayer d'exécuter E2FSCK avec un autre superbloc: E2FSCK -B 8193

La suggestion de Shanes j'ai essayé

root@tanserv:/home/mushegh# mkfs.ext4 -n /dev/md0 mke2fs 1.41.14 (22-Dec-2010) Filesystem label= OS type: Linux Block size=4096 (log=2) Fragment size=4096 (log=2) Stride=128 blocks, Stripe width=256 blocks 122101760 inodes, 488379392 blocks 24418969 blocks (5.00%) reserved for the super user First data block=0 Maximum filesystem blocks=0 14905 block groups 32768 blocks per group, 32768 fragments per group 8192 inodes per group Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968, 102400000, 214990848

et exécutez FSCK.ext4 avec chaque bloc de sauvegarde mais tous renvoyés ce qui suit:

root@tanserv:/home/mushegh# fsck.ext4 -b 214990848 /dev/md0 e2fsck 1.41.14 (22-Dec-2010) fsck.ext4: Invalid argument while trying to open /dev/md0 The superblock could not be read or does not describe a correct ext2 filesystem. If the device is valid and it really contains an ext2 filesystem (and not swap or ufs or something else), then the superblock is corrupt, and you might try running e2fsck with an alternate superblock: e2fsck -b 8193 <device>

Aucune suggestion?

Salutations!

Shane Madden · Answer

Ok - quelque chose me dérangeait de votre problème, alors j'ai tiré sur A VM pour plonger dans le comportement qui devrait être attendu. Je vais arriver à ce qui me dérangeait dans une minute; d'abord laisser Moi dites ceci:

sauvegarde ces lecteurs avant de tenter quelque chose !!

Vous avez peut-être déjà fait des dégâts au-delà de ce que le resync a fait; Pouvez-vous clarifier ce que vous vouliez dire quand vous avez dit:

Par suggestions, j'ai nettoyé les superblocs et j'ai ré-créé la matrice avec l'option --assume-Clean, mais sans chance du tout.

Si vous avez couru un mdadm --misc --zero-superblock, Ensuite ça devrait aller.

Quoi qu'il en soit, ébranler de nouveaux disques et attrapez des images actuelles exactes d'eux avant de faire quoi que ce soit de tout ce qui pourrait faire plus d'écriture à ces disques.

dd if=/dev/sdd of=/path/to/store/sdd.img

Cela étant dit .. Cela ressemble à des données stockées sur ces choses est choquante de manière choquante à des resynacots égarés. Lisez-y, il y a de l'espoir, et cela peut être le jour où je frappe la limite de longueur de réponse.

Le meilleur scénario des cas

J'ai jeté ensemble A VM= pour recréer votre scénario. Les lecteurs ne sont que de 100 Mo, donc je n'attendrais donc pas toujours à chaque resync, mais cela devrait être une représentation assez précise autrement.

Construit le tableau de manière générique et par défaut possible - 512K morceaux, la disposition gauche-symétrique, les disques de la lettre de lettre. Rien de spécial.

root@test:~# mdadm --create /dev/md0 --chunk=512 --level=5 --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1 mdadm: Defaulting to version 1.2 metadata mdadm: array /dev/md0 started. root@test:~# cat /proc/mdstat Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] md0 : active raid5 sdd1[3] sdc1[1] sdb1[0] 203776 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU] unused devices: <none>

Jusqu'ici tout va bien; Faisons un système de fichiers et mettons quelques données dessus.

root@test:~# mkfs.ext4 /dev/md0 mke2fs 1.41.14 (22-Dec-2010) Filesystem label= OS type: Linux Block size=1024 (log=0) Fragment size=1024 (log=0) Stride=512 blocks, Stripe width=1024 blocks 51000 inodes, 203776 blocks 10188 blocks (5.00%) reserved for the super user First data block=1 Maximum filesystem blocks=67371008 25 block groups 8192 blocks per group, 8192 fragments per group 2040 inodes per group Superblock backups stored on blocks: 8193, 24577, 40961, 57345, 73729 Writing inode tables: done Creating journal (4096 blocks): done Writing superblocks and filesystem accounting information: done This filesystem will be automatically checked every 30 mounts or 180 days, whichever comes first. Use tune2fs -c or -i to override. root@test:~# mkdir /mnt/raid5 root@test:~# mount /dev/md0 /mnt/raid5 root@test:~# echo "data" > /mnt/raid5/datafile root@test:~# dd if=/dev/urandom of=/mnt/raid5/randomdata count=10000 10000+0 records in 10000+0 records out 5120000 bytes (5.1 MB) copied, 0.706526 s, 7.2 MB/s root@test:~# sha1sum /mnt/raid5/randomdata 847685a5d42524e5b1d5484452a649e854b59064 /mnt/raid5/randomdata

D'accord. Nous avons un système de fichiers et des données ("données" dans datafile et 5 Mo de données aléatoires avec ce hachage SHA1 dans randomdata) dessus; Voyons ce qui se passe lorsque nous faisons une recréation.

root@test:~# umount /mnt/raid5 root@test:~# mdadm --stop /dev/md0 mdadm: stopped /dev/md0 root@test:~# cat /proc/mdstat Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] unused devices: <none> root@test:~# mdadm --create /dev/md1 --chunk=512 --level=5 --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1 mdadm: /dev/sdb1 appears to be part of a raid array: level=raid5 devices=3 ctime=Sat Jan 7 21:07:06 2012 mdadm: /dev/sdc1 appears to be part of a raid array: level=raid5 devices=3 ctime=Sat Jan 7 21:07:06 2012 mdadm: /dev/sdd1 appears to be part of a raid array: level=raid5 devices=3 ctime=Sat Jan 7 21:07:06 2012 Continue creating array? y mdadm: Defaulting to version 1.2 metadata mdadm: array /dev/md1 started. root@test:~# cat /proc/mdstat Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] md1 : active raid5 sdd1[2] sdc1[1] sdb1[0] 203776 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU] unused devices: <none>

La resynchronisation est terminée très rapidement avec ces petits disques, mais cela se produisait. Alors voici ce qui me dérangeait de plus tôt; ton fdisk -l sortir. N'ayant aucune table de partition sur le périphérique md n'est pas un problème, il est attendu. Votre système de fichiers réside directement sur le faux périphérique Block sans table de partition.

root@test:~# fdisk -l ... Disk /dev/md1: 208 MB, 208666624 bytes 2 heads, 4 sectors/track, 50944 cylinders, total 407552 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 524288 bytes / 1048576 bytes Disk identifier: 0x00000000 Disk /dev/md1 doesn't contain a valid partition table

Ouais, pas de table de partition. Mais...

root@test:~# fsck.ext4 /dev/md1 e2fsck 1.41.14 (22-Dec-2010) /dev/md1: clean, 12/51000 files, 12085/203776 blocks

Système de fichiers parfaitement valide, après une resynchronisation. C'est donc bon; Vérifions sur nos fichiers de données:

root@test:~# mount /dev/md1 /mnt/raid5/ root@test:~# cat /mnt/raid5/datafile data root@test:~# sha1sum /mnt/raid5/randomdata 847685a5d42524e5b1d5484452a649e854b59064 /mnt/raid5/randomdata

Solid - aucune corruption de données du tout! Mais ceci est avec les mêmes paramètres, donc rien n'a été cartographié différemment entre les deux groupes RAID. Laissons tomber cette chose avant d'essayer de le casser.

root@test:~# umount /mnt/raid5 root@test:~# mdadm --stop /dev/md1

Prendre un pas en arrière

Avant d'essayer de casser cela, parlons pourquoi il est difficile de casser. RAID 5 fonctionne à l'aide d'un bloc de parité qui protège une zone de la même taille que le bloc sur chaque autre disque de la matrice. La parité n'est pas uniquement sur un disque spécifique, elle est tournée autour des disques uniformément pour mieux écarter la charge de lecture sur les disques de fonctionnement normal.

Le XOR Opération pour calculer la parité ressemble à ceci:

DISK1 DISK2 DISK3 DISK4 PARITY 1 0 1 1 = 1 0 0 1 1 = 0 1 1 1 1 = 0

Donc, la parité est étendue parmi les disques.

DISK1 DISK2 DISK3 DISK4 DISK5 DATA DATA DATA DATA PARITY PARITY DATA DATA DATA DATA DATA PARITY DATA DATA DATA

Une resynchronisation est généralement faite lors du remplacement d'un disque mort ou manquant; C'est aussi fait sur mdadm create Pour vous assurer que les données sur les disques s'alignent sur ce que la géométrie du raid est censée ressembler. Dans ce cas, le dernier disque de la spécification de tableau est celui qui est "synchronisé vers" - toutes les données existantes sur les autres disques sont utilisées pour la synchronisation.

Ainsi, toutes les données sur le "nouveau" disque sont éliminées et reconstruites; Soit construire des blocs de données frais hors des blocs de parité pour ce qui aurait dû être présumé, sinon construire des blocs de parité fraîches.

Ce qui est cool, c'est que la procédure de ces deux choses est exacte la même chose: An XOR Opération sur les données du reste des disques. Le processus resynysé dans ce cas peut avoir dans sa disposition que Un certain bloc devrait être un bloc de parité et penser qu'il construit un nouveau bloc de parité, alors qu'il crée une nouvelle création d'un ancien bloc de données. Donc, même si elle pense Ça construit ceci:

DISK1 DISK2 DISK3 DISK4 DISK5 PARITY DATA DATA DATA DATA DATA PARITY DATA DATA DATA DATA DATA PARITY DATA DATA

... cela peut simplement reconstruire DISK5 de la mise en page ci-dessus.

Donc, il est possible que les données restent cohérentes, même si le tableau a mal intégré.

Jeter un singe dans les travaux

(pas une clé; tout le singe)

Test 1 :

Faisons le tableau dans le mauvais ordre! sdc, alors sdd, alors sdb ..

root@test:~# mdadm --create /dev/md1 --chunk=512 --level=5 --raid-devices=3 /dev/sdc1 /dev/sdd1 /dev/sdb1 mdadm: /dev/sdc1 appears to be part of a raid array: level=raid5 devices=3 ctime=Sat Jan 7 23:06:34 2012 mdadm: /dev/sdd1 appears to be part of a raid array: level=raid5 devices=3 ctime=Sat Jan 7 23:06:34 2012 mdadm: /dev/sdb1 appears to be part of a raid array: level=raid5 devices=3 ctime=Sat Jan 7 23:06:34 2012 Continue creating array? y mdadm: Defaulting to version 1.2 metadata mdadm: array /dev/md1 started. root@test:~# cat /proc/mdstat Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] md1 : active raid5 sdb1[3] sdd1[1] sdc1[0] 203776 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU] unused devices: <none>

Ok, c'est tout bien et bien. Avons-nous un système de fichiers?

root@test:~# fsck.ext4 /dev/md1 e2fsck 1.41.14 (22-Dec-2010) fsck.ext4: Superblock invalid, trying backup blocks... fsck.ext4: Bad magic number in super-block while trying to open /dev/md1 The superblock could not be read or does not describe a correct ext2 filesystem. If the device is valid and it really contains an ext2 filesystem (and not swap or ufs or something else), then the superblock is corrupt, and you might try running e2fsck with an alternate superblock: e2fsck -b 8193 <device>

Nan! Pourquoi donc? Parce que pendant que les données sont toutes là, c'est dans le mauvais ordre; Quelle était une fois 512 Ko d'A, puis 512kb de B, A, B, et ainsi de suite, a maintenant été mélangée à B, A, B, A. Le disque ressemble maintenant à la jibbérisation du vérificateur de fichier de fichiers, il ne s'exécutera pas. La sortie de mdadm --misc -D /dev/md1 nous donne plus de détails; Cela ressemble à ceci:

Number Major Minor RaidDevice State 0 8 33 0 active sync /dev/sdc1 1 8 49 1 active sync /dev/sdd1 3 8 17 2 active sync /dev/sdb1

Quand ça devrait ressembler à ceci:

Number Major Minor RaidDevice State 0 8 17 0 active sync /dev/sdb1 1 8 33 1 active sync /dev/sdc1 3 8 49 2 active sync /dev/sdd1

Donc, c'est tout bien et bien. Nous avons écrasé un tas de blocs de données avec de nouveaux blocs de parité cette fois-ci. Recréer, avec le bon ordre maintenant:

root@test:~# mdadm --stop /dev/md1 mdadm: stopped /dev/md1 root@test:~# mdadm --create /dev/md1 --chunk=512 --level=5 --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1 mdadm: /dev/sdb1 appears to be part of a raid array: level=raid5 devices=3 ctime=Sat Jan 7 23:11:08 2012 mdadm: /dev/sdc1 appears to be part of a raid array: level=raid5 devices=3 ctime=Sat Jan 7 23:11:08 2012 mdadm: /dev/sdd1 appears to be part of a raid array: level=raid5 devices=3 ctime=Sat Jan 7 23:11:08 2012 Continue creating array? y mdadm: Defaulting to version 1.2 metadata mdadm: array /dev/md1 started. root@test:~# fsck.ext4 /dev/md1 e2fsck 1.41.14 (22-Dec-2010) /dev/md1: clean, 12/51000 files, 12085/203776 blocks

Neat, il y a encore un système de fichiers là-bas! Toujours avoir des données?

root@test:~# mount /dev/md1 /mnt/raid5/ root@test:~# cat /mnt/raid5/datafile data root@test:~# sha1sum /mnt/raid5/randomdata 847685a5d42524e5b1d5484452a649e854b59064 /mnt/raid5/randomdata

Succès!

test 2

Ok, changeons la taille du morceau et voyons si cela nous donne une certaine démarcation.

root@test:~# umount /mnt/raid5 root@test:~# mdadm --stop /dev/md1 mdadm: stopped /dev/md1 root@test:~# mdadm --create /dev/md1 --chunk=64 --level=5 --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1 mdadm: /dev/sdb1 appears to be part of a raid array: level=raid5 devices=3 ctime=Sat Jan 7 23:21:19 2012 mdadm: /dev/sdc1 appears to be part of a raid array: level=raid5 devices=3 ctime=Sat Jan 7 23:21:19 2012 mdadm: /dev/sdd1 appears to be part of a raid array: level=raid5 devices=3 ctime=Sat Jan 7 23:21:19 2012 Continue creating array? y mdadm: Defaulting to version 1.2 metadata mdadm: array /dev/md1 started. root@test:~# fsck.ext4 /dev/md1 e2fsck 1.41.14 (22-Dec-2010) fsck.ext4: Superblock invalid, trying backup blocks... fsck.ext4: Bad magic number in super-block while trying to open /dev/md1 The superblock could not be read or does not describe a correct ext2 filesystem. If the device is valid and it really contains an ext2 filesystem (and not swap or ufs or something else), then the superblock is corrupt, and you might try running e2fsck with an alternate superblock: e2fsck -b 8193 <device>

Ouais, oui, il est aléatoire lors de la mise en place comme ça. Mais pouvons-nous récupérer?

root@test:~# mdadm --stop /dev/md1 mdadm: stopped /dev/md1 root@test:~# mdadm --create /dev/md1 --chunk=512 --level=5 --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1 mdadm: /dev/sdb1 appears to be part of a raid array: level=raid5 devices=3 ctime=Sat Jan 7 23:21:51 2012 mdadm: /dev/sdc1 appears to be part of a raid array: level=raid5 devices=3 ctime=Sat Jan 7 23:21:51 2012 mdadm: /dev/sdd1 appears to be part of a raid array: level=raid5 devices=3 ctime=Sat Jan 7 23:21:51 2012 Continue creating array? y mdadm: Defaulting to version 1.2 metadata mdadm: array /dev/md1 started. root@test:~# fsck.ext4 /dev/md1 e2fsck 1.41.14 (22-Dec-2010) /dev/md1: clean, 12/51000 files, 12085/203776 blocks root@test:~# mount /dev/md1 /mnt/raid5/ root@test:~# cat /mnt/raid5/datafile data root@test:~# sha1sum /mnt/raid5/randomdata 847685a5d42524e5b1d5484452a649e854b59064 /mnt/raid5/randomdata

Succès, encore une fois!

Test

C'est celui que j'ai pensé tuer des données à coup sûr - faisons un algorithme de mise en page différent!

root@test:~# umount /mnt/raid5 root@test:~# mdadm --stop /dev/md1 mdadm: stopped /dev/md1 root@test:~# mdadm --create /dev/md1 --chunk=512 --level=5 --layout=right-asymmetric --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1 mdadm: /dev/sdb1 appears to be part of a raid array: level=raid5 devices=3 ctime=Sat Jan 7 23:32:34 2012 mdadm: /dev/sdc1 appears to be part of a raid array: level=raid5 devices=3 ctime=Sat Jan 7 23:32:34 2012 mdadm: /dev/sdd1 appears to be part of a raid array: level=raid5 devices=3 ctime=Sat Jan 7 23:32:34 2012 Continue creating array? y mdadm: Defaulting to version 1.2 metadata mdadm: array /dev/md1 started. root@test:~# cat /proc/mdstat Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] md1 : active raid5 sdd1[3] sdc1[1] sdb1[0] 203776 blocks super 1.2 level 5, 512k chunk, algorithm 1 [3/3] [UUU] unused devices: <none> root@test:~# fsck.ext4 /dev/md1 e2fsck 1.41.14 (22-Dec-2010) fsck.ext4: Superblock invalid, trying backup blocks... Superblock has an invalid journal (inode 8).

Effrayant et mauvais - il pense qu'il a trouvé quelque chose et veut faire une solution! Ctrl+C!

Clear<y>? cancelled! fsck.ext4: Illegal inode number while checking ext3 journal for /dev/md1

OK, la crise évitée. Voyons si les données sont toujours intactes après avoir resynoncé avec la mauvaise mise en page:

root@test:~# mdadm --stop /dev/md1 mdadm: stopped /dev/md1 root@test:~# mdadm --create /dev/md1 --chunk=512 --level=5 --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1 mdadm: /dev/sdb1 appears to be part of a raid array: level=raid5 devices=3 ctime=Sat Jan 7 23:33:02 2012 mdadm: /dev/sdc1 appears to be part of a raid array: level=raid5 devices=3 ctime=Sat Jan 7 23:33:02 2012 mdadm: /dev/sdd1 appears to be part of a raid array: level=raid5 devices=3 ctime=Sat Jan 7 23:33:02 2012 Continue creating array? y mdadm: Defaulting to version 1.2 metadata mdadm: array /dev/md1 started. root@test:~# fsck.ext4 /dev/md1 e2fsck 1.41.14 (22-Dec-2010) /dev/md1: clean, 12/51000 files, 12085/203776 blocks root@test:~# mount /dev/md1 /mnt/raid5/ root@test:~# cat /mnt/raid5/datafile data root@test:~# sha1sum /mnt/raid5/randomdata 847685a5d42524e5b1d5484452a649e854b59064 /mnt/raid5/randomdata

Succès!

test 4

Prouvons-nous également que ce superblock zeroing n'est pas très préjudiciable rapidement:

root@test:~# umount /mnt/raid5 root@test:~# mdadm --stop /dev/md1 mdadm: stopped /dev/md1 root@test:~# mdadm --misc --zero-superblock /dev/sdb1 /dev/sdc1 /dev/sdd1 root@test:~# mdadm --create /dev/md1 --chunk=512 --level=5 --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1 mdadm: Defaulting to version 1.2 metadata mdadm: array /dev/md1 started. root@test:~# fsck.ext4 /dev/md1 e2fsck 1.41.14 (22-Dec-2010) /dev/md1: clean, 12/51000 files, 12085/203776 blocks root@test:~# mount /dev/md1 /mnt/raid5/ root@test:~# cat /mnt/raid5/datafile data root@test:~# sha1sum /mnt/raid5/randomdata 847685a5d42524e5b1d5484452a649e854b59064 /mnt/raid5/randomdata

Oui, pas de gros problème.

test 5

Jetons tout ce que nous avons à cela. Tous les 4 tests précédents, combinés.

Ordre de périphérique incorrect
Mauvaise taille de morceau
Mauvais algorithme de mise en page
Superblocks à zéro (nous ferons cela entre les deux créations)

En avant!

root@test:~# umount /mnt/raid5 root@test:~# mdadm --stop /dev/md1 mdadm: stopped /dev/md1 root@test:~# mdadm --misc --zero-superblock /dev/sdb1 /dev/sdc1 /dev/sdd1 root@test:~# mdadm --create /dev/md1 --chunk=64 --level=5 --raid-devices=3 --layout=right-symmetric /dev/sdc1 /dev/sdd1 /dev/sdb1 mdadm: Defaulting to version 1.2 metadata mdadm: array /dev/md1 started. root@test:~# cat /proc/mdstat Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] md1 : active raid5 sdb1[3] sdd1[1] sdc1[0] 204672 blocks super 1.2 level 5, 64k chunk, algorithm 3 [3/3] [UUU] unused devices: <none> root@test:~# fsck.ext4 /dev/md1 e2fsck 1.41.14 (22-Dec-2010) fsck.ext4: Superblock invalid, trying backup blocks... fsck.ext4: Bad magic number in super-block while trying to open /dev/md1 The superblock could not be read or does not describe a correct ext2 filesystem. If the device is valid and it really contains an ext2 filesystem (and not swap or ufs or something else), then the superblock is corrupt, and you might try running e2fsck with an alternate superblock: e2fsck -b 8193 <device> root@test:~# mdadm --stop /dev/md1 mdadm: stopped /dev/md1

Le verdict?

root@test:~# mdadm --misc --zero-superblock /dev/sdb1 /dev/sdc1 /dev/sdd1 root@test:~# mdadm --create /dev/md1 --chunk=512 --level=5 --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1 mdadm: Defaulting to version 1.2 metadata mdadm: array /dev/md1 started. root@test:~# cat /proc/mdstat Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] md1 : active raid5 sdd1[3] sdc1[1] sdb1[0] 203776 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU] unused devices: <none> root@test:~# fsck.ext4 /dev/md1 e2fsck 1.41.14 (22-Dec-2010) /dev/md1: clean, 13/51000 files, 17085/203776 blocks root@test:~# mount /dev/md1 /mnt/raid5/ root@test:~# cat /mnt/raid5/datafile data root@test:~# sha1sum /mnt/raid5/randomdata 847685a5d42524e5b1d5484452a649e854b59064 /mnt/raid5/randomdata

Wow.

Donc, il semble que aucune de ces actions n'a corrompu des données de quelque manière que ce soit. Cela a été assez surpris par ce résultat, franchement; Je m'attendais à des changements modétaires de perte de données sur le changement de taille des morceaux et une perte définitive sur le changement de mise en page. J'ai appris quelque chose aujourd'hui.

Alors .. Comment puis-je obtenir mes données ??

Autant d'informations que vous avez sur l'ancien système vous seraient extrêmement utiles. Si vous connaissez le type de système de fichiers, si vous avez d'anciennes copies de votre /proc/mdstat Avec des informations sur la commande de conduite, l'algorithme, la taille des morceaux et la version de métadonnées. Avez-vous des alertes par e-mail de Mdadm mis en place? Si oui, trouvez un ancien; Sinon, vérifiez /var/spool/mail/root. Vérifier votre ~/.bash_history Pour voir si votre construction originale est là.

Donc, la liste des choses que vous devriez faire:

( sauvegarder les disques avec dd avant de faire quoi que ce soit !!
Essayez de fsck Le MD actuel et actif - Vous pourriez peut-être construire dans le même ordre qu'auparavant. Si vous connaissez le type de système de fichiers, c'est utile; Utilisez cet outil spécifique fsck. Si l'un des outils offre quelque chose pour résoudre tout, ne les laissez pas sauf si vous êtes sûr d'avoir trouvé le système de fichiers valide! Si un fsck propose de réparer quelque chose pour vous, n'hésitez pas à laisser un commentaire à demander s'il vous aide ou à peu près aux données NUKE.
Essayez de construire le tableau avec différents paramètres. Si vous avez un vieux /proc/mdstat, alors vous pouvez simplement imiter ce qu'il montre; Sinon, alors vous êtes un peu dans l'obscurité - essayer toutes les différentes commandes d'entraînement sont raisonnables, mais la vérification de chaque taille possible avec chaque ordre possible est futile. Pour chacun, fsck cela pour voir si vous obtenez quelque chose de prometteur.

Donc, c'est ça. Désolé pour le roman, n'hésitez pas à laisser un commentaire si vous avez des questions, et bonne chance!

Note de bas de page: moins de 22 000 caractères; 8K + timide de la limite de longueur

Anton Stolbunov · Answer

J'avais un problème similaire:
[.____] après une défaillance d'un réseau RAID5 logiciel, j'ai tiré mdadm --create sans le donner --assume-clean, et ne pouviez plus monter le tableau. Après deux semaines de creusage, j'ai finalement restauré toutes les données. J'espère que la procédure ci-dessous sauvera le temps de quelqu'un.

Longue histoire courte

Le problème a été causé par le fait que mdadm --create fait un nouveau tableau différent de l'original sur deux aspects:

différent ordre de partitions
dIFFÉRENT DES DONNÉES DE DONNÉES DE RAID

Comme il a été montré dans la brillante réponse de Shane Madden , mdadm --create ne détruit pas les données dans la plupart des cas! Après avoir trouvé l'ordre de partition et le décalage des données, je pourrais restaurer le tableau et extraire toutes les données de celle-ci.

Conditions préalables

Je n'avais aucune sauvegarde des superblocages Raid, alors tout ce que je savais, c'est que c'était un tableau RAID5 sur 8 partitions créées lors de l'installation de Xubuntu 12.04.0. Il avait un système de fichiers ext4. Un autre élément de connaissances important était une copie d'un fichier qui a également été stocké sur le tableau RAID.

Outils

Xubuntu 12.04.1 Live CD a été utilisé pour faire tout le travail. En fonction de votre situation, vous pourriez avoir besoin de certains des outils suivants:

version de Mdadm qui permet de spécifier le décalage de données

Sudo apt-get install binutils-dev git git clone -b data_offset git://neil.brown.name/mdadm cd mdadm make

BGREP - Recherche de données binaires

curl -L 'https://github.com/tmbinc/bgrep/raw/master/bgrep.c' | gcc -O2 -x c -o bgrep -

hexdump, e2fsck, montage et une calculatrice hexadécimale - Outils standard de Repos

Commencez par la sauvegarde complète

Nommage des fichiers de périphérique, par ex. /dev/sda2 /dev/sdb2 etc., n'est pas persistant, il est donc préférable d'écrire les numéros de série de vos entraînements donnés par

Sudo hdparm -I /dev/sda

Puis connectez-vous un disque dur externe et sauvegardez chaque partition de votre tableau RAID comme celui-ci:

Sudo dd if=/dev/sda2 bs=4M | gzip > serial-number.gz

Déterminer la mise en page d'origine RAID5

Diverses mises en page sont décrites ici: http://www.accs.com/p_and_p/raid/linuxraid.html
[.____] Pour déterminer la manière dont les bandes de données ont été organisées sur la matrice d'origine, vous avez besoin d'une copie d'un fichier à la recherche aléatoire que vous connaissez a été stockée sur le tableau. La taille du morceau par défaut actuellement utilisée par mdadm est de 512 Ko. Pour un tableau de n partitions, vous avez besoin d'un fichier de taille au moins (N + 1) * 512 Ko. Une JPEG ou une vidéo est bonne car elle fournit des substrings relativement uniques de données binaires. Supposons que notre fichier s'appelle picture.jpg. Nous lisons 32 octets de données à N + 1 postes à partir de 100 000 et incrémentation de 512K:

hexdump -n32 -s100k -v -e '/1 "%02X"' picture.jpg ; echo DA1DC4D616B1C71079624CDC36E3D40E7B1CFF00857C663687B6C4464D6C77D2 hexdump -n32 -s612k -v -e '/1 "%02X"' picture.jpg ; echo AB9DDDBBB05CA915EE2289E59A116B02A26C82C8A8033DD8FA6D06A84B6501B7 hexdump -n32 -s1124k -v -e '/1 "%02X"' picture.jpg ; echo BC31A8DC791ACDA4FA3E9D3406D5639619576AEE2E08C03C9EF5E23F0A7C5CBA ...

Nous recherchons ensuite des occurrences de toutes ces partes sur toutes nos partitions brutes, donc au total (N + 1) * N commandes, comme ceci:

Sudo ./bgrep DA1DC4D616B1C71079624CDC36E3D40E7B1CFF00857C663687B6C4464D6C77D2 /dev/sda2 Sudo ./bgrep DA1DC4D616B1C71079624CDC36E3D40E7B1CFF00857C663687B6C4464D6C77D2 /dev/sdb2 ... Sudo ./bgrep DA1DC4D616B1C71079624CDC36E3D40E7B1CFF00857C663687B6C4464D6C77D2 /dev/sdh2 /dev/sdh2: 52a7ff000 Sudo ./bgrep AB9DDDBBB05CA915EE2289E59A116B02A26C82C8A8033DD8FA6D06A84B6501B7 /dev/sda2 /dev/sdb2: 52a87f000 ...

Ces commandes peuvent être exécutées en parallèle pour différents disques. Le balayage d'une partition de 38 Go a pris environ 12 minutes. Dans mon cas, chaque chaîne de 32 octets n'a été trouvée qu'une fois parmi les huit disques. En comparant les décalages retournés par BGREP, vous obtenez une photo comme celle-ci:

| offset \ partition | b | d | c | e | f | g | a | h | |--------------------+---+---+---+---+---+---+---+---| | 52a7ff000 | P | | | | | | | 1 | | 52a87f000 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | P | | 52a8ff000 | | | | | | | P | 9 |

Nous voyons un fichier normal gaucher-symétrique Layout, qui est par défaut pour mdadm. Plus important encore, nous connaissons maintenant l'ordre des partitions. Cependant, nous ne savons pas quelle partition est la première dans le tableau, car elles peuvent être changées cycliques.

Notez également la distance entre les décalages trouvés. Dans mon cas, il était 512 Ko. La taille du morceau peut réellement être plus petite que cette distance, auquel cas la mise en page réelle sera différente.

Trouver la taille des morceaux d'origine

Nous utilisons le même fichier picture.jpg Pour lire 32 octets de données à différents intervalles les uns des autres. Nous savons d'au-dessus que les données à compensation 100k mentent sur /dev/sdh2, au décalage 612k est à /dev/sdb2, et à 1124k est à /dev/sdd2. Cela montre que la taille du morceau n'est pas supérieure à 512 Ko. Nous vérifions qu'il n'est pas inférieur à 512 Ko. Pour cela, nous renversons le bytretring à 356K offset et regardez sur quelle partition il est assis:

hexdump -n32 -s356k -v -e '/1 "%02X"' P1080801.JPG ; echo 7EC528AD0A8D3E485AE450F88E56D6AEB948FED7E679B04091B031705B6AFA7A Sudo ./bgrep 7EC528AD0A8D3E485AE450F88E56D6AEB948FED7E679B04091B031705B6AFA7A /dev/sdb2 /dev/sdb2: 52a83f000

Il est sur la même partition que compensée 612K, ce qui indique que la taille du morceau n'est pas de 256 Ko. Nous éliminons des tailles de morceaux plus petites de la manière similaire. J'ai fini avec 512kb morceaux étant la seule possibilité.

Trouver la première partition dans la mise en page

Maintenant, nous connaissons l'ordre des partitions, mais nous ne savons pas quelle partition devrait être la première et que le décalage de données RAID a été utilisé. Pour trouver ces deux inconnues, nous créerons un tableau RAID5 avec une mise en page correcte des chunk et un petit décalage de données, et recherchez le démarrage de notre système de fichiers dans ce nouveau tableau.

Pour commencer, nous créons un tableau avec le bon ordre des partitions, que nous avons trouvées précédemment:

Sudo mdadm --stop /dev/md126 Sudo mdadm --create /dev/md126 --assume-clean --raid-devices=8 --level=5 /dev/sdb2 /dev/sdd2 /dev/sdc2 /dev/sde2 /dev/sdf2 /dev/sdg2 /dev/sda2 /dev/sdh2

Nous vérifions que l'ordre est obéi en émettant

Sudo mdadm --misc -D /dev/md126 ... Number Major Minor RaidDevice State 0 8 18 0 active sync /dev/sdb2 1 8 50 1 active sync /dev/sdd2 2 8 34 2 active sync /dev/sdc2 3 8 66 3 active sync /dev/sde2 4 8 82 4 active sync /dev/sdf2 5 8 98 5 active sync /dev/sdg2 6 8 2 6 active sync /dev/sda2 7 8 114 7 active sync /dev/sdh2

Maintenant, nous déterminons que nous déterminons les compensations des byters connus n + 1 dans le tableau RAID. Je gère un script pendant une nuit (Live CD ne demande pas de mot de passe sur sudo :):

#!/bin/bash echo "1st:" Sudo ./bgrep DA1DC4D616B1C71079624CDC36E3D40E7B1CFF00857C663687B6C4464D6C77D2 /dev/md126 echo "2nd:" Sudo ./bgrep AB9DDDBBB05CA915EE2289E59A116B02A26C82C8A8033DD8FA6D06A84B6501B7 /dev/md126 echo "3rd:" Sudo ./bgrep BC31A8DC791ACDA4FA3E9D3406D5639619576AEE2E08C03C9EF5E23F0A7C5CBA /dev/md126 ... echo "9th:" Sudo ./bgrep 99B5A96F21BB74D4A630C519B463954EC096E062B0F5E325FE8D731C6D1B4D37 /dev/md126

Sortie avec commentaires:

1st: /dev/md126: 2428fff000 # 1st 2nd: /dev/md126: 242947f000 # 480000 after 1st 3rd: # 3rd not found 4th: /dev/md126: 242917f000 # 180000 after 1st 5th: /dev/md126: 24291ff000 # 200000 after 1st 6th: /dev/md126: 242927f000 # 280000 after 1st 7th: /dev/md126: 24292ff000 # 300000 after 1st 8th: /dev/md126: 242937f000 # 380000 after 1st 9th: /dev/md126: 24297ff000 # 800000 after 1st

Sur la base de ces données, nous voyons que la 3ème chaîne n'a pas été trouvée. Cela signifie que le morceau à /dev/sdd2 est utilisé pour la parité. Voici une illustration des positions de parité dans le nouveau tableau:

| offset \ partition | b | d | c | e | f | g | a | h | |--------------------+---+---+---+---+---+---+---+---| | 52a7ff000 | | | P | | | | | 1 | | 52a87f000 | 2 | P | 4 | 5 | 6 | 7 | 8 | | | 52a8ff000 | P | | | | | | | 9 |

Notre objectif est de déduire la partition de démarrer la matrice, afin de déplacer les morceaux de parité au bon endroit. Puisque la parité doit être déplacée deux morceaux vers la gauche, la séquence de partition doit être déplacée deux étapes à droite. Ainsi, la mise en page correcte pour ce décalage de données est ahbdcefg:

Sudo mdadm --stop /dev/md126 Sudo mdadm --create /dev/md126 --assume-clean --raid-devices=8 --level=5 /dev/sda2 /dev/sdh2 /dev/sdb2 /dev/sdd2 /dev/sdc2 /dev/sde2 /dev/sdf2 /dev/sdg2

À ce stade, notre tableau RAID contient des données sur la bonne forme. Vous pourriez avoir de la chance de sorte que le décalage des données RAID soit identique à celui de la matrice d'origine, puis vous serez probablement en mesure de monter la partition. Malheureusement, ce n'était pas mon cas.

Vérifier la cohérence des données

Nous vérifions que les données sont cohérentes sur une bande de morceaux en extrayant une copie de picture.jpg de la matrice. Pour cela, nous localisons le décalage de la chaîne de 32 octets à 100k:

Sudo ./bgrep DA1DC4D616B1C71079624CDC36E3D40E7B1CFF00857C663687B6C4464D6C77D2 /dev/md126

Nous ajoutons ensuite 100 * 1024 à partir du résultat et utilisons la valeur décimale obtenue dans skip= Paramètre pour dd. Les count= est la taille de picture.jpg en octets:

Sudo dd if=/dev/md126 of=./extract.jpg bs=1 skip=155311300608 count=4536208

Regarde ça extract.jpg est le même que picture.jpg.

Trouver un décalage de données RAID

A Sidenote: Décalage de données par défaut pour mdadm version 3.2.3 est 2048 secteurs. Mais cette valeur a été changée au fil du temps. Si le tableau d'origine utilisait un décalage de données plus petit que votre courant mdadm, alors mdadm --create sans pour autant --assume-clean peut écraser le début du système de fichiers.

Dans la section précédente, nous avons créé un tableau RAID. Vérifiez que les données RAID compensent-elles en émettant certaines des partitions individuelles:

Sudo mdadm --examine /dev/sdb2 ... Data Offset : 2048 sectors ...

Les secteurs 2048 512 octets sont de 1 Mo. Étant donné que la taille du morceau est de 512 Ko, le décalage actuel des données est de deux morceaux.

Si, à ce stade, vous avez un décalage de deux morceaux, il est probablement assez petit et vous pouvez ignorer ce paragraphe.
[.____] Nous créons un tableau RAID5 avec le décalage de données d'un 512 Ko-Chunk. Démarrer un morceau plus tôt passe la parité Une étape à gauche, nous compensons donc en déplaçant la séquence de partition une étape vers la gauche. Par conséquent, pour un décalage de données de 512kb, la mise en page correcte est hbdcefga. Nous utilisons une version de mdadm qui prend en charge le décalage des données (voir la section Outils). Il faut compenser en kilo-octets:

Sudo mdadm --stop /dev/md126 Sudo ./mdadm --create /dev/md126 --assume-clean --raid-devices=8 --level=5 /dev/sdh2:512 /dev/sdb2:512 /dev/sdd2:512 /dev/sdc2:512 /dev/sde2:512 /dev/sdf2:512 /dev/sdg2:512 /dev/sda2:512

Nous recherchons maintenant un superbloc ext4 valide. La structure Superblock peut être trouvée ici: https://ext4.wiki.kernel.org/index.php/ext4_disk_layout#the_super_block
[.____] Nous analysons le début de la matrice pour des occurrences de la magie s_magic suivie par s_state et s_errors. Les partes à rechercher sont:

53EF01000100 53EF00000100 53EF02000100 53EF01000200 53EF02000200

Exemple de commande:

Sudo ./bgrep 53EF01000100 /dev/md126 /dev/md126: 0dc80438

Le numéro magique commence 0x38 octets dans le Superblock, nous allons donc soustrayer 0x38 pour calculer le décalage et examiner l'ensemble du superbloc:

Sudo hexdump -n84 -s0xDC80400 -v /dev/md126 dc80400 2000 00fe 1480 03f8 cdd3 0032 d2b2 0119 dc80410 ab16 00f7 0000 0000 0002 0000 0002 0000 dc80420 8000 0000 8000 0000 2000 0000 b363 51bd dc80430 e406 5170 010d ffff ef53 0001 0001 0000 dc80440 3d3a 50af 0000 0000 0000 0000 0001 0000 dc80450 0000 0000

Cela semble être un superbloc valide. s_log_block_size Champ à 0x18 est 0002, ce qui signifie que la taille du bloc est 2 ^ (10 + 2) = 4096 octets. s_blocks_count_lo à 0x4 est 03f81480 blocs de 254 Go. Cela semble bon.

Nous numérisons maintenant pour les occurrences des premiers octets du Superblock pour trouver ses copies. Notez que le retournement des octets par rapport à la sortie HexDump:

Sudo ./bgrep 0020fe008014f803d3cd3200 /dev/md126 /dev/md126: 0dc80400 # offset by 1024 bytes from the start of the FS /dev/md126: 15c80000 # 32768 blocks from FS start /dev/md126: 25c80000 # 98304 /dev/md126: 35c80000 # 163840 /dev/md126: 45c80000 # 229376 /dev/md126: 55c80000 # 294912 /dev/md126: d5c80000 # 819200 /dev/md126: e5c80000 # 884736 /dev/md126: 195c80000 /dev/md126: 295c80000

Cela aligne parfaitement les positions attendues des superblocages de sauvegarde:

Sudo mke2fs -n /dev/md126 ... Block size=4096 (log=2) ... Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 4096000, 7962624, 11239424, 20480000, 23887872

Par conséquent, le système de fichiers commence au décalage 0xDC80000, c'est-à-dire 225792KB à partir du début de la partition. Depuis que nous avons 8 partitions dont l'une est pour la parité, nous divisons le décalage par 7. Cela donne 33030144 octets offset sur chaque partition, ce qui correspond exactement à 63 morceaux de raid. Et comme le décalage actuel de données RAID est un seul morceau, nous concluons que le décalage de données d'origine était de 64 morceaux, soit 32768KB. Shifting hbdcefga 63 fois à droite donne la mise en page bdcefgah.

Nous construisons enfin le bon tableau RAID:

Sudo mdadm --stop /dev/md126 Sudo ./mdadm --create /dev/md126 --assume-clean --raid-devices=8 --level=5 /dev/sdb2:32768 /dev/sdd2:32768 /dev/sdc2:32768 /dev/sde2:32768 /dev/sdf2:32768 /dev/sdg2:32768 /dev/sda2:32768 /dev/sdh2:32768 Sudo fsck.ext4 -n /dev/md126 e2fsck 1.42 (29-Nov-2011) Warning: skipping journal recovery because doing a read-only filesystem check. /dev/md126: clean, 423146/16654336 files, 48120270/66589824 blocks Sudo mount -t ext4 -r /dev/md126 /home/xubuntu/mp

VOILÀ!

Mark Henderson · Answer

Si vous êtes chanceux Vous avez peut-être un certain succès avec vos fichiers avec le logiciel de récupération pouvant lire un tableau RAID-5 cassé. Récupération zéro Assomption est une fois que j'ai eu du succès avec avant.

Cependant, je ne suis pas sûr que le processus de création d'une nouvelle matrice ait disparu et détruit toutes les données, cela pourrait donc être un effort de chance.

SideShow Bob · Answer

J'ai eu un problème similaire. J'ai formaté et réinstallé mon système d'exploitation/démarrage avec une installation propre de Ubuntu 12.04, puis dirigez-vous la commande Mdadm --Create ... et ne pouviez pas la monter.

Il a dit qu'il n'avait pas de superbloc ou de partition valide.

De plus, lorsque j'ai arrêté le raid Mdadm, je ne pouvais plus monter le dispositif régulier.

J'ai pu réparer le superbloc avec MKE2FS et E2FSCK:

root@blackbox:~# mke2fs -n /dev/sdc1 mke2fs 1.42 (29-Nov-2011) Filesystem label= OS type: Linux Block size=4096 (log=2) Fragment size=4096 (log=2) Stride=0 blocks, Stripe width=0 blocks 91578368 inodes, 366284000 blocks 18314200 blocks (5.00%) reserved for the super user First data block=0 Maximum filesystem blocks=4294967296 11179 block groups 32768 blocks per group, 32768 fragments per group 8192 inodes per group Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968, 102400000, 214990848

Puis couru:

e2fsck -b 32768 -y /dev/sdc1

Cela restauré le Superblock pour que je puisse me monter et lire le lecteur.

Pour obtenir le tableau Travailler sans détruire le superbloc ou les partitions que j'ai utilisé construire:

mdadm --build /dev/md0 --level=mirror --assume-clean --raid-devices=2 /dev/sdc1 missing

Après avoir vérifié les données, j'ajouterai l'autre lecteur:

mdadm --add /dev/md0 /sdd1

rd.olivaw · Answer

Je viens de mettre à jour certaines des informations données précédemment. J'ai eu un tableau RAID5 à 3 disques fonctionnant bien lorsque ma carte mère est morte. Le tableau tenu/dev/md2 en tant que partition/home Partition 1.2TB et/dev/md3 en tant que partition/var partition de 300 Go.

J'avais deux sauvegardes de choses "importantes" et un tas de choses aléatoires que j'avais attrapées de différentes parties d'Internet que j'ai vraiment dû passer à travers et que je suis écarté de manière sélective. La plupart des sauvegardes ont été divisées en fichiers .TAR.GZ de 25 Go ou moins, et une copie séparée de/etc. a également été sauvegardée.

Le reste du système de fichiers a eu lieu sur deux petits disques RAID0 de 38 Go.

Ma nouvelle machine était semblable à celle du vieux matériel et j'ai eu la machine et couru simplement en branchant les cinq disques dans et en sélectionnant un vieux noyau générique. Donc, j'avais cinq disques avec des systèmes de fichiers propres, même si je ne pouvais pas être certain que les disques étaient dans le bon ordre et que je devais installer une nouvelle version de Debian Jessie pour être sûr que je pouvais mettre à niveau la machine en cas de besoin et trier les autres problèmes.

Avec le nouveau système générique installé sur deux disques RAID0, j'ai commencé à remettre les matrices ensemble. Je voulais être sûr d'avoir eu les disques dans le bon ordre. Ce que j'aurais dû faire était de délivrer:

mdadm --assemble /dev/md3 -o --no-degraded --uuid=82164ae7:9af3c5f1:f75f70a5:ba2a159a

Mais je n'ai pas fait. Il semble que Mdadm soit assez intelligent et donné une UUID, peut déterminer quelles entraînements vont où aller. Même si le BIOS désigne/Dev/SDC AS/SDA, MDADM le placera correctement (YMMV).

Au lieu de cela, j'ai émis: mdadm --create /dev/md2 without the --assume-clean, et autorisé la resynchronisation sur/dev/sde1 à compléter. La prochaine erreur que j'ai faite était de travailler sur/dev/sdc1 au lieu du dernier lecteur dans le/dev/md2,/sde1. À tout moment, Mdadm pense qu'il y a un problème c'est le dernier lecteur qui se fait expulser ou ré-synchronisé.

Après cela, Mdadm n'a pas pu trouver de superbloc, et E2FSCK -N ne pouvait pas non plus.

Après avoir trouvé cette page, j'ai traversé la procédure d'essayer de trouver la séquence pour les lecteurs (faites), recherchez des données valides (vérifiées 6 Mo d'un fichier de 9 Mo), obtenez les disques de la séquence droite, CDE, a saisi les UUID de/md2 et/md3 de l'ancien /etc/mdadm.conf et a essayé l'assemblage.

Bien, /dev/md3 a commencé et mdadm --misc -D /dev/md3 a montré trois partitions saines et les disques du bon ordre. /dev/md2 aussi semblait bien, jusqu'à ce que j'essaye de monter le système de fichiers.

# mdadm --create /dev/md2 --raid-devices=3 --level=5 --uuid=c0a644c7:e5bcf758:ecfbc8f3:ee0392b7 /dev/sdc1 /dev/sdd1 /dev/sde1 mdadm: /dev/sdc1 appears to be part of a raid array: level=raid5 devices=3 ctime=Wed Feb 3 14:05:36 2016 mdadm: /dev/sdd1 appears to contain an ext2fs file system size=585936896K mtime=Thu Jan 1 01:00:00 1970 mdadm: /dev/sdd1 appears to be part of a raid array: level=raid5 devices=3 ctime=Wed Feb 3 14:05:36 2016 mdadm: /dev/sde1 appears to contain an ext2fs file system size=585936896K mtime=Thu Jan 1 01:00:00 1970 mdadm: /dev/sde1 appears to be part of a raid array: level=raid5 devices=3 ctime=Wed Feb 3 14:05:36 2016 Continue creating array? y mdadm: Defaulting to version 1.2 metadata mdadm: array /dev/md2 started.

Le système de fichiers a refusé d'être monté et E2FSCK n'a pas pu trouver de superblocages. En outre, lors de la vérification des superblocages comme décrit ci-dessus, le nombre total de blocs figurant sous forme d'A880 0076 ou A880 0076 ou 5500 1176 ne correspond pas à la taille de la capacité de disque de 1199,79 signalé mon MDADM. Aussi aucun des emplacements des "superblocks" alignés sur les données dans les messages ci-dessus.

J'ai sauvegardé tout/var, et je suis prêt à essuyer les disques. Pour voir s'il était possible d'essuyer juste/md2, (je n'avais rien d'autre à perdre à ce stade) Je dis ce qui suit:

root@ced2:/home/richard# mdadm --create /dev/md2 --raid-devices=3 --level=5 --uuid=c0a644c7:e5bcf758:ecfbc8f3:ee0392b7 /dev/sdc1 /dev/sdd1 /dev/sde1 mdadm: /dev/sdc1 appears to be part of a raid array: level=raid5 devices=3 ctime=Wed Feb 3 14:05:36 2016 mdadm: /dev/sdd1 appears to contain an ext2fs file system size=585936896K mtime=Thu Jan 1 01:00:00 1970 mdadm: /dev/sdd1 appears to be part of a raid array: level=raid5 devices=3 ctime=Wed Feb 3 14:05:36 2016 mdadm: /dev/sde1 appears to contain an ext2fs file system size=585936896K mtime=Thu Jan 1 01:00:00 1970 mdadm: /dev/sde1 appears to be part of a raid array: level=raid5 devices=3 ctime=Wed Feb 3 14:05:36 2016 Continue creating array? y mdadm: Defaulting to version 1.2 metadata mdadm: array /dev/md2 started. # mkfs.ext3 /dev/md2 mke2fs 1.42.12 (29-Aug-2014) Creating filesystem with 292902912 4k blocks and 73228288 inodes Filesystem UUID: a54e252f-78db-4ebb-b7ca-7dcd2edf57a4 Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968, 102400000, 214990848 Allocating group tables: done Writing inode tables: done Creating journal (32768 blocks): done Writing superblocks and filesystem accounting information: done # hexdump -n84 -s0x00000400 -v /dev/md2 0000400 6000 045d 5800 1175 7799 00df 6ff0 112e 0000410 5ff5 045d 0000 0000 0002 0000 0002 0000 0000420 8000 0000 8000 0000 2000 0000 10d3 56b2 0000430 10d3 56b2 0002 ffff ef53 0001 0001 0000 0000440 0c42 56b2 0000 0000 0000 0000 0001 0000 0000450 0000 0000 0000454 # ./bgrep 00605D0400587511 /dev/md2 /dev/md2: 00000400 /dev/md2: 08000000 /dev/md2: 18000000 /dev/md2: 28000000 /dev/md2: 38000000 /dev/md2: 48000000 /dev/md2: c8000000 /dev/md2: d8000000 /dev/md2: 188000000 /dev/md2: 288000000 /dev/md2: 3e8000000 /dev/md2: 798000000 /dev/md2: ab8000000 etc

Tout semblait bien, sauf pour le passage à l'UUID. Ainsi, après quelques chèques supplémentaires, j'ai écrit 600 Go de données sauvegardées sur/dev/md2. Ensuite, démonta et essayé de retrouver le lecteur:

# mdadm --assemble /dev/md2 uuid=c0a644c7:e5bcf758:ecfbc8f3:ee0392b7 mdadm: cannot open device uuid=c0a644c7:e5bcf758:ecfbc8f3:ee0392b7: No such file or directory mdadm: uuid=c0a644c7:e5bcf758:ecfbc8f3:ee0392b7 has no superblock - Assembly aborted

Vous plaisantez j'espère? Qu'en est-il de mes 600 Go sur le fichier?

# mdadm --assemble /dev/md2 mdadm: /dev/md2 not identified in config file.

Ah - facilement corrigé. une ligne non motivée dans /etc/mdadm.conf

# mdadm --assemble /dev/md2 mdadm: /dev/md2 has been started with 3 drives. # e2fsck -n /dev/md2 e2fsck 1.42.12 (29-Aug-2014) /dev/md2: clean, 731552/73228288 files, 182979586/292902912 blocks

Yippie!