34 votos

Recuperar datos RAID 5 después de creada la nueva matriz en lugar de re-uso de

Gente por favor ayuda - soy un newb con un gran dolor de cabeza en la mano (la tormenta perfecta de la situación).

Tengo 3 hdd de 1 tb en mi ubuntu 11.04 configurado como software raid 5. Los datos habían sido copiado semanal en otro separar el disco duro del ordenador hasta que falló completamente y fue lanzado lejos. Unos días atrás tuvimos un apagón y después de reiniciar mi caja no montar el raid. En mi infinita sabiduría me entró

mdadm --create -f...

comando en lugar de

mdadm --assemble

y no se dieron cuenta de la farsa que había hecho hasta después. Comenzó la matriz de degradado y se procedió con la construcción y la sincronización de que el que tomó ~10 horas. Después me volví vi que la matriz con éxito y en funcionamiento, pero el raid no es

Me refiero a las unidades individuales son particiones (partición de tipo f8 ) pero el md0 dispositivo no está. Darse cuenta en el horror de lo que he hecho estoy tratando de encontrar algunas soluciones. Pido que --create no sobreescribir todo el contenido de la unidad.

Podría por FAVOR alguien que me ayude con esto - los datos de la unidad es muy importante y único en ~10 años de fotos, documentos, etc.

Es posible que mediante la especificación de la participación de unidades de disco duro en un orden incorrecto puede hacer mdadm sobrescribir? cuando hago

mdadm --examine --scan 

Puedo obtener algo como ARRAY /dev/md/0 metadata=1.2 UUID=f1b4084a:720b5712:6d03b9e9:43afe51b name=<hostname>:0

Curiosamente el nombre que solía ser 'raid' y no el host hame con :0 anexa.

Aquí está el 'desinfectar' entradas de configuración:

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

Por las sugerencias que me hizo limpiar los superbloques y re-crea la matriz con --assume-clean opción, pero no hubo suerte a todos.

¿Hay alguna herramienta que me ayude a revivir, al menos, algunos de los datos? Alguien me puede decir qué y cómo la mdadm --create hace cuando se sincroniza a destruir los datos para que yo pueda escribir una herramienta para la onu-hacer lo que se hizo?

Después de la re-creación de la raid puedo ejecutar fsck.ext4 /dev/md0 y aquí está el resultado

root@tanserv:/etc/mdadm# fsck.ext4 /dev/md0 e2fsck 1.41.14 (22-Dic-2010) fsck.ext4: Superbloque no válido, tratando de copia de seguridad de los bloques... fsck.ext4: Bad magic number en super-bloque, mientras que tratando de abrir /dev/md0

El superbloque no se puede leer o no describe una correcta ext2 el sistema de ficheros. Si el dispositivo es válido y lo que realmente contiene un sistema de archivos ext2 sistema de archivos (y no de intercambio o ufs o algo más), entonces el superbloque es corrupto, y puede que se trate de ejecutar e2fsck con un suplente superbloque: e2fsck-b 8193


Por Shanes la sugerencia de que he intentado

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

y ejecutar fsck.ext4 con cada copia de seguridad de bloque, pero todo volvió a la siguiente:

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>

Alguna sugerencia?

Saludos!

87voto

Shane Madden Puntos 81409

Ok - algo se me molesta acerca de su problema, así que me lancé a una máquina virtual para sumergirse en el comportamiento que se debe esperar. Voy a llegar a lo que estaba molestando en un minuto; en primer lugar, permítanme decir esto:

Copia de seguridad de estos dispositivos antes de intentar cualquier cosa!!

Usted puede haber hecho daño más allá de lo que la resincronización hizo; puede aclarar lo que quiso decir cuando dijo:

Por las sugerencias que me hizo limpiar los superbloques y re-crea la matriz con --asumen la opción-clean, pero no hubo suerte a todos.

Si ejecutó un mdadm --misc --zero-superblock, entonces usted debe estar bien.

De todos modos, busca nuevos discos y agarrar exacta imágenes actuales de ellos antes de hacer cualquier cosa que podría hacer más de la escritura de dichos discos.

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

Lo que se dice.. se parece a los datos almacenados en estas cosas es sorprendentemente resistente a los díscolos resyncs. Leer, hay esperanza, y este puede ser el día en que llegué a la respuesta límite de longitud.


El Mejor De Los Casos

Me lanzó junto a una máquina virtual para recrear el escenario. Las unidades se encuentran a solo 100 MB, así que no estará esperando para siempre en cada uno de resincronización, pero esto debe ser una idea bastante precisa de la representación de otra manera.

Construida la matriz de forma genérica y por defecto como sea posible - 512k trozos, de izquierda simétrica de diseño, los discos en la carta de pedido.. nada especial.

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>

Hasta ahora, bien; vamos a hacer un sistema de ficheros, y poner algunos datos sobre ella.

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

Ok. Tenemos un sistema de ficheros y datos (los"datos" en datafile, y 5MB de la pena de datos aleatorios con ese hash SHA1 en randomdata); vamos a ver qué pasa cuando hacemos un re-crear.

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 resincronización termina muy rápidamente con estos pequeños discos, pero no llegó a producirse. Así que aquí está lo que estaba molestando desde antes; su fdisk -l de salida. De no tener la tabla de partición en el md dispositivo no es un problema en absoluto, se espera. El sistema de ficheros reside directamente en el falso dispositivo de bloque sin tabla de particiones.

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

Sí, no hay tabla de particiones. Pero...

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

Perfectamente válido sistema de ficheros, después de una resincronización. Así que bueno, vamos a comprobar en nuestros archivos de datos:

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

Sólido - no hay datos de la corrupción a todos! Pero esto es exactamente con la misma configuración, por lo que nada se asignan de manera diferente entre los dos grupos de RAID. Vamos a colocar esta cosa antes de que nosotros tratamos de romper.

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

Tomando un Paso Atrás

Antes de tratar de romper este, vamos a hablar de por qué es difícil de romper. RAID 5 funciona mediante el uso de un bloque de paridad que protege un área del mismo tamaño que el bloque en cada disco de la matriz. La paridad no es sólo un disco determinado, se gira alrededor de los discos de manera uniforme, para difundir mejor la carga de lectura a cabo a través de los discos en la operación normal.

La operación XOR para calcular la paridad se parece a esto:

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

Así, la paridad se extendió entre los discos.

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

Una resincronización suele hacerse cuando la sustitución de un muertas o desaparecidas en el disco; es también hecho en mdadm create para asegurar que los datos en los discos que se alinea con lo que el RAID de la geometría se supone que se vea como. En ese caso, el último disco de la matriz de especificaciones es el que está sincronizado a' - todos los datos existentes en los otros discos se utiliza para la sincronización.

De este modo, todos los datos sobre el 'nuevo' disco se destruye y reconstruye; ya sea fresco de la construcción de bloques de datos de bloques de paridad para lo que debería haber estado allí, o más fresco de la construcción bloques de paridad.

Lo bueno es que el procedimiento tanto de esas cosas es el mismo: una operación XOR entre los datos del resto de los discos. La resincronización proceso en este caso puede tener en su presentación que un determinado bloque debe ser un bloque de paridad, y creo que es la construcción de un nuevo bloque de paridad, cuando en realidad se trata de volver a la creación de un viejo bloque de datos. Así que, incluso si se piensa que la construcción de este:

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

...que sólo puede ser la reconstrucción DISK5 desde el diseño anterior.

Así, es posible que los datos para ser consistente, incluso si la matriz integrada del mal.


Lanzando un Mono en las Obras

(no una llave; todo el mono)

Prueba 1:

Vamos a hacer que la matriz en el orden equivocado! sdc, a continuación, sdd, a continuación, 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, eso es todo bien y bueno. ¿Tenemos un sistema de ficheros?

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>

Nope! ¿Por qué es eso? Porque mientras que los datos de todo lo que hay, es en el orden equivocado; lo que una vez fue de 512 kb de Un, a continuación, 512KB de B, a, B, y así sucesivamente, ahora se ha barajado a B, a, B, A. El disco ahora parece jibberish para el sistema de archivos checker, no se ejecutará. La salida de mdadm --misc -D /dev/md1 nos da más detalles; Se parece a esto:

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

Cuando se debe tener este aspecto:

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

Así que, eso es todo bien y bueno. Nos sobrescribió un montón de bloques de datos con los nuevos bloques de paridad este tiempo de espera. Re-crear, con el orden correcto ahora:

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

Pulcro, todavía hay un sistema de ficheros que hay! Todavía tengo los datos?

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

El éxito!

Prueba 2

Ok, vamos a cambiar el tamaño de porción y a ver si nos llega algo de quebrantamiento.

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>

Sí, sí, es una manguera cuando se establece como esta. Pero, ¿se puede recuperar?

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

El éxito, de nuevo!

Prueba 3

Este es el que yo pensaba que iba a matar a los datos para que - vamos a hacer un diseño diferente algoritmo!

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).

Miedo y mal - se piensa que encontró algo y quiere hacer alguna fijación! Ctrl+C!

Clear<y>? cancelled!

fsck.ext4: Illegal inode number while checking ext3 journal for /dev/md1

Ok, crisis evitado. Vamos a ver si los datos siguen intactos después de la resincronización con el mal diseño de:

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

El éxito!

Prueba 4

También vamos a probar que el superbloque de la reducción a cero no es perjudicial muy rápido:

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

Sí, no es gran cosa.

Prueba 5

Vamos a tirar todo lo que tenemos en ella. Todos los 4 las pruebas anteriores combinados.

  • Dispositivo equivocado orden
  • Mal tamaño de porción
  • Mal diseño del algoritmo
  • Cero superbloques (vamos a hacerlo entre ambas creaciones)

Adelante!

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

El veredicto?

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.

Así, parece que ninguna de estas acciones de los datos dañados de alguna manera. Yo estaba muy sorprendido por este resultado, francamente; yo esperaba moderada probabilidades de pérdida de datos en el fragmento de cambio de tamaño, y algunos pérdida definitiva sobre el cambio de diseño. Hoy aprendí algo.


Así que .. ¿Cómo puedo obtener mis datos??

Toda la información que tenga sobre el sistema antiguo, que sería muy útil para usted. Si usted sabe el tipo de sistema de archivos, si usted tiene cualquier copias antiguas de su /proc/mdstat con información sobre el orden de la unidad, algoritmo, tamaño de porción, y la versión de metadatos. ¿Tienes mdadm de correo electrónico configuración de alertas? Si es así, encontrar una vieja; si no es así, compruebe /var/spool/mail/root. Revise su ~/.bash_history para ver si su construcción original es de allí.

Así, la lista de cosas que usted debe hacer:

  1. Copia de seguridad de los discos con dd antes de hacer nada!!
  2. Intente fsck de la corriente, activo md - puede que tenga que acaba de pasar a construir en el mismo orden que antes. Si usted sabe el tipo de sistema de archivos, que es útil; un uso específico fsck herramienta. Si alguna de las herramientas que se ofrecen para solucionar cualquier cosa, no dejes que ellos a menos que esté seguro de que ha encontrado la validez del sistema de ficheros! Si un fsck ofrece para arreglar algo para usted, no dude en dejar un comentario para preguntar si es realmente ayudar o a nuke de datos.
  3. Trate de construcción de la matriz con diferentes parámetros. Si usted tiene un viejo /proc/mdstat, entonces usted puede imitar lo que se muestra; si no, entonces usted está un poco en la oscuridad, tratando todos de la unidad diferentes órdenes es razonable, pero la comprobación de que cada posible tamaño de porción en cada orden es inútil. Para cada uno, fsck a ver si se consigue nada prometedor.

Así que, que, que. Lo siento por la novela, siéntase libre de dejar un comentario si usted tiene cualquier pregunta, y buena suerte!

nota: en virtud de 22 mil caracteres; 8k+ tímido del límite de longitud de la

5voto

Shlomi Fish Puntos 1951

Si usted es afortunado , usted podría tener cierto éxito con la obtención de los archivos de nuevo con el software de recuperación que puede leer una rotura de matriz RAID-5. Zero Assumption Recovery es uno de los que he tenido éxito con anterioridad.

Sin embargo, no estoy seguro de si el proceso de creación de una nueva matriz se ha ido y destruye todos los datos, así que esto podría ser una última oportunidad esfuerzo.

2voto

Anton Stolbunov Puntos 31

He tenido un problema similar:
después de un fracaso de un software raid 5 matriz disparé mdadm --create sin dándole --assume-clean, y no podía montar la matriz más. Después de dos semanas de excavación finalmente restaurado todos los datos. Espero el siguiente procedimiento le ahorrará el tiempo de alguien.

Larga Historia Corta

El problema fue causado por el hecho de que mdadm --create una nueva matriz que era diferente de la original en dos aspectos:

  • orden diferente de las particiones
  • RAID diferentes datos de compensación

Como se ha demostrado en la brillante respuesta de Shane Madden, mdadm --create no destruir los datos en la mayoría de los casos! Después de encontrar la partición de pedido y datos de compensación podría restaurar la matriz y extraer todos los datos de ella.

Requisitos previos

Yo no tenía copias de seguridad de RAID superbloques, lo único que sabía era que se trataba de un raid 5 matriz de 8 particiones que se crean durante la instalación de Xubuntu 12.04.0. Había un sistema de archivos ext4. Otra pieza importante del conocimiento es una copia de un archivo que se almacena en la matriz RAID.

Herramientas

Xubuntu 12.04.1 live CD se utilizó para hacer todo el trabajo. Dependiendo de su situación, usted puede ser que necesite algunas de las siguientes herramientas:

la versión de mdadm que permite especificar los datos de compensación

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

bgrep - búsqueda de datos binarios

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

hexdump, e2fsck, montaje y una calculadora hexadecimal - herramientas estándar de repos

Comience con la Copia de seguridad Completa

Nomenclatura de los archivos de un dispositivo, por ejemplo /dev/sda2 /dev/sdb2 etc., no es persistente, por lo que es mejor para escribir sus unidades de serie de los números dados por

sudo hdparm -I /dev/sda

A continuación, conectar un disco duro externo y copia de seguridad de cada partición de la matriz RAID como este:

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

Determinar Original RAID5 Diseño

Los diferentes diseños se describen a continuación: http://www.accs.com/p_and_p/RAID/LinuxRAID.html
Para encontrar cómo tiras de datos se organizaron en la matriz original, usted necesita una copia de un azar-archivo en busca de que usted sabe que fue almacenada en la matriz. El tamaño de porción predeterminado utilizado actualmente por mdadm es de 512 kb. Para una matriz de N particiones, necesita un archivo de tamaño al menos (N+1)*512 KB. Un jpeg o de video es buena, ya que proporciona relativamente único subcadenas de datos binarios. Supongamos que nuestro archivo se llama picture.jpg. Leemos 32 bytes de datos en N+1 posiciones a partir de 100k y el incremento por 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
...

Nosotros, a continuación, busque las apariciones de todos estos bytestrings en todas nuestras particiones raw, así que en total, (N+1)*N comandos, como este:

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
...

Estos comandos se pueden ejecutar en paralelo de diferentes discos. Análisis de un 38GB partición tomó alrededor de 12 minutos. En mi caso, cada cadena de 32 bytes se encuentran sólo una vez entre los ocho unidades. Mediante la comparación de los desplazamientos devuelto por bgrep de obtener una imagen como esta:

| 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 |

Vemos una normal a la izquierda-simétrica de diseño, que es el predeterminado para mdadm. Lo que es más importante, ahora sabemos que el orden de las particiones. Sin embargo, no sabemos en qué partición es la primera en la matriz, como pueden ser cyclicly cambiado.

Tenga en cuenta también la distancia entre encontró compensaciones. En mi caso fue de 512 kb. El tamaño de porción en realidad puede ser más pequeña que esta distancia, en cuyo caso la configuración real será diferente.

Encontrar Original Tamaño De Porción

Utilizamos el mismo archivo picture.jpg leer 32 bytes de datos en diferentes intervalos de uno a otro. Sabemos de lo anterior que los datos en el desplazamiento de 100k está acostado en /dev/sdh2, y en el desplazamiento 612k es en /dev/sdb2, y en 1124k es en /dev/sdd2. Esto muestra que el tamaño de porción es no más grande que la de 512 kb. Podemos comprobar que no es menor que la de 512 kb. Para esto hemos volcado la bytestring en el desplazamiento 356k y ver en qué partición se encuentra:

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

Es en la misma partición como desplazamiento 612k, lo que indica que el tamaño de porción no es de 256KB. Eliminamos pequeños tamaños de fragmento en la manera similar. Terminé con 512KB de trozos ser la única posibilidad.

Encontrar la Primera Partición en el Diseño

Ahora sabemos que el orden de las particiones, pero no sabemos cuál de ellas debe ser la primera, y que de datos RAID offset se utiliza. Para encontrar estos dos incógnitas, vamos a crear una matriz raid 5 con un correcto trozo de diseño y un pequeño desplazamiento, y la búsqueda para el inicio de nuestro sistema de archivos en esta nueva matriz.

Para empezar, vamos a crear una matriz con el orden correcto de las particiones, lo que hemos encontrado anteriormente:

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

Podemos comprobar que la orden sea obedecida por la emisión de

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

Ahora podemos determinar los desplazamientos de los N+1 conocido bytestrings en la matriz RAID. Puedo ejecutar una secuencia de comandos para una noche (Live CD no preguntar por la contraseña de 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

Salida con los comentarios:

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

A partir de estos datos podemos ver que la 3ª cuerda no se encontró. Esto significa que el fragmento en /dev/sdd2 se utiliza para la paridad. Aquí está una ilustración de la paridad de posiciones en la nueva matriz:

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

Nuestro objetivo es deducir que la partición para iniciar la matriz, con el fin de cambiar los pedazos de paridad en el lugar correcto. Dado que la paridad debe ser desplazado dos trozos a la izquierda, la partición de la secuencia debe ser desplazado dos pasos a la derecha. Por lo tanto el diseño correcto para este tipo de datos offset es 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 

En este punto de nuestro RAID array que contiene los datos en la forma correcta. Podría ser la suerte de modo que los datos RAID desplazamiento es el mismo que en la matriz original y, a continuación, lo más probable es ser capaz de montar la partición. Desafortunadamente, este no era mi caso.

Verificar La Consistencia De Los Datos

Podemos comprobar que los datos son consistentes a través de una franja de los trozos mediante la extracción de una copia de picture.jpg de la matriz. Para ello vamos a localizar el desplazamiento de la cadena de 32 bytes en 100k:

sudo ./bgrep DA1DC4D616B1C71079624CDC36E3D40E7B1CFF00857C663687B6C4464D6C77D2 /dev/md126

Luego nos restan 100*1024 de el resultado y el uso de los obtenidos decimal valor en skip= parámetro de dd. El count= es el tamaño de la picture.jpg en bytes:

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

Compruebe que extract.jpg es el mismo que picture.jpg.

Encuentre Datos de RAID Offset

Una nota al margen: por defecto los datos de desplazamiento para el mdadm versión 3.2.3 es de 2048 sectores. Pero este valor ha sido cambiado a lo largo del tiempo. Si la matriz original utiliza un menor de datos de desplazamiento de su actual mdadm, a continuación, mdadm --create sin --assume-clean puede sobrescribir el inicio del sistema de archivos.

En la sección anterior hemos creado una matriz RAID. Verificar que RAID de datos de desplazamiento que tenía por la emisión de algunas de las particiones individuales:

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

2048 sectores de 512 bytes es de 1 mb. Desde el tamaño de porción es de 512 kb, los datos de la corriente de desplazamiento es de dos trozos.

Si en este momento usted tiene dos pedazo de desplazamiento, es probablemente lo suficientemente pequeño, y usted puede saltarse este párrafo.
Vamos a crear un raid 5 matriz con los datos de compensación de uno de 512 kb-chunk. A partir de un fragmento anterior se cambia la paridad de un paso a la izquierda, por lo tanto, se compensa por el desplazamiento de la partición de la secuencia de un paso a la izquierda. Por lo tanto para 512KB de datos de compensación, el diseño correcto es hbdcefga. Usamos una versión de mdadm que es compatible con datos de desplazamiento (consulte la sección de Herramientas). Toma de desplazamiento en kilobytes:

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

Ahora buscamos un válido ext4 superbloque. El superbloque estructura se puede encontrar aquí: https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout#The_Super_Block
Podemos analizar el principio de la matriz de ocurrencias de la magia número s_magic , seguido por s_state y s_errors. El bytestrings a buscar son:

53EF01000100
53EF00000100
53EF02000100
53EF01000200
53EF02000200

Comando de ejemplo:

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

El número mágico comienza 0x38 de bytes en el superbloque, por lo que nos reste 0x38 para calcular el desplazamiento y examinar toda la superbloque:

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                              

Este parece ser un válido superbloque. s_log_block_size de campo en 0x18 es 0002, lo que significa que el tamaño de bloque es de 2^(10+2)=4096 bytes. s_blocks_count_lo en 0x4 es 03f81480 bloques que se 254GB. Se ve bien.

Ahora exploración de las apariciones de los primeros bytes del superbloque para encontrar sus copias. Nota el byte voltear como en comparación con hexdump de salida:

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

Esto se alinea perfectamente con la espera de posiciones de copia de seguridad de superbloques:

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

Por lo tanto el sistema de archivos se inicia en el desplazamiento 0xdc80000, es decir, 225792KB desde el inicio de la partición. Ya tenemos 8 particiones de los cuales uno es el de la paridad, dividimos el desplazamiento por 7. Esto le da 33030144 bytes de desplazamiento en cada partición, que es exactamente 63 RAID trozos. Y puesto que la corriente de datos de RAID desplazamiento es de un solo tramo, llegamos a la conclusión de que los datos originales de desplazamiento fue de 64 trozos, o 32768KB. Cambiando hbdcefga 63 veces a la derecha, muestra el diseño de la bdcefgah.

Finalmente hemos de construir la correcta matriz 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à!

0voto

SideShow Bob Puntos 1

Yo tenía un problema similar. He formateado y reinstalado mi SO/unidad de arranque con una instalación limpia de Ubuntu 12.04, y luego corrió la mdadm --create... comando y no podía montar.

Se dijo que no tenía una validez de superbloque o partición.

Por otra parte, cuando dejé el mdadm raid, yo ya no podía montar el regular dispositivo.

Yo era capaz de reparar el superbloque con mke2fs y 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

Luego corrió:

e2fsck -b 32768 -y /dev/sdc1

Que restaure el superbloque para que yo pudiera montar y leer la unidad.

Para obtener la matriz de trabajo sin destruir el superbloque o particiones que he usado:

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

Después de verificar los datos, voy a añadir la otra unidad:

mdadm --add /dev/md0 /sdd1

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by: