☰

如何恢复数据 - 从软件 RAID1 - 两个驱动器上的 MBR 均丢失

tag-icon • tag-icon linux software-raid raid1 mbr
如何恢复数据 - 从软件 RAID1 - 两个驱动器上的 MBR 均丢失

我正在尝试恢复 raid1 阵列，两个磁盘都是 NVMe 闪存驱动器。

在漫长而糟糕的一天结束时，我做了一件非常愚蠢的事情 - 删除了每个 NVMe 驱动器的前 512 个字节 - 目的是禁用引导加载程序。结果我删除了分区数据以及 RAID 信息。我备份了这 512 个字节 - 但猜猜怎么着 - 我将它们备份到了相同的磁盘上，所以现在无法访问它们。

我使用 dd 将磁盘复制到另一个磁盘，然后开始尝试恢复数据 - 执行了 testdisk，找到了所有分区：

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]

我将此分区数据写入两个磁盘，并重新启动，但只有 /boot 分区（第一个）恢复。我尝试使用 mdadm 组装根分区（第三个），但失败了

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

我的计划是以某种方式从其中一个磁盘安装根分区，获取扇区备份，然后恢复所有内容。

但我无法挂载 /dev/nvme1n1p3，它失败了

# 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

如何才能访问 /dev/nvme0n1p3 中的文件？

更新：感谢 Peter Zhabin 的建议，我确实尝试恢复其中一个驱动器 /dev/nvme1n1 上的文件系统，并在 testdisk 的帮助下恢复分区：

我从另一台具有类似（但不完全相同）磁盘和分区的服务器获取了偏移量：

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

Fsck 抱怨错误的分区（或超级块），并给出了与驱动器上的内容非常接近的 FS 统计信息：

 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

但是，我无法挂载文件系统：

 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

接下来该做什么？感觉数据很接近了……

答案1

好吧，我终于成功恢复了 MBR。正如我上面提到的，我已经将两个 RAID 驱动器的 MBR 备份到驱动器本身。这是在 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

我认为可以在驱动器映像中查找 MBR 备份文件。我在与文件 mbrb.backup 类似的服务器上保存了 MBR 扇区，它有以下字符串：

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

由于我不知道如何在 512Gb 图像中查找带有空字节的字符串，因此我进行了 grep 搜索，查找单个字符串，就像在工作 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

我开始在原始驱动器中寻找这个字符串：

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

它发现了这个字符串有 20 多个偏移量。偏移量如下所示：

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

然后我用 dd 保存了它们，并用 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

得到了 20 多个文件，其中大多数都完全相似，也许有些是 GRUB 文件。然后我开始将它们与我从工作服务器保存的 MBR 进行比较。最后一个看起来非常相似。我已将其保存到损坏磁盘的 MBR 中：

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

用 testdisk 检查了一下，有趣的是，它抱怨分区错误，但其他一切看起来都很有希望：

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

所以我冒险将相同的 MBR 放入 /dev/nvme0n1 raid。重启后，md 设备恢复正常，我的数据也恢复了。这看起来是个奇迹。

相关内容