1 votos

Cómo recuperar datos - de Software RAID1 - MBR se ha perdido en ambas unidades

Estoy tratando de recuperar raid 1, matriz, ambos discos son NVMe unidades flash.

Me hizo muy estúpido, cosa que en el final de la larga y mal día - borran los primeros 512 bytes de cada NVMe de la unidad - la intención fue la de desactivar el gestor de arranque. Resultó que borré la partición de datos así como la información de la banda. Hice copias de seguridad de los 512 bytes - pero ¿adivinen qué - les hice a los mismos discos, por lo que son inaccesibles ahora.

He hecho copias de los discos con dd en otro disco, y comenzó a intentar recuperar los datos ... hizo testdisk, que se encontró con todas las particiones:

Disk /dev/nvme0n1 - 512 GB / 476 GiB - CHS 488386 64 32
Current partition structure:
    Partition                  Start        End    Size in sectors

1 * Linux RAID               1   0  1 32737  63 32   67045376 [rescue:0]
2 P Linux RAID           32769   0  1 33280  63 32    1048576 [rescue:1]
3 P Linux RAID           33281   0  1 488257  63 32  931792896 [rescue:2]

Escribí esta partición de datos a disco, hizo un reinicio, pero sólo partición /boot - primera - recuperados. He intentado montar la partición root (tercero) con mdadm, pero no con

[Sun May 27 11:30:40 2018] md: nvme0n1p3 does not have a valid v1.2 superblock, not importing!
[Sun May 27 11:30:45 2018] md: nvme0n1p3 does not have a valid v1.2 superblock, not importing!
[Sun May 27 13:45:32 2018] md: nvme1n1p1 does not have a valid v1.2 superblock, not importing!
[Sun May 27 13:45:32 2018] md: nvme0n1p1 does not have a valid v1.2 superblock, not importing!
[Sun May 27 13:45:32 2018] md: nvme1n1p3 does not have a valid v1.2 superblock, not importing!
[Sun May 27 13:45:32 2018] md: nvme0n1p3 does not have a valid v1.2 superblock, not importing!

Mi plan era de alguna manera montar la partición root de uno de los discos, conseguir que el sector de la copia de seguridad y restaurar todo.

Pero no puedo mount /dev/nvme1n1p3, se produce un error

# mount /dev/nvme0n1p3  /mnt/arr2
mount: unknown filesystem type 'linux_raid_member'

# mount /dev/nvme0n1p3  /mnt/arr2 -t ext4
mount: /dev/nvme0n1p3 is already mounted or /mnt/arr2 busy

¿Qué se puede hacer para obtener acceso a los archivos en /dev/nvme0n1p3?

ACTUALIZACIÓN: Gracias a los consejos de Pedro Zhabin,, he intentado recuperar el sistema de ficheros en una de las unidades, /dev/nvme1n1, con particiones recuperados con la ayuda de testdisk:

Tomé desplazamiento desde otro servidor con similares (pero no idénticos) de discos y particiones:

 losetup --find --show --read-only --offset $((262144*512)) /dev/nvme1n1p3 

Fsck se quejaron por el mal de partición (o superbloque), y dio a FS estadísticas que se ve muy cerca de lo que estaba en la unidad:

 fsck.ext3 -n -v /dev/loop1

    e2fsck 1.43.3 (04-Sep-2016)
    Warning: skipping journal recovery because doing a read-only filesystem check.
    The filesystem size (according to the superblock) is 116473936 blocks
    The physical size of the device is 116441344 blocks
    Either the superblock or the partition table is likely to be corrupt!
    Abort? no

    /dev/loop1 contains a file system with errors, check forced.
    Pass 1: Checking inodes, blocks, and sizes
    Inode 26881053 extent tree (at level 2) could be narrower.  Fix? no

    Pass 2: Checking directory structure
    Pass 3: Checking directory connectivity
    Pass 4: Checking reference counts
    Pass 5: Checking group summary information
    Free blocks count wrong (20689291, counted=20689278).
    Fix? no

    Free inodes count wrong (25426857, counted=25426852).
    Fix? no


         3695703 inodes used (12.69%, out of 29122560)
           30256 non-contiguous files (0.8%)
             442 non-contiguous directories (0.0%)
                 # of inodes with ind/dind/tind blocks: 0/0/0
                 Extent depth histogram: 3616322/1294/3
        95784645 blocks used (82.24%, out of 116473936)
               0 bad blocks
              29 large files

         3510238 regular files
          107220 directories
               2 character device files
               0 block device files
              53 fifos
            1248 links
           78147 symbolic links (77987 fast symbolic links)
              39 sockets
    ------------
         3696947 files

Sin embargo, era incapaz de montar el sistema de ficheros:

 root@rescue /mnt/backups # mount -o ro /dev/loop1 /mnt/reco/
 mount: wrong fs type, bad option, bad superblock on /dev/loop1,
   missing codepage or helper program, or other error

Lo que se puede hacer a continuación? Se siente como si los datos están tan cerca...

0voto

qurashi Puntos 6

Bueno finalmente me las arreglé para restaurar el MBR. Como mencioné anteriormente, yo tenía una copia de seguridad del MBR del tanto de las unidades RAID - a las unidades de sí mismos. Fue hecho con la ayuda de comando dd:

dd if=/dev/nvme0n1 bs=512 count=1 of=nvme0n1.bootsector.backup
dd if=/dev/nvme1n1 bs=512 count=1 of=nvme1n1.bootsector.backup 

Pensé que sería posible buscar MBR archivos de copia de seguridad en la unidad de imágenes. He guardado MBR sectores en el servidor similar al archivo mbrb.copia de seguridad, y la cadena:

 "GRUB\20\0Geom\0Hard\20Disk\0Read\0\20Error"

Desde que lo hizo no logró cómo buscar la cadena con bytes nulos en 512 gb imagen, hice una búsqueda grep que se veía por las cuerdas, como este en el trabajo MBR:

#dd if=/dev/sdb of=mbrb.backup bs=512 count=1
#strings -t d mbr.backup | grep -4 -iE 'GRUB' | grep -4 'Geom' | grep -4 'Hard Disk' | grep -4 'Read' | grep -4 'Error'
392 GRUB
398 Geom
403 Hard Disk
413 Read
418  Error

Empecé a buscar esta cadena en el raw de la unidad:

#strings -t d /dev/nvme1n1 | grep -4 -iE 'GRUB' | grep -4 'Geom' | grep -4 'Hard Disk' | grep -4 'Read' | grep -4 'Error'

Y se encuentra a unos 20+ compensaciones con esta cadena. Los desplazamientos se veía así:

34368320904 GRUB
34368320910 Geom
34368320915 Hard Disk
34368320925 Read
34368320930  Error

34702932360 GRUB
34702932366 Geom
34702932371 Hard Disk
34702932381 Read
34702932386  Error

and some more results....

Que me salvó a todos de ellos con dd, calcula el número de bloque con bc:

bc 1.06.95
Copyright 1991-1994, 1997, 1998, 2000, 2004, 2006 Free Software Foundation, Inc.
This is free software with ABSOLUTELY NO WARRANTY.
For details type `warranty'.
34368320904/512
67125626

dd if=/dev/nvme1n1 of=recovery_file.34368320904 bs=512 skip=67125626 count=2

Tengo más de 20 archivos, la mayoría de ellos era exactamente similar, quizás un poco de GRUB archivos. Entonces empecé a comparar el MBR me salvó de que el servidor de trabajo. El último parecía muy similares. He guardado en el MBR del disco roto:

 dd if=recovery_file.475173835144 of=/dev/nvme1n1 bs=521 count=1

Comprobado con testdisk, curiosamente, se quejó de que las particiones estaban equivocados, pero todo lo demás se veía muy prometedor:

Disk /dev/nvme1n1 - 512 GB / 476 GiB - CHS 488386 64 32
Current partition structure:
 Partition                  Start        End    Size in sectors

 1 P Linux RAID               1   0  1 32768  63 32   67108864 [rescue:0]

Warning: Bad starting sector (CHS and LBA don't match)
 2 P Linux RAID           32769   0  1 33280  63 32    1048576 [rescue:1]

Warning: Bad starting sector (CHS and LBA don't match)
 3 P Linux RAID           33281   0  1 488385  21 16  932053680 [rescue:2]

Warning: Bad starting sector (CHS and LBA don't match)
No partition is bootable

Así que tomé el riesgo y poner la misma MBR para que el /dev/nvme0n1 raid. Después de reiniciar los dispositivos md subió y mis datos estaba de vuelta. Parece un milagro.

EnMiMaquinaFunciona.com

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

Powered by: