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!
fuente
Respuestas:
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:
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.
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.
Hasta aquí todo bien; hagamos un sistema de archivos y agreguemos algunos datos.
Okay. Tenemos un sistema de archivos y algunos datos ("datos"
datafiley 5 MB de datos aleatorios con ese hash SHA1randomdata); Veamos qué sucede cuando hacemos una recreación.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 elmddispositivo no es un problema, se espera. Su sistema de archivos reside directamente en el dispositivo de bloque falso sin tabla de particiones.Sí, no hay mesa de partición. Pero...
Sistema de archivos perfectamente válido, después de una resincronización. Entonces eso es bueno; Vamos a ver nuestros archivos de datos:
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.
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í:
Entonces, la paridad se extiende entre los discos.
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:
... 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, entoncessdd, entoncessdb..Ok, eso está muy bien. ¿Tenemos un sistema de archivos?
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:Cuando debería verse así:
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:
¡Genial, todavía hay un sistema de archivos allí! ¿Aún tienes datos?
¡Éxito!
Prueba 2
Ok, cambiemos el tamaño del fragmento y veamos si eso nos da algo de quiebre.
Sí, sí, está manguera cuando se configura así. Pero, ¿podemos recuperarnos?
¡Éxito otra vez!
Prueba 3
Este es el que pensé que mataría datos con seguridad, ¡hagamos un algoritmo de diseño diferente!
Miedo y mal: ¡cree que encontró algo y quiere arreglarlo! Ctrl+ C!
Ok, crisis evitada. Veamos si los datos siguen intactos después de volver a sincronizar con el diseño incorrecto:
¡Éxito!
Prueba 4
Probemos también que la reducción a cero del superbloque no es dañina muy rápido:
Sí, no es gran cosa.
Prueba 5
Vamos a tirar todo lo que tenemos. Las 4 pruebas anteriores, combinadas.
¡Adelante!
¿El veredicto?
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:
ddantes de hacer nada!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 esafsckherramienta 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 hayfsckofertas 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./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
fuente
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.
fuente
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: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
bgrep - buscando datos binarios
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 porLuego conecte un HDD externo y haga una copia de seguridad de cada partición de su matriz RAID de esta manera:
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 archivopicture.jpg. Leemos 32 bytes de datos en N + 1 posiciones comenzando desde 100k e incrementándose en 512k: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:
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:
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: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:
Verificamos que la orden se obedece emitiendo
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 :):
Salida con comentarios:
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: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: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:Luego restamos 100 * 1024 del resultado y usamos el valor decimal obtenido en el
skip=parámetro paradd. Elcount=es el tamaño depicture.jpgen bytes:Comprueba que
extract.jpges lo mismo quepicture.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:
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ónmdadmque admite el desplazamiento de datos (consulte la sección Herramientas). Se compensa en kilobytes: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 des_stateys_errors. Las cadenas de bytes a buscar son:Comando de ejemplo:
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:
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:
Esto se alinea perfectamente con las posiciones esperadas de los superbloques de respaldo:
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:
Voilà!
fuente
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:
Luego corrió:
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:
Después de verificar los datos, agregaré la otra unidad:
fuente
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:
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ó, ymdadm --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.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:
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:
¿Me estás tomando el pelo? ¿Qué pasa con mis 600 GB en el archivo?
Ah, fácil de arreglar. una línea sin comentarios en /etc/mdadm.conf
Yippie!
fuente