Recupere datos RAID 5 después de crear una nueva matriz en lugar de volver a usar

35

Amigos, por favor, ayuden: soy un novato con un gran dolor de cabeza (situación de tormenta perfecta).

Tengo un disco duro de 3 1 tb en mi ubuntu 11.04 configurado como software raid 5. Los datos se copiaron semanalmente en otro disco duro separado de la computadora hasta que falló por completo y se descartó. Hace unos días tuvimos un corte de energía y después de reiniciar mi caja no montó la redada. En mi infinita sabiduría entré

mdadm --create -f...

comando en lugar de

mdadm --assemble

y no noté la parodia que había hecho hasta después. Comenzó la matriz degradada y procedió a construirla y sincronizarla, lo que tomó ~ 10 horas. Cuando regresé, vi que la matriz está funcionando correctamente pero la incursión no

Quiero decir que las unidades individuales están particionadas (tipo de partición f8) pero el md0dispositivo no. Dándome cuenta con horror de lo que he hecho, estoy tratando de encontrar algunas soluciones. Solo rezo para que --createno sobrescriba todo el contenido del disco duro.

¿Podría ALGUIEN ayudarme con esto? Los datos que están en el disco son muy importantes y únicos ~ 10 años de fotos, documentos, etc.

¿Es posible que al especificar los discos duros participantes en un orden incorrecto pueda mdadmsobrescribirlos? Cuando lo hago

mdadm --examine --scan 

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

Curiosamente, el nombre solía ser 'raid' y no el host host con: 0 agregado.

Aquí están las entradas de configuración 'desinfectadas':

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

Según las sugerencias, limpié los superbloques y volví a crear la matriz con --assume-cleanopción, pero sin suerte.

¿Existe alguna herramienta que me ayude a revivir al menos algunos de los datos? ¿Alguien puede decirme qué y cómo hace mdadm --create cuando se sincroniza para destruir los datos y poder escribir una herramienta para deshacer lo que se hizo?

Después de la recreación de la incursión ejecuto fsck.ext4 / dev / md0 y aquí está la salida

root @ tanserv: / etc / mdadm # fsck.ext4 / dev / md0 e2fsck 1.41.14 (22-dic-2010) fsck.ext4: Superblock no válido, intentando bloques de respaldo ... fsck.ext4: Número mágico incorrecto en super- bloquear al intentar abrir / dev / md0

El superbloque no se pudo leer o no describe un sistema de archivos ext2 correcto. Si el dispositivo es válido y realmente contiene un sistema de archivos ext2 (y no swap o ufs o algo más), entonces el superbloque está dañado, y puede intentar ejecutar e2fsck con un superbloque alternativo: e2fsck -b 8193


Por sugerencia de Shanes intenté

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 ejecute fsck.ext4 con cada bloque de respaldo, pero todos devolvieron lo 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!

Brigadieren
fuente
1
Quizás algún día la gente se dé cuenta de por qué RAID5 es una idea terrible. Hasta entonces, 1) las personas perderán datos. 2) Recibiremos preguntas como estas.
Tom O'Connor
11
@ Tom O'Connor ... porque claramente, RAID5 tiene la culpa del error del usuario. : rolleyes:
Reality Extractor
2
Con suerte, la respuesta de Shane puede guardar los datos, pero, una vez más, prueba por qué RAID por sí solo no es lo mejor para el almacenamiento. Necesita copias de seguridad también. (pero +1 para la pregunta y la respuesta épica que resultó)
tombull89
44
Sé que se repite a menudo, pero la incursión no es una solución de respaldo . El mensaje realmente necesita conducir a casa.
Sirex

Respuestas:

89

Ok, algo me estaba molestando sobre tu problema, así que encendí una máquina virtual para sumergirme en el comportamiento que debería esperarse. Llegaré a lo que me estaba molestando en un minuto; primero déjame decir esto:

¡Haga una copia de seguridad de estas unidades antes de intentar algo!

Es posible que ya haya hecho daño más allá de lo que hizo la resincronización; ¿Puedes aclarar a qué te referías cuando dijiste:

Según las sugerencias, limpié los superbloques y volví a crear la matriz con la opción --assume-clean, pero sin suerte.

Si ejecutaste un mdadm --misc --zero-superblock, entonces deberías estar bien.

De todos modos, busque algunos discos nuevos y tome imágenes actuales exactas de ellos antes de hacer cualquier cosa que pueda escribir más en estos discos.

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

Dicho esto ... parece que los datos almacenados en estas cosas son sorprendentemente resistentes a las desincronizaciones rebeldes. Siga leyendo, hay esperanza, y este puede ser el día en que llegue al límite de longitud de respuesta.


El mejor escenario

Creé una máquina virtual para recrear su escenario. Las unidades tienen solo 100 MB, por lo que no esperaría para siempre en cada resincronización, pero de lo contrario, esta debería ser una representación bastante precisa.

Construyó la matriz de la manera más genérica y predeterminada posible: trozos de 512k, diseño simétrico a la izquierda, discos en orden de letras ... 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 aquí todo bien; hagamos un sistema de archivos y agreguemos algunos datos.

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

Okay. Tenemos un sistema de archivos y algunos datos ("datos" datafiley 5 MB de datos aleatorios con ese hash SHA1 randomdata); Veamos qué sucede cuando hacemos una recreación.

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 terminó muy rápidamente con estos pequeños discos, pero ocurrió. Así que esto es lo que me estaba molestando de antes; su fdisk -lsalida No tener una tabla de particiones en el mddispositivo no es un problema, se espera. Su sistema de archivos reside directamente en el dispositivo de bloque falso 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 mesa de partición. Pero...

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

Sistema de archivos perfectamente válido, después de una resincronización. Entonces eso es bueno; Vamos a ver 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 corrupción de datos en absoluto! Pero esto es exactamente con la misma configuración, por lo que nada se asignó de manera diferente entre los dos grupos RAID. Dejemos caer esto antes de intentar romperlo.

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

Dando un paso atrás

Antes de intentar romper esto, hablemos 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 cualquier otro disco de la matriz. La paridad no solo se encuentra en un disco específico, sino que se gira alrededor de los discos de manera uniforme para distribuir mejor la carga de lectura a través de los discos en funcionamiento normal.

La operación XOR para calcular la paridad se ve así:

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

Entonces, la paridad se extiende 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 generalmente se realiza al reemplazar un disco muerto o faltante; también se realiza mdadm createpara garantizar que los datos en los discos se alineen con la apariencia de la geometría del RAID. En ese caso, el último disco en la especificación de la matriz es el que está 'sincronizado': todos los datos existentes en los otros discos se usan para la sincronización.

Entonces, todos los datos en el 'nuevo' disco se borran y se reconstruyen; ya sea construyendo nuevos bloques de datos a partir de bloques de paridad para lo que debería haber estado allí, o bien construyendo nuevos bloques de paridad.

Lo bueno es que el procedimiento para ambas cosas es exactamente el mismo: una operación XOR a través de los datos del resto de los discos. El proceso de resincronización en este caso puede tener en su diseño que cierto bloque debería ser un bloque de paridad, y pensar que está construyendo un nuevo bloque de paridad, cuando en realidad está recreando un bloque de datos antiguo. Entonces, incluso si cree que está construyendo esto:

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

... puede que solo se esté reconstruyendo a DISK5partir del diseño anterior.

Por lo tanto, es posible que los datos se mantengan consistentes incluso si la matriz está mal construida.


Lanzar un mono en las obras

(no una llave inglesa; todo el mono)

Prueba 1:

¡Hagamos la matriz en el orden incorrecto! sdc, entonces sdd, entonces 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 está muy bien. ¿Tenemos un sistema de archivos?

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>

No! ¿Porqué es eso? Porque si bien los datos están allí, están en el orden incorrecto; lo que una vez fue 512 KB de A, luego 512 KB de B, A, B, y así sucesivamente, ahora se ha barajado a B, A, B, A. El disco ahora parece incoherente para el verificador del sistema de archivos, no se ejecutará. La salida de mdadm --misc -D /dev/md1nos 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 debería verse así:

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

Entonces, eso está muy bien. Sobreescribimos un montón de bloques de datos con nuevos bloques de paridad esta vez. Vuelva a 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

¡Genial, todavía hay un sistema de archivos allí! ¿Aún tienes 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

¡Éxito!

Prueba 2

Ok, cambiemos el tamaño del fragmento y veamos si eso nos da algo de quiebre.

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í, está manguera cuando se configura así. Pero, ¿podemos recuperarnos?

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

¡Éxito otra vez!

Prueba 3

Este es el que pensé que mataría datos con seguridad, ¡hagamos un algoritmo de diseño diferente!

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: ¡cree que encontró algo y quiere arreglarlo! Ctrl+ C!

Clear<y>? cancelled!

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

Ok, crisis evitada. Veamos si los datos siguen intactos después de volver a sincronizar con el diseño incorrecto:

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

¡Éxito!

Prueba 4

Probemos también que la reducción a cero del superbloque no es dañina 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. Las 4 pruebas anteriores, combinadas.

  • Orden de dispositivo incorrecta
  • Tamaño de trozo incorrecto
  • Algoritmo de diseño incorrecto
  • Superbloques a cero (haremos esto 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

Guau.

Por lo tanto, parece que ninguna de estas acciones corrompió los datos de ninguna manera. Me sorprendió bastante este resultado, francamente; Esperaba probabilidades moderadas de pérdida de datos en el cambio de tamaño del fragmento, y alguna pérdida definitiva en el cambio de diseño. Aprendí algo hoy.


Entonces ... ¿Cómo obtengo mis datos?

Toda la información que tenga sobre el antiguo sistema le sería extremadamente útil. Si conoce el tipo de sistema de archivos, si tiene copias antiguas de su /proc/mdstatinformación sobre el orden de la unidad, el algoritmo, el tamaño del fragmento y la versión de metadatos. ¿Tiene configuradas las alertas de correo electrónico de mdadm? Si es así, encuentre uno viejo; si no, verifique /var/spool/mail/root. Verifique ~/.bash_historysi su construcción original está allí.

Entonces, la lista de cosas que debes hacer:

  1. ¡Haga una copia de seguridad de los discos ddantes de hacer nada!
  2. Intente con fsckel md activo actual: es posible que haya compilado en el mismo orden que antes. Si conoce el tipo de sistema de archivos, eso es útil; usa esa fsckherramienta específica . Si alguna de las herramientas ofrece arreglar algo, ¡no lo deje a menos que esté seguro de que realmente ha encontrado el sistema de archivos válido! Si hay fsckofertas para arreglar algo por usted, no dude en dejar un comentario para preguntar si realmente está ayudando o si está a punto de destruir datos.
  3. Intente construir la matriz con diferentes parámetros. Si tienes un viejo /proc/mdstat, puedes imitar lo que muestra; si no, entonces estás un poco a oscuras: probar todas las diferentes órdenes de manejo es razonable, pero es inútil verificar cada tamaño de fragmento posible con cada orden posible. Para cada uno, fsckpara ver si obtienes algo prometedor.

Entonces, eso es todo. Perdón por la novela, siéntase libre de dejar un comentario si tiene alguna pregunta, ¡y buena suerte!

nota al pie: menos de 22 mil caracteres; 8k + menos del límite de longitud

Shane Madden
fuente
8
Esa es una respuesta asombrosa.
Antoine Benkemoun
3
Ni siquiera sé qué decir ... BRAVO !!! Felicitaciones a Shane Madden. Voy a hacer una copia de seguridad de los discos y comenzaré con sus sugerencias. Gracias, no realmente muchas gracias !!!
Brigadieren
3
Yo solo ... wow. Brillante respuesta. Creo que la única respuesta para romper el límite de 30,000 caracteres es el ensayo de Evan Anderson "Cómo funciona la división en subredes".
tombull89
3
La mejor respuesta en SF en lo que a mí respecta.
Chopper3
14
Usted, señor, gane internet.
Mark Henderson
5

Si tiene suerte , podría tener algo de éxito al recuperar sus archivos con un software de recuperación que puede leer una matriz RAID-5 rota. La recuperación de la suposición cero es una con la que he tenido éxito anteriormente.

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

Mark Henderson
fuente
Muchas gracias Mark. Voy a darle una oportunidad. ¿Sabes si modifica las unidades? Si es así, haré una copia del disco y también intentaré con otras herramientas.
Brigadieren
@ Brigadieren: no, lo siento, no estoy lo suficientemente familiarizado con las complejidades de cómo funciona RAID5.
Mark Henderson
@Brigadieren De acuerdo con la documentación de mdadm , el proceso de creación no destruirá datos, solo resincroniza, pero si se elige una geometría que no coincida con su original, entonces puede haber destruido datos con la escritura de una nueva paridad. Si tengo algo de tiempo libre más adelante, podría ver cómo volver a crear su situación en una máquina virtual, para ver si puedo agregar alguna información. Recomiendo tomar copias completas de las unidades antes de intentar cualquier paso de recuperación que escriba en los discos, es posible que desee obtener unidades adicionales para hacer copias.
Shane Madden
Simplemente no estoy seguro de qué causó la sincronización: el hecho de que la matriz se degradó en primer lugar (debido a un corte de energía) o algo más. Me pregunto si mdadm --create hace alguna distinción si especifico el orden de la unidad de manera diferente a la que se dio originalmente.
Brigadieren
@Brigadieren La sincronización siempre ocurre en crear.
Shane Madden
5

Tuve un problema similar:
después de una falla de una matriz RAID5 de software, disparé mdadm --createsin darla --assume-cleany ya no pude montar la matriz. Después de dos semanas de excavación, finalmente restauré todos los datos. Espero que el siguiente procedimiento le ahorre tiempo a alguien.

Larga historia corta

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

  • diferente orden de particiones
  • Diferente desplazamiento de datos RAID

Como se ha demostrado en la brillante respuesta de Shane Madden , ¡ mdadm --createno destruye los datos en la mayoría de los casos! Después de encontrar el orden de partición y el desplazamiento de datos, pude restaurar la matriz y extraer todos los datos de ella.

Prerrequisitos

No tenía copias de seguridad de los superbloques RAID, así que todo lo que sabía era que era una matriz RAID5 en 8 particiones creadas durante la instalación de Xubuntu 12.04.0. Tenía un sistema de archivos ext4. Otro conocimiento importante era una copia de un archivo que también estaba almacenado en la matriz RAID.

Herramientas

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

versión de mdadm que permite especificar el desplazamiento de datos

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

bgrep - buscando datos binarios

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

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

Comience con copia de seguridad completa

La asignación de nombres a los archivos del dispositivo, por ejemplo, /dev/sda2 /dev/sdb2etc., no es persistente, por lo que es mejor anotar los números de serie de sus unidades dados por

sudo hdparm -I /dev/sda

Luego conecte un HDD externo y haga una copia de seguridad de cada partición de su matriz RAID de esta manera:

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

Determinar el diseño RAID5 original

Aquí se describen varios diseños: http://www.accs.com/p_and_p/RAID/LinuxRAID.html
Para encontrar cómo se organizaron las tiras de datos en la matriz original, necesita una copia de un archivo de aspecto aleatorio que sabe que era almacenado en la matriz. El tamaño de fragmento predeterminado utilizado actualmente mdadmes 512 KB. Para una matriz de N particiones, necesita un archivo de tamaño mínimo (N + 1) * 512 KB. Un jpeg o video es bueno ya que proporciona subcadenas relativamente únicas de datos binarios. Supongamos que se llama nuestro archivo picture.jpg. Leemos 32 bytes de datos en N + 1 posiciones comenzando desde 100k e incrementándose en 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
...

Luego buscamos las ocurrencias de todas estas cadenas de bytes en todas nuestras particiones en bruto, por lo 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 para diferentes discos. El escaneo de una partición de 38GB tomó alrededor de 12 minutos. En mi caso, cada cadena de 32 bytes se encontró solo una vez entre las ocho unidades. Al comparar las compensaciones devueltas por bgrep, obtiene 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 un diseño simétrico a la izquierda normal , que es el predeterminado mdadm. Más importante aún, ahora sabemos el orden de las particiones. Sin embargo, no sabemos qué partición es la primera en la matriz, ya que pueden desplazarse cíclicamente.

Tenga en cuenta también la distancia entre las compensaciones encontradas. En mi caso fue de 512 KB. El tamaño del fragmento puede ser más pequeño que esta distancia, en cuyo caso el diseño real será diferente.

Encuentra el tamaño original del trozo

Usamos el mismo archivo picture.jpgpara leer 32 bytes de datos a diferentes intervalos entre sí. Sabemos desde arriba que los datos en el desplazamiento 100k están /dev/sdh2en reposo, en el desplazamiento 612k está en /dev/sdb2, y en 1124k está en /dev/sdd2. Esto muestra que el tamaño del fragmento no es mayor que 512 KB. Verificamos que no sea más pequeño que 512 KB. Para esto volcamos la cadena de bytes en el desplazamiento 356k y miramos 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

Está en la misma partición que el offset 612k, lo que indica que el tamaño del fragmento no es de 256 KB. Eliminamos trozos más pequeños de la misma manera. Terminé con trozos de 512 KB como la única posibilidad.

Encuentra la primera partición en el diseño

Ahora sabemos el orden de las particiones, pero no sabemos qué partición debería ser la primera y qué desplazamiento de datos RAID se utilizó. Para encontrar estas dos incógnitas, crearemos una matriz RAID5 con el diseño correcto de fragmentos y un pequeño desplazamiento de datos, y buscaremos el inicio de nuestro sistema de archivos en esta nueva matriz.

Para empezar, creamos una matriz con el orden correcto de particiones, que encontramos 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

Verificamos que la orden se obedece emitiendo

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 determinamos las compensaciones de las cadenas de bytes conocidas N + 1 en la matriz RAID. Ejecuto un script por una noche (Live CD no pide contraseña en 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 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

En base a estos datos, vemos que no se encontró la tercera cadena. Esto significa que el fragmento en /dev/sdd2se utiliza para la paridad. Aquí hay una ilustración de las posiciones de paridad 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 desde qué partición comenzar la matriz, a fin de desplazar los trozos de paridad al lugar correcto. Como la paridad debe desplazarse dos trozos hacia la izquierda, la secuencia de partición debe desplazarse dos pasos hacia la derecha. Por lo tanto, el diseño correcto para este desplazamiento de datos 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, nuestra matriz RAID contiene datos en la forma correcta. Es posible que tenga suerte de que el desplazamiento de datos RAID sea el mismo que en la matriz original, y entonces lo más probable es que pueda montar la partición. Lamentablemente este no fue mi caso.

Verificar la consistencia de los datos

Verificamos que los datos sean consistentes en una tira de fragmentos extrayendo una copia de picture.jpgla matriz. Para esto, ubicamos el desplazamiento de la cadena de 32 bytes a 100k:

sudo ./bgrep DA1DC4D616B1C71079624CDC36E3D40E7B1CFF00857C663687B6C4464D6C77D2 /dev/md126

Luego restamos 100 * 1024 del resultado y usamos el valor decimal obtenido en el skip=parámetro para dd. El count=es el tamaño de picture.jpgen bytes:

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

Comprueba que extract.jpges lo mismo que picture.jpg.

Buscar compensación de datos RAID

Una nota al margen: el desplazamiento de datos predeterminado para la mdadmversión 3.2.3 es de 2048 sectores. Pero este valor ha cambiado con el tiempo. Si la matriz original utiliza un desplazamiento de datos más pequeño que el actualmdadm , a continuación, mdadm --createsin que --assume-cleanpueda sobrescribir el inicio del sistema de archivos.

En la sección anterior creamos una matriz RAID. Verifique qué compensación de datos RAID tenía al emitir algunas de las particiones individuales:

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

2048 sectores de 512 bytes es de 1 MB. Como el tamaño del fragmento es de 512 KB, el desplazamiento de datos actual es de dos fragmentos.

Si en este punto tiene un desplazamiento de dos partes, probablemente sea lo suficientemente pequeño y puede omitir este párrafo.
Creamos una matriz RAID5 con el desplazamiento de datos de un fragmento de 512 KB. Comenzar un trozo antes desplaza la paridad un paso hacia la izquierda, por lo tanto, compensamos desplazando la secuencia de partición un paso hacia la izquierda. Por lo tanto, para el desplazamiento de datos de 512 KB, el diseño correcto es hbdcefga. Utilizamos una versión mdadmque admite el desplazamiento de datos (consulte la sección Herramientas). Se compensa 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 superbloque ext4 válido. La estructura del superbloque se puede encontrar aquí: https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout#The_Super_Block
Exploramos el comienzo de la matriz en busca de ocurrencias del número mágico s_magicseguido de s_statey s_errors. Las cadenas de bytes 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 bytes en el superbloque, por lo que restamos 0x38 para calcular el desplazamiento y examinar todo el 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                              

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

Ahora buscamos las ocurrencias de los primeros bytes del superbloque para encontrar sus copias. Tenga en cuenta el byte volteado en comparación con la salida 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

Esto se alinea perfectamente con las posiciones esperadas de los superbloques de respaldo:

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 comienza en el desplazamiento 0xdc80000, es decir, 225792 KB desde el inicio de la partición. Como tenemos 8 particiones, una de las cuales es por paridad, dividimos el desplazamiento por 7. Esto da un desplazamiento de 33030144 bytes en cada partición, que es exactamente 63 fragmentos RAID. Y dado que el desplazamiento de datos RAID actual es un fragmento, concluimos que el desplazamiento de datos original fue de 64 fragmentos, o 32768 KB. Cambiar hbdcefga63 veces a la derecha da el diseñobdcefgah .

Finalmente construimos la matriz RAID correcta:

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

Anton Stolbunov
fuente
Excelente tutorial. Una nota: 53EF00000100 no parece ser un ancla válida para el encabezado EXT4. De acuerdo con ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout#The_Super_Block, los dos bytes después de 53EF podrían ser solo 0100, 0200 o 0400.
mate
0

Tuve un problema similar. Formateé y reinstalé mi sistema operativo / unidad de arranque con una instalación limpia de Ubuntu 12.04, luego ejecuté el comando mdadm --create ... y no pude montarlo.

Dijo que no tenía un superbloque o partición válido.

Además, cuando detuve la incursión mdadm, ya no pude montar el dispositivo normal.

Pude 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

Eso restauró el superbloque para poder montar y leer la unidad.

Para que la matriz funcione sin destruir el superbloque o las particiones, utilicé build:

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

Después de verificar los datos, agregaré la otra unidad:

mdadm --add /dev/md0 /sdd1
Bob acto secundario
fuente
0

Solo estoy actualizando parte de la información proporcionada anteriormente. Tenía una matriz raid5 de 3 discos que funcionaba bien cuando murió mi placa base. La matriz contenía / dev / md2 como la partición / home 1.2TB y / dev / md3 como la partición / var 300GB.

Tenía dos copias de seguridad de cosas "importantes" y un montón de cosas aleatorias que había tomado de varias partes de Internet por las que realmente debería haber pasado y haber sido arrojado selectivamente. La mayoría de las copias de seguridad se dividieron en archivos .tar.gz de 25 GB o menos, y también se realizó una copia de seguridad de / etc.

El resto del sistema de archivos se mantuvo en dos discos raid0 pequeños de 38 GB.

Mi nueva máquina era similar al hardware anterior, y la puse en funcionamiento simplemente conectando los cinco discos y seleccionando un núcleo genérico antiguo. Así que tenía cinco discos con sistemas de archivos limpios, aunque no podía estar seguro de que los discos estuvieran en el orden correcto, y necesitaba instalar una nueva versión de Debian Jessie para asegurarme de que podía actualizar la máquina cuando fuera necesario, y resolver otros problemas.

Con el nuevo sistema genérico instalado en dos discos Raid0, comencé a volver a armar los arreglos. Quería asegurarme de tener los discos en el orden correcto. Lo que debería haber hecho fue emitir:

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

Pero no lo hice. Parece que mdadm es bastante inteligente y, dado un uuid, puede descubrir qué unidades van a dónde. Incluso si la BIOS designa / dev / sdc como / sda, mdadm lo juntará correctamente (aunque YMMV).

En su lugar mdadm --create /dev/md2 without the --assume-clean, emití: y permití que se completara la resincronización en / dev / sde1. El siguiente error que cometí fue trabajar en / dev / sdc1 en lugar de la última unidad en / dev / md2, / sde1. Cada vez que mdadm cree que hay un problema, es la última unidad que se expulsa o se vuelve a sincronizar.

Después de eso, mdadm no pudo encontrar ningún superbloque, y e2fsck -n tampoco.

Después de encontrar esta página, realicé el procedimiento de tratar de encontrar la secuencia de las unidades (hecho), verifiqué los datos válidos (verificó 6 MB de un archivo de 9 MB), obtuve los discos en la secuencia correcta, cde, tomé el uuid de / md2 y / md3 del antiguo /etc/mdadm.conf y trató de ensamblar.

Bueno, /dev/md3comenzó, y mdadm --misc -D /dev/md3mostró tres particiones saludables, y los discos en el orden correcto. /dev/md2También se veía bien, hasta que intenté montar el sistema de archivos.

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

El sistema de archivos se negó a ser montado, y e2fsck no pudo encontrar ningún superbloque. Además, al verificar los superbloques como se describió anteriormente, el recuento total de bloques encontrado como a880 0076 o a880 0076 o 5500 1176 no coincidía con el tamaño de capacidad de disco de 1199.79 informó mi mdadm. Además, ninguna de las ubicaciones de los "superbloques" se alineó con los datos en las publicaciones anteriores.

Realicé una copia de seguridad de / var y me preparé para limpiar los discos. Para ver si era posible borrar solo / md2, (no tenía nada más que perder en este momento), hago lo siguiente:

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

Todo parecía estar bien, excepto el cambio a la uuid. Entonces, después de un par de verificaciones más, escribí 600GB de datos respaldados en / dev / md2. Luego, desmontó e intentó volver a montar la unidad:

# 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

¿Me estás tomando el pelo? ¿Qué pasa con mis 600 GB en el archivo?

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

Ah, fácil de arreglar. una línea sin comentarios en /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!

rd.olivaw
fuente