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

J'ai un disque dur de 1 1 To sur mon ubuntu 11.04 configuré en tant que raid logiciel 5. Les données avaient été copiées chaque semaine sur un autre disque dur séparé de l'ordinateur jusqu'à ce que cela échoue complètement et soit jeté. Il y a quelques jours, nous avons eu une panne de courant et après avoir redémarré ma boîte, je ne voulais pas monter le raid. Dans mon infinie sagesse je suis entré

mdadm --create -f...

commande au lieu de

mdadm --assemble

et n'a pas remarqué la parodie que j'avais faite jusqu'à après. Le tableau a commencé à se dégrader et a été construit et synchronisé, ce qui a pris environ 10 heures. Après mon retour, j’ai vu que le tableau était opérationnel mais que le raid n’était pas

Je veux dire que les lecteurs individuels sont partitionnés (type de partition f8), mais pas le md0périphérique. Réalisant avec horreur ce que j'ai fait, j'essaie de trouver des solutions. Je prie juste pour --createne pas écraser tout le contenu du pilote dur.

Est-ce que quelqu'un pourrait m'aider avec ceci - les données qui sont sur le lecteur sont très importantes et uniques ~ 10 ans de photos, de documents, etc.

Est-il possible qu'en spécifiant les disques durs participants dans le mauvais ordre, on puisse les mdadmécraser? 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

Curieusement, le nom utilisé était 'raid' et non l'hôte avec: 0 ajouté.

Voici les entrées de configuration "assainies":

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

Selon les suggestions, j'ai nettoyé les superblocs et ai recréé le tableau avec --assume-cleanoption mais sans aucune chance.

Existe-t-il un outil qui m'aidera à restaurer au moins certaines des données? Quelqu'un peut-il me dire quoi et comment mdadm --create fait quand se synchronise pour détruire les données afin que je puisse écrire un outil pour annuler tout ce qui a été fait?

Après la recréation du raid, je lance fsck.ext4 / dev / md0 et voici la sortie

root @ tanserv: / etc / mdadm # fsck.ext4 / dev / md0 e2fsck 1.41.14 (22-Dec-2010) fsck.ext4: superbloc non valide, en essayant des blocs de sauvegarde ... fsck.ext4: mauvais nombre magique en super bloquer 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 qu'il contient réellement un système de fichiers ext2 (et non swap, ufs ou autre chose), le superbloc est corrompu et vous pouvez essayer de faire fonctionner e2fsck avec un superbloc alternatif: e2fsck -b 8193

La suggestion de Per 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 ont renvoyé 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?

Cordialement!

Ok. Quelque chose me dérangeait à propos de votre problème, alors j’ai allumé une VM pour lui expliquer le comportement auquel il fallait s’attendre. J'arriverai à ce qui m'ennuyait dans une minute; laissez-moi d'abord dire ceci:

Sauvegardez ces lecteurs avant de tenter quoi que ce soit!

Vous avez peut-être déjà fait plus de dégâts que ce que la resynchronisation a fait; pouvez-vous préciser ce que vous vouliez dire quand vous avez dit:

Selon les suggestions, j'ai nettoyé les superblocs et recréé le tableau avec l'option --assume-clean, mais sans aucune chance.

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

Quoi qu’il en soit, récupérez de nouveaux disques et prenez-en des images exactes avant de faire quoi que ce soit qui pourrait écrire davantage sur ces disques.

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

Cela étant dit, il semble que les données stockées sur ces objets soient extrêmement résistantes aux resynchronisations fantaisistes. Continuez à lire, il y a de l'espoir, et c'est peut-être le jour où j'atteins la limite de longueur de réponse.

Le meilleur scénario

J'ai jeté ensemble une VM pour recréer votre scénario. Les disques ne font que 100 Mo, je ne serais donc pas en attente de chaque resynchronisation, mais cela devrait être une représentation assez précise sinon.

Construit le tableau de manière aussi générique et par défaut que possible - morceaux de 512 Ko, disposition symétrique à gauche, disques dans l'ordre des lettres .. 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" datafile, et 5 Mo de données aléatoires contenant cette valeur de hachage SHA1 randomdata); Voyons ce qui se passe quand on recrée.

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 s'est terminée très rapidement avec ces minuscules disques, mais cela s'est produit. Alors voici ce qui m'ennuyait de plus tôt; votre fdisk -lsortie. N'avoir aucune table de partition sur le mdpériphérique n'est pas un problème du tout, c'est prévu. Votre système de fichiers réside directement sur le faux périphérique de bloc 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

Oui, 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. Donc c'est bien; vérifions 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

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

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

Prendre du recul

Avant de tenter de résoudre ce problème, voyons pourquoi il est difficile de rompre. RAID 5 fonctionne en utilisant un bloc de parité qui protège une zone de la même taille que le bloc de chaque disque de la matrice. La parité ne concerne pas seulement un disque spécifique, elle est pivotée uniformément sur les disques pour mieux répartir la charge de lecture sur les disques en fonctionnement normal.

L'opération XOR 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

Ainsi, la parité est répartie entre 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 effectuée lors du remplacement d'un disque mort ou manquant. Cela est également fait mdadm createpour s'assurer que les données sur les disques s'alignent avec ce à quoi la géométrie du RAID est supposée ressembler. Dans ce cas, le dernier disque de la spécification de matrice est celui sur lequel la synchronisation est effectuée: toutes les données existantes sur les autres disques sont utilisées pour la synchronisation.

Ainsi, toutes les données du "nouveau" disque sont effacées et reconstruites; soit en construisant de nouveaux blocs de données à partir de blocs de parité pour ce qui aurait dû être là, soit en créant de nouveaux blocs de parité.

Ce qui est bien, c’est que la procédure à suivre pour ces deux choses est exactement la même: une opération XOR sur les données du reste des disques. Le processus de resynchronisation dans ce cas peut avoir dans sa présentation qu’un bloc donné doit être un bloc de parité et penser qu’il construit un nouveau bloc de parité alors qu’il recrée en fait un ancien bloc de données. Donc même s'il pense que cela construit ceci:

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

... il peut simplement s'agir de reconstruire à DISK5partir de la mise en page ci-dessus.

Il est donc possible que les données restent cohérentes même si la matrice est mal construite.

Lancer un singe dans les travaux

(pas une clé; le singe entier)

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, tout va 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 même si toutes les données sont là, elles sont dans le mauvais ordre; ce qui était autrefois 512 Ko de A, puis 512 Ko de B, A, B, etc. a maintenant été mélangé à B, A, B, A. Le disque ressemble maintenant à un charabia pour le vérificateur de système de fichiers, il ne fonctionnera pas. La sortie de mdadm --misc -D /dev/md1nous 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 cela 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, tout va bien. Nous avons écrasé tout un tas de blocs de données avec de nouveaux blocs de parité. Recréez, dans 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

Bien, il y a encore un système de fichiers! Vous avez encore 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 bloc et voyons si cela nous cause des problèmes.

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, ouais, c'est arrosé quand ça se passe 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

Le succès, encore!

Test 3

C’est celui qui, à mon avis, tuerait les données à coup sûr. Faisons un algorithme de présentation 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 avoir trouvé quelque chose et veut faire des réparations! 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 la resynchronisation avec une mise en page incorrecte:

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

Montrons simplement que la réduction à zéro des superblocs n'est pas préjudiciable très 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

Ouais, pas grave.

Test 5

Jetons tout ce que nous avons à faire. Les 4 tests précédents, combinés.

• Mauvais ordre d'appareil
• Mauvaise taille de morceau
• Mauvais algorithme de mise en page
• Superblocs mis à zéro (nous le ferons 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

Sensationnel.

Il semble donc qu'aucune de ces actions n'a corrompu les données. J'ai été assez surpris par ce résultat, franchement; Je m'attendais à une probabilité modérée de perte de données lors du changement de taille de bloc et à une perte certaine lors du changement de présentation. 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 disposez d'anciennes copies de vos /proc/mdstatinformations avec l'ordre du lecteur, l'algorithme, la taille de bloc et la version des métadonnées. Avez-vous configuré les alertes par e-mail de mdadm? Si c'est le cas, trouvez-en un ancien. sinon, vérifiez /var/spool/mail/root. Vérifiez votre ~/.bash_historypour voir si votre construction d'origine est là-bas.

Alors, la liste des choses que vous devriez faire:

1. Sauvegardez les disques avec ddavant de faire quoi que ce soit !!
2. Essayez avec fsckle md actif actuel - vous venez peut-être de construire dans le même ordre que précédemment. Si vous connaissez le type de système de fichiers, c'est utile. utiliser cet fsckoutil spécifique . Si l'un des outils propose de réparer quoi que ce soit, ne le laissez pas sauf si vous êtes certain d'avoir trouvé le système de fichiers valide! Si une fsckoffre de réparer quelque chose pour vous, n'hésitez pas à laisser un commentaire pour demander si cela aide réellement ou juste sur des données nucléaires.
3. 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, vous êtes un peu dans le noir - il est raisonnable d'essayer tous les différents ordres de lecteurs, mais il est inutile de vérifier chaque taille de bloc possible avec chaque ordre possible. Pour chacun, fsckvoir si vous avez quelque chose de prometteur.

Alors 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

Si vous avez de la chance, vous pourrez peut-être récupérer vos fichiers avec un logiciel de récupération capable de lire une matrice RAID-5 défectueuse. Zero Assumption Recovery est un programme avec lequel j'ai eu du succès auparavant.

Cependant, je ne suis pas sûr que le processus de création d'un nouveau tableau ait été détruit et détruit toutes les données. Il pourrait donc s'agir d'un effort ultime.

J'ai eu un problème similaire:
après une défaillance d'un logiciel RAID5, j'ai déclenché mdadm --createsans le donner --assume-cleanet je ne pouvais plus monter le module. Après deux semaines de recherches, j'ai finalement restauré toutes les données. J'espère que la procédure ci-dessous permettra à quelqu'un de gagner du temps.

Longue histoire courte

Le problème était dû au fait qu’un mdadm --createnouveau tableau était différent de l’original sous deux aspects:

• ordre différent des partitions
• décalage de données RAID différent

Comme le montre la réponse brillante de Shane Madden , mdadm --createne détruit pas les données dans la plupart des cas! Après avoir trouvé l'ordre de la partition et le décalage des données, je pouvais restaurer le tableau et en extraire toutes les données.

Conditions préalables

Je n'avais aucune sauvegarde de superblocs RAID, donc tout ce que je savais, c'est qu'il s'agissait d'un ensemble RAID5 sur 8 partitions créé lors de l'installation de Xubuntu 12.04.0. Il avait un système de fichiers ext4. Un autre élément de connaissance important était la copie d'un fichier qui était également stocké sur la matrice RAID.

Outils

Xubuntu 12.04.1 live CD a été utilisé pour effectuer tout le travail. Selon votre situation, vous aurez peut-être besoin des outils suivants:

version de mdadm permettant 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, mount et une calculatrice hexadécimale - outils standard de repos

Commencer avec une sauvegarde complète

La dénomination des fichiers de périphérique, par exemple, /dev/sda2 /dev/sdb2etc., n’est pas persistante, il est donc préférable de noter les numéros de série de vos lecteurs, donnés par.

sudo hdparm -I /dev/sda

Connectez ensuite un disque dur externe et sauvegardez chaque partition de votre matrice RAID comme suit:

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

Déterminer la disposition RAID5 d'origine

Diverses dispositions sont décrites ci-dessous: http://www.accs.com/p_and_p/RAID/LinuxRAID.html
Pour savoir comment les bandes de données ont été organisées sur le tableau d'origine, vous avez besoin d'une copie d'un fichier de style aléatoire, comme vous le savez. stocké sur le tableau. La taille de bloc par défaut actuellement utilisée par mdadmest de 512 Ko. Pour un tableau de N partitions, vous avez besoin d’un fichier d’une taille minimale (N + 1) * 512 Ko. Un jpeg ou une vidéo est bon car il fournit des sous-chaînes relativement uniques de données binaires. Supposons que notre fichier s'appelle picture.jpg. Nous lisons 32 octets de données en N + 1 positions à partir de 100k et en augmentant 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 chaînes d'octets 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. L'analyse 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 seule fois sur les huit lecteurs. En comparant les décalages renvoyés par bgrep, vous obtenez une image 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 une disposition normale symétrique à gauche , qui est la valeur 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 du tableau, car elles peuvent être décalées de manière cyclique.

Notez également la distance entre les décalages trouvés. Dans mon cas, c'était 512KB. La taille du bloc peut en réalité être inférieure à cette distance, auquel cas la disposition réelle sera différente.

Trouver la taille d'origine

Nous utilisons le même fichier picture.jpgpour lire 32 octets de données à des intervalles différents les uns des autres. Nous savons par le haut que les données à l'offset 100k /dev/sdh2reposent, à l'offset 612k à /dev/sdb2et à 1124k à /dev/sdd2. Cela montre que la taille du bloc n'est pas supérieure à 512 Ko. Nous vérifions qu'il n'est pas inférieur à 512 Ko. Pour cela, nous vidons la chaîne d'octets à l'offset 356k et regardons sur quelle partition elle se trouve:

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

Il se trouve sur la même partition que l'offset 612k, ce qui indique que la taille du bloc n'est pas de 256 Ko. Nous éliminons les plus petites tailles de morceaux de la même manière. Je me suis retrouvé avec des morceaux de 512KB étant la seule possibilité.

Trouver la première partition dans la mise en page

Nous connaissons maintenant l'ordre des partitions, mais nous ne savons pas quelle partition devrait être la première et quel décalage de données RAID a été utilisé. Pour trouver ces deux inconnues, nous allons créer une grappe RAID5 avec une disposition correcte des blocs et un petit décalage de données, puis rechercher le début de notre système de fichiers dans cette nouvelle grappe.

Pour commencer, nous créons un tableau avec le bon ordre de partitions, que nous avons trouvé 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

Nous déterminons maintenant les décalages des N + 1 chaînes d'octets connues dans la matrice RAID. Je lance un script pour une nuit (le 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 des 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 constatons que la 3ème chaîne n'a pas été trouvée. Cela signifie que le bloc at /dev/sdd2est 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 sur laquelle démarrer le tableau, afin de déplacer les morceaux de parité au bon endroit. Comme la parité doit être décalée de deux morceaux vers la gauche, la séquence de partition doit être décalée de deux pas vers la droite. Ainsi, la mise en page correcte pour ce décalage de données est la suivante 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 matrice RAID contient des données sous la forme appropriée. Vous aurez peut-être de la chance si le décalage des données RAID est identique à celui de la matrice d'origine et vous pourrez alors probablement monter la partition. Malheureusement, ce n'était pas mon cas.

Vérifier la cohérence des données

Nous vérifions la cohérence des données sur une bande de morceaux en extrayant une copie de picture.jpgla matrice. Pour cela, localisons le décalage de la chaîne de 32 octets à 100 ko:

sudo ./bgrep DA1DC4D616B1C71079624CDC36E3D40E7B1CFF00857C663687B6C4464D6C77D2 /dev/md126

Nous soustrayons ensuite 100 * 1024 du résultat et utilisons la valeur décimale obtenue en skip=paramètre pour dd. Le count=est la taille picture.jpgen octets:

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

Vérifiez que extract.jpgc'est la même chose que picture.jpg.

Trouver le décalage de données RAID

Une remarque: le décalage de données par défaut pour la mdadmversion 3.2.3 est de 2048 secteurs. Mais cette valeur a changé avec le temps. Si le tableau d' origine utilisé un plus petit que votre décalage de données en cours mdadm, puis mdadm --createsans --assume-cleanpeut remplacer le début du système de fichiers.

Dans la section précédente, nous avons créé une matrice RAID. Vérifiez le décalage de données RAID dont il disposait en émettant pour certaines des partitions individuelles:

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

2048 secteurs de 512 octets est 1MB. La taille de bloc étant de 512 Ko, le décalage de données actuel est de deux morceaux.

Si à ce stade, vous avez un décalage de deux blocs, il est probablement suffisamment petit et vous pouvez ignorer ce paragraphe.
Nous créons une matrice RAID5 avec le décalage de données d'un bloc de 512 Ko. Commencer un morceau plus tôt déplace la parité d'un pas vers la gauche, donc nous compensons en déplaçant la séquence de partition d'un pas vers la gauche. Par conséquent, pour un décalage de données de 512 Ko, la mise en page correcte est hbdcefga. Nous utilisons une version mdadmqui prend en charge le décalage de données (voir la section Outils). Cela prend offset 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

Maintenant, nous recherchons un superbloc ext4 valide. La structure de superbloc peut être trouvée ici: https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout#The_Super_Block
Nous analysons le début du tableau à la recherche d'occurrences du nombre magique s_magicsuivies de s_stateet s_errors. Les bytestrings à rechercher sont:

53EF01000100
53EF00000100
53EF02000100
53EF01000200
53EF02000200

Exemple de commande:

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

Le nombre magique commence 0x38 octets dans le superbloc, nous soustrayons donc 0x38 pour calculer le décalage et examiner le superbloc entier:

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_sizechamp à 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 qui est 254GB. Cela semble bon.

Nous recherchons maintenant les occurrences des premiers octets du superbloc pour trouver ses copies. Notez le basculement d'octet 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 correspond parfaitement aux positions attendues des superblocs 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 à l’offset 0xdc80000, c’est-à-dire 225792 Ko à partir du début de la partition. Puisque nous avons 8 partitions, dont une pour la parité, nous divisons le décalage par 7. Cela donne 33030144 octets décalés sur chaque partition, ce qui correspond exactement à 63 blocs RAID. Et comme le décalage de données RAID actuel est d'un bloc, nous concluons que le décalage de données d'origine était de 64 morceaux, soit 32768 Ko. Un décalage de hbdcefga63 fois vers la droite donne la mise en page bdcefgah.

Nous construisons finalement la bonne matrice 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à!

J'ai eu un problème similaire. J'ai formaté et réinstallé mon lecteur de système d'exploitation / système d'exploitation avec une nouvelle installation d'Ubuntu 12.04, puis j'ai exécuté la commande mdadm --create ... et je n'ai pas pu le 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 périphérique standard.

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 a restauré le superbloc afin que je puisse monter et lire le lecteur.

Pour que le tableau fonctionne sans détruire le superbloc ou les partitions que j'ai utilisées pour la construction:

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

Je ne fais que mettre à jour certaines des informations données précédemment. Un tableau RAID 3 à 3 disques fonctionnait correctement lorsque ma carte mère est morte. Le tableau contenait / dev / md2 en tant que partition / home de 1,2 To et / dev / md3 en tant que partition / var de 300 Go.

J'avais deux sauvegardes de choses "importantes" et une série de choses aléatoires que j'avais saisies à divers endroits d'Internet et que j'aurais vraiment dû parcourir et jeter de manière sélective. La plupart des sauvegardes ont été décomposées en fichiers .tar.gz de 25 Go ou moins, et une copie distincte de / etc a également été sauvegardée.

Le reste du système de fichiers s'est déroulé sur deux petits disques raid0 de 38 Go.

Ma nouvelle machine était semblable à l'ancien matériel et je l'ai mise en marche simplement en branchant les cinq disques et en sélectionnant un ancien noyau générique. Donc, j'avais cinq disques avec des systèmes de fichiers propres, bien que je ne puisse pas être sûr que les disques soient dans le bon ordre, et je devais installer une nouvelle version de Debian Jessie pour être sûr de pouvoir mettre à jour la machine si nécessaire, et de trier les autres problèmes.

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

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

Mais je n'ai pas. Il semble que mdadm soit assez intelligent et que, avec un uuid, il sache où aller. Même si le bios désigne / dev / sdc en tant que / sda, mdadm le mettra correctement ensemble (bien que YMMV).

Au lieu de cela, j'ai publié mdadm --create /dev/md2 without the --assume-clean:, et laissé la resynchronisation sur / dev / sde1 se terminer. L’erreur suivante que j’ai faite est de travailler sur / dev / sdc1 au lieu du dernier lecteur de / dev / md2, / sde1. À tout moment, mdadm pense qu’il ya un problème, c’est le dernier disque qui a été mis à la porte ou resynchronisé.

Après cela, mdadm n'a pu trouver aucun superbloc, et e2fsck -n n'a pas pu non plus.

Après avoir trouvé cette page, j’ai essayé de trouver la séquence des disques (terminée), de vérifier la validité des données (6 Mo vérifiés d’un fichier de 9 Mo), d’obtenir les disques dans le bon ordre, cde, de saisir les uuid de / md2 et / md3 à partir de l’ancien /etc/mdadm.conf et essayé de les assembler.

Eh bien, a /dev/md3commencé et a mdadm --misc -D /dev/md3montré trois partitions en bonne santé, et les disques dans le bon ordre. /dev/md2avait également l'air bien, jusqu'à ce que j'ai essayé 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 trouvé aucun superbloc. En outre, lors de la vérification des superblocs comme décrit ci-dessus, le nombre total de blocs trouvé comme étant un 880 0076, un 880 0076 ou un 5500 1176 ne correspondait pas à la taille de la capacité du disque de 1199,79 indiquée par mdadm. En outre, aucun des emplacements des "superblocs" alignés avec les données des publications ci-dessus.

J'ai sauvegardé tout le répertoire / var et je me suis préparé à effacer les disques. Pour voir s'il était possible d'effacer simplement / md2, (je n'avais rien d'autre à perdre à ce stade), voici 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 aller bien, sauf le changement de l'uuid. Après quelques vérifications supplémentaires, j’ai écrit 600 Go de données sauvegardées sur / dev / md2. Ensuite, démontez et essayez de remonter 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 réparé. non commenté une ligne 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!