Descripción
Tengo una matriz IMSM RAID 5 que contiene 6 unidades SSD. Una de las unidades falló hace unos meses y aún no pude reemplazarla. (Sí, sé que a veces soy vago. Por favor, no me juzguen). Pero ya lo eliminé del RAID.
Sin embargo, ayer parece que otro disco falló. La matriz no se ensambla. Dado que ni siquiera el BIOS puede construir el RAID, no puedo iniciar nada. Sin embargo, tras una inspección más cercana, parece que el disco está bien. Puedo acceder a él y hacer copias de seguridad usando dd. Pero ahora parece tener un registro MBR al principio. ¿Quizás algún proceso sobrescribió el superbloque RAID con una tabla MBR? Si ese es el caso, los datos aún deberían estar ahí. Solo necesito poder decir mdadmlos metadatos correctos. Cuando lo pienso, podría haberle sucedido lo mismo al primer disco que supuestamente "falló". Ya que todavía era legible también. Pero no me molesté en investigar en aquel entonces.
No obstante, ahora estoy tratando de encontrar una manera de volver a ensamblar la matriz para acceder a sus datos (si es posible). Conozco el tamaño del fragmento, el orden exacto de las unidades y el nivel de RAID. ¿No debería ser suficiente información?
Alguna información
Lo primero que hice fue crear imágenes de las 5 unidades restantes usando dd(llamado sd[a-e].backup). También examiné todas las unidades utilizadas --examiney guardé el resultado. Puedes leer el resultado enesta esencia. Como puede ver allí, mdadm lee el encabezado MBR sdby pasa a la siguiente unidad sin detectar ninguna información RAID. Sin embargo, para todas las demás unidades, mdadm imprime los metadatos correctos. Mientras estamos en ello, aquí está el resultado decat /proc/mdstat
Personalities:
md127 : inactive sda[3](S) sdd[2](S) sde[1](S) sdc[0](S)
13049 blocks super external:imsm
unused devices: <none>
lo que intenté
- Obviamente intenté "apagarlo y volverlo a encender":
# mdadm --stop /dev/md127
mdadm: stopped /dev/md127
# mdadm --assemble /dev/md0 /dev/sdb missing /dev/sda /dev/sdc /dev/sde /dev/sdd
mdadm: Cannot assemble mbr metadata on /dev/sdb
mdadm: /dev/sdb has no superblock - assembly aborted
# mdadm --assemble --scan
Después de la última llamada a mdadm, /proc/mdstatnuevamente parece idéntico al resultado anterior.
Luego creé dispositivos de bucle de solo lectura:
# losetup --show -rf /mnt/backup/sdX.backup
[...]
# losetup -a
/dev/loop1: [...] (/mnt/backup/sda.backup)
/dev/loop2: [...] (/mnt/backup/sdb.backup)
/dev/loop3: [...] (/mnt/backup/sdc.backup)
/dev/loop4: [...] (/mnt/backup/sdd.backup)
/dev/loop5: [...] (/mnt/backup/sde.backup)
- A continuación intenté utilizarlo,
--buildya que no requiere ninguna información de superbloque y todos los metadatos se pueden proporcionar manualmente:
# mdadm --build /dev/md0 --raid-devices=6 --level=5 --chunk=32 /dev/loop2 missing /dev/loop1 /dev/loop3 /dev/loop5 /dev/loop4
mdadm: Raid level 5 not permitted with --build
Pero aparentemente no puedo usarlo --builden el contexto de RAID de nivel 5.
- Lo siguiente que intenté fue usar
--assemblepero sin usar la información OROM sobre el RAID.
# IMSM_NO_PLATFORM=1 mdadm --assemble /dev/md0 /dev/loop2 missing /dev/loop1 /dev/loop3 /dev/loop5 /dev/loop4
mdadm: Cannot assemble mbr metadata on /dev/loop2
mdadm: /dev/loop2 has no superblock - assembly aborted
Supongo que habría sido demasiado fácil. ¿Puedo de alguna manera decirle a mdadm que asuma que loop2es el primer dispositivo en esa matriz y use los metadatos de las otras unidades?
- Lo último que habría intentado es volver a montar los dispositivos de bucle como lectura-escritura y recrear la matriz. Sin embargo, todos los ejemplos que he encontrado (como ésteoÉste) asume que la matriz se creó con mdadm. Pero no fue así. Inicialmente fue creado por una utilidad en el BIOS y tiene el formato IMSM o Intel Rapid Storage. Supongo que debo tener conocimientos más detallados al respecto, como el diseño o la compensación de datos. No estoy seguro de cuáles son los valores predeterminados para IMSM ni dónde puedo encontrarlos. Pero lo más importante es que me preocupa que el formato de metadatos de mdadm utilice más espacio y un superbloque más grande que IMSM y sobrescriba los datos cuando guarda los metadatos. ¿Quizás también sea posible recrear la matriz usando IMSM? O tal vez sea posible almacenar los metadatos externamente. En pocas palabras, no tengo idea de cómo recrear manualmente una matriz IMSM con mdadm.
Otras preguntas sobre StackExchange
- Soy consciente deesta pregunta. Pero no estoy seguro de si esto se puede aplicar a mi situación ya que estoy usando IMSM que tiene diferentes superbloques (si es que tienen alguno).
- yo también he leídoesta pregunta. Sin embargo, se trata de RAID 0 y la respuesta sugiere usar
--buildlo que no funciona con RAID 5. - También soy consciente deÉste. Pero
--forceno es aplicable en mi situación ya que la unidad en cuestión no solo está marcada como fallida o no sincronizada. Y nuevamente no estoy seguro de cómo debo recrear la matriz específicamente con IMSM.
Respuesta1
Eureka - Introducción
Entonces descubrí cómo volver a acceder a mis datos. Lamentablemente no pude recrear la matriz usando mdadm. El problema es que con IMSM primero tengo que crear un contenedor. Pero el contenedor no acepta dispositivos extraviados. Necesitaría todos mis 6 discos duros originales, pero por el momento sólo tengo 5. Tampoco puedo utilizar ningún disco duro virtual porque es necesario conectarlo al controlador RAID. Además, no estoy seguro de cómo mdadmcomenzaría a sincronizar las unidades tan pronto como cree un volumen. Sin embargo, encontré una manera que implica dmsetup. Puedo acceder a todos mis archivos nuevamente.
Mientras realizaba múltiples copias de seguridad de las unidades para trabajar con ellas, también me di cuenta de que la única unidad que ya no forma parte de la matriz a veces falla con errores de E/S. Aún así pude hacer copias de seguridad ya que estos errores ocurrieron sólo aproximadamente una de cada tres invocaciones de dd. Supongo que tan pronto como ocurrió uno de los errores de IO, IMSM probablemente expulsó la unidad de la matriz y se eliminaron todos sus metadatos.
También me di cuenta de que esta unidad era la primera de la matriz. Como tengo una tabla GPT y como los datos del array empiezan en el primer sector también es lógico que empiece con un MBR. Entonces, el supersector de la unidad no se sobrescribió con un MBR. Siempre estuvo ahí.
leyendo los datos
Estoy tratando de brindar una solución paso a paso que explique todos los comandos utilizados en el proceso. Con suerte, esto ayudará a alguien.
(Opcional) Haga una copia de seguridad de todas las unidades.
Esto no es estrictamente necesario. Especialmente porque más adelante usaremos dispositivos de bucle de solo lectura. Sin embargo, estoy particularmente paranoico después de una falla importante en mi solución de almacenamiento. Por eso trato de evitar el uso de datos reales tanto como sea posible. Más allá de eso, el uso de los archivos de respaldo muestra que este método no requiere los discos duros originales ni el BIOS en absoluto. Todo lo que necesitas es una imagen dd. Si se salta esta sección, asegúrese de crear realmente los dispositivos de bucle en la siguiente sección como de solo lectura o puede correr el riesgo de que sus datos se degraden aún más y se pierdan para siempre.
Sin embargo, aquí está el comando para hacer una copia de seguridad de su disco duro. Quizás ya estés familiarizado con dd. Pero en caso de que no esté ejecutando este comando para cada disco duro que forma parte de su matriz:
# dd if=/dev/sdX of=/path/to/backups/sdX.img status=progress
# dd if=/dev/sdY of=/path/to/backups/sdY.img status=progress
# [...]
El archivo de entrada if=/dev/sdXes su disco duro. Reemplace sdXcon sda, sdb, etc. El archivo de salida of=/path/to/backups/sdX.imgapunta a la imagen que se escribirá. Nuevamente reemplace sdXapropiadamente. status=progresssimplemente le dice a la versión GNU de dd que imprima el progreso actual en stderr.
Crear dispositivos de bucle
A continuación vamos a crear dispositivos de bucle. En caso de que estemos utilizando imágenes de respaldo, garantiza que se reconozcan como archivos de bloque. Aunque esto puede no ser necesario. Pero en cualquier caso asegura que la imagen solo será leída ya que estamos usando la bandera de solo lectura.-r
# losetup --show -rf /path/to/backups/sdX.img
# losetup --show -rf /path/to/backups/sdY.img
[...]
-r: solo lee del archivo, no escribas en él-f: utilice el siguiente número disponible para el dispositivo de bucle para que no tengamos que adivinarlo nosotros mismos.--show: imprime el nombre que-frealmente elijas. Esto suele ser bastante útil. Aunque de todos modos imprimiremos estos valores en el siguiente paso.
Para obtener una buena descripción general de los dispositivos de bucle que acabamos de crear, podemos usar el siguiente comando:
# losetup -a
/dev/loop1: [2129]:251265027 (/path/to/backups/sdX.img)
/dev/loop2: [2129]:251265027 (/path/to/backups/sdY.img)
[...]
Intente recordar qué dispositivo de bucle pertenece a qué imagen.
Recopilando algunos metadatos
A continuación necesitamos encontrar alguna información sobre el RAID. Específicamente necesitamos averiguar en qué sector comienza el RAID (especialmente en el caso de un RAID matricial), cuántos sectores abarca, cuál es el tamaño y diseño de su fragmento y en qué orden se agregaron las unidades al conjunto.
Si hay al menos una unidad que todavía forma parte de la matriz y tiene metadatos adjuntos, puede usarla para recuperar la mayor parte de la información necesaria. Ejecute el siguiente comando en una unidad sdXque todavía forma parte de la matriz:
# mdadm --examine /dev/sdX
/dev/sdX:
Magic : Intel Raid ISM Cfg Sig.
Version : 1.3.00
Orig Family : aa0b2c12
Family : 48d867fb
Generation : 0018f99c
Attributes : All supported
UUID : 0312fa14:fa8db3c2:2a76dc3f:299ed5b4
Checksum : 084869b8 correct
MPB Sectors : 6
Disks : 6
RAID Devices : 1
Disk02 Serial : S21PNSBG710576N
State : active
Id : 00000000
Usable Size : 488391936 (232.88 GiB 250.06 GB)
Bad Block Management Log:
Log Size : 2040
Signature : abadb10c
Entry Count : 254
[NameOfYourArray]:
UUID : 24b1e785:14f37ee5:41f6a4ab:d8b89e11
RAID Level : 5
Members : 6
Slots : [__UUUU]
Failed disk : 1
This Slot : 2
Sector Size : 512
Array Size : 2441959424 (1164.42 GiB 1250.28 GB)
Per Dev Size : 488392200 (232.88 GiB 250.06 GB)
Sector Offset : 0
Num Stripes : 7631124
Chunk Size : 32 KiB
Reserved : 0
Migrate State : idle
Map State : failed
Dirty State : clean
RWH Policy : off
La salida continúa, pero puedes ignorar el resto. El resultado que se muestra arriba proporciona la siguiente información valiosa:
Sector Offset : 0 # Where the data starts
# (right at the first sector in my case)
Array Size : 2441959424 # Size of the volume (data) inside the array
Chunk Size : 32 KiB # Size of a single chunk
Incluso puede determinar en qué parte de su matriz se encuentra esa unidad en particular.
This Slot : 2
Esto significa que ésta es la tercera unidad de la matriz. (El número de ranura comienza en cero). Alternativamente, Disk## Serial : [...]también indica el número de ranura:
Disk02 Serial : S21PNSBG710576N
Ejecute este comando para todas las unidades. Para aquellos que aún arrojan resultados válidos, anote el número de ranura.
Hay otro truco que puede utilizar para determinar la primera unidad de la matriz. Dado que el RAID está escrito en fragmentos y no en bytes, los primeros 32 kiB residen en la primera unidad. El segundo 32 kiB en el segundo disco y así sucesivamente. Esto significa que la primera unidad debe tener suficientes sectores que contengan el inicio de su tabla de particiones. Lo que significa que debería haber un MBR al inicio (incluso cuando estás usando GPT, ya que comienza con un MBR protector). mdadm --examineya te dice que encontró un MBR cuando no hay metadatos. Pero también puedes usar fdisk -l.
En mi caso pude averiguar los números de ranura de cuatro unidades a través de sus metadatos. Tuve suerte de que la quinta unidad contenía un MBR, por lo que automáticamente supe que era la primera. 5 de 6 unidades son suficientes para iniciar la matriz. Si no conoce los números exactos de ranuras de suficientes unidades, puede intentar utilizar diferentes permutaciones hasta que este método tenga éxito.
Lo que significa que el orden correcto de mis unidades y por tanto de mis dispositivos de bucle es:
| Ranura | Conducir | Dispositivo de bucle |
|---|---|---|
| MBR (0) | /dev/sdb | /dev/bucle2 |
| 1 | desaparecido | - |
| 2 | /dev/sda | /dev/bucle1 |
| 3 | /dev/sdc | /dev/loop3 |
| 4 | /dev/sde | /dev/loop5 |
| 5 | /dev/sdd | /dev/loop4 |
Lo último que hay que resolver es el diseño. Lamentablemente mdadmno nos da información al respecto. Sin embargo, cuando echamos un vistazo aDefiniciones RAID de IntelParece que el diseño de RAID 5 siempre se deja asimétrico. No estoy seguro de si las matrices IMSM se pueden configurar con un diseño diferente, pero me parece poco probable. Si todo esto no funciona para usted, puede probar diferentes diseños. Echar un vistazoen la fuentepara leer más sobre los otros diseños.
A continuación se muestra una descripción general de todos los niveles de RAID que admite IMSM. La palabra clave dmsetup se utiliza en el siguiente capítulo.
| Nivel de RAID | Disposición | sintaxis dmsetup |
|---|---|---|
| 0 | N / A | incursión0 |
| 1 | N / A | incursión1 |
| 5 | izquierda asimétrica | raid5_la |
| 10 | predeterminado (sin 1E ni copia) | incursión10 |
Si no puede recopilar metadatos de ninguna unidad, deberá adivinar valores y/o probar diferentes combinaciones. A modo de ayuda estos son los diferentes modos que soporta IMSM:
| Información | Valores posibles |
|---|---|
| Niveles de RAID | 0, 1, 5, 10 |
| Tamaños de trozos | 4 kiB, 8 kiB, 16 kiB, 32 kiB, 64 kiB, 128 kiB |
Para el sector de inicio y el tamaño, es mejor asumir cero y el tamaño de la unidad más pequeña de la matriz multiplicado por el número de unidades sin paridad si no está seguro. Puede obtener el tamaño en sectores de una unidad emitiendo el siguiente comando:
blockdev --getsize /dev/sdX
Si sus datos en realidad no comienzan en cero, aún puede obtener el desplazamiento correcto más adelantebuscando un encabezado de particióno tal vez incluso porbuscando sistemas de archivos.
Ensamblando la matriz usando dmsetup
Desafortunadamente, no hay forma de proporcionar los metadatos manualmente cuando estás usando mdadm. La única excepción es para elNiveles RAID 0 y 1 donde puedes usar--build:
mdadm --build /dev/md0 --raid-devices=2 --level=0 --chunk=32 /dev/loop0 /dev/loop1
Como no tenemos suerte aquí, necesitamos usar una herramienta diferente. Por lo tanto, vamos a utilizar dmsetupen su lugar. dmsetupes un comando que crea discos duros virtuales que se asignan a discos reales u otras fuentes. Estas asignaciones constan de varias secciones y cada sección se puede asignar a una unidad diferente. En nuestro caso sólo necesitamos una sección y estamos mapeando a un RAID cuyos metadatos proporcionaremos manualmente.
Pero primero tenemos que hablar de números. Como determinamos anteriormente, el tamaño del fragmento en mi caso fue de 32 kiB. Sin embargo dmsetuprequiere sectores. En casi todos los casos, un sector equivale a 512 bytes. Si quieres estar seguro, puedes comprobar el tamaño del sector con blockdev --getss /dev/sdX. En mi caso esto significa 32 kiB / (512 bytes/sector) = 64 sectors. Ya conocemos el tamaño de los datos en la matriz en sectores (es decir, 2441959424). Pero hay un problema. Tengo 6 dispositivos. Con un fragmento de paridad por franja, el número de fragmentos debe ser divisible por 5. Pero el número de sectores no es divisible por 5. En mi caso, al menos es divisible el número de sectores por fragmento. Pero ni siquiera estoy seguro de que eso esté garantizado. Parece que los datos se detienen a mitad de la última franja. Lamentablemente, dmsetup no tolerará esto. Eso significa que debemos redondear al número entero más cercano que sea divisible por 5 unidades y por 64 sectores (ajuste estos números según su situación). En mi caso, esto es: 2441959680. Esto significará que fdiskpuedo quejarme de un tamaño de unidad incorrecto y de que falta una tabla de respaldo. Pero podemos solucionarlo truncando la imagen dd.
Ahora cree un archivo (p. ej. table.txt) que contendrá una línea para una sección.
<start> <size> raid <raid layout> 2 <chunk size> nosync <num devices>[ - /dev/loopN|-]*num_devices
Primero hay que dar el inicio y el tamaño en sectores. El siguiente argumento dice que se trata de un RAID. Para conocer el diseño de RAID, consulte la tabla de la sección anterior. El "2" en el siguiente argumento significa dos parámetros especiales para el RAID. El primero es el tamaño del trozo. El segundo impedirá cualquier sincronización. Después de eso, debe describir sus unidades proporcionando primero la cantidad de dispositivos y luego un par de metadatos y una ruta de dispositivo para cada dispositivo. Como no queremos proporcionar ningún metadato, utilizamos un guión para indicarlo. Si falta el dispositivo escribimos dos guiones indicando que ni los metadatos ni el dispositivo están disponibles. Es recomendable dejar fuera al menos un dispositivo si el nivel RAID lo permite. Si ya sospecha que una unidad puede contener datos defectuosos, elija esa.
Por ejemplo, en mi caso el archivo tiene este aspecto. Tenga en cuenta que falta el segundo dispositivo.
0 2441959680 raid raid5_la 2 64 nosync 6 - /dev/loop2 - - - /dev/loop1 - /dev/loop3 - /dev/loop5 - /dev/loop4
Ahora ejecute el siguiente comando para crear un nuevo archivo de bloque que se asigne a nuestra matriz:
# dmsetup create sdr /path/to/table.txt
Esto puede generar un montón de errores de IO. En cuyo caso, el tamaño de los sectores probablemente no era divisible por el tamaño del fragmento. Puede eliminar el archivo de bloqueo para rehacer el último paso con el siguiente comando:
# dmsetup remove sdr
Ahora echemos un vistazo a este archivo de dispositivo recién creado. Si tu corres
# fdisk -l /dev/mapper/sdr
Deberías poder ver tu tabla de particiones. No te preocupes por los dos errores que aparecerán si tienes una tabla GPT. La discrepancia de tamaño y la falta de tabla de respaldo se deben al hecho de que elegimos un tamaño para nuestro RAID que es demasiado grande.
El mío se ve así:
Device Start End Sectors Size Type
/dev/mapper/sdr-part1 2048 923647 921600 450M Windows recovery environment
/dev/mapper/sdr-part2 923648 1128447 204800 100M EFI System
/dev/mapper/sdr-part3 1128448 1161215 32768 16M Microsoft reserved
/dev/mapper/sdr-part4 1161216 679840003 678678788 323.6G Microsoft basic data
/dev/mapper/sdr-part5 679841792 680902655 1060864 518M Windows recovery environment
/dev/mapper/sdr-part6 680904704 2295472127 1614567424 769.9G Linux filesystem
/dev/mapper/sdr-part7 2295472128 2441957375 146485248 69.9G Linux swap
Usando la columna de inicio y sectores de esta tabla podemos incluso montar algunas de estas particiones. Tenga en cuenta que todos los números están en sectores y deben convertirse a bytes multiplicándolos por 512.
# mount -o ro,noload,loop,offset=348623208448,sizelimit=826658521088 /dev/mapper/sdr /mnt
Lo que significa que mi partición de Linux ahora está montada en /mnt y puedo explorar todos mis archivos en romodo (es decir, de solo lectura). el noloades necesario paraevitar que ext4 realice operaciones de escritura.
Y ahora por fin realizaremos una copia de seguridad completa usando dd.
# dd if=/dev/mapper/sdr of=/path/to/backups/raid.img status=progress
¿Recuerdas cómo creamos un RAID que era un poco más grande de lo que debería ser? Podemos aprovechar esta oportunidad para corregir este error truncando la imagen a su tamaño correcto. El número de sectores debe convertirse a bytes: 2441959424*512 = 1250283225088.
# truncate -s 1250283225088 /path/to/backups/raid.img
Ahora fdisk -lya no se queja de que el tamaño no coincide.