raid1 恢复:数据恢复或 raid 重建,如何处理

raid1 恢复:数据恢复或 raid 重建,如何处理

我在尝试从以前的 raid1 驱动器恢复文件时遇到了问题。2e 驱动器不再存在,并且这次恢复中有一些我不希望丢失的值得纪念的文件。因此,在进一步操作之前,我已经这样做了,并寻求建议。

发生了什么事..我从运行 raid 1 系统的 2bay NAS(asustor as6102t)更换为 4bay NAS(asustor 6604t),目的是在我更换所有东西后通过空插槽备份重要数据(我知道这不是最好的选择,#1)。

为了“确保”我不会丢失任何数据,我将第一个驱动器放入新的 NAS 并安装了新的操作系统版本。

后来我得知我的新 NAS 可以选择将卷 1 安装到 SSD,这样 HD 就可以进入休眠状态,所以我选择了这种方式。最初我以为 SSD 只能用作缓存驱动器。

因此我仅使用 SSD 启动了系统,从而在 SSD 上创建了卷 1。由于驱动器 1 也有一个卷 1,因此它不再被识别为卷 1..不幸的是,当时我放入了两个旧驱动器,而 ADM 可能仍在同步 2e 驱动器以匹配第一个驱动器。

然后我意识到我只能在另一个驱动器上创建卷 2 后保存两个驱动器中的一个访问数据(第二个错误的选择 #2),并且就这样做了,才意识到当我关闭它时 ADM 仍在同步。(#3)然后我犯了有史以来最愚蠢的错误,我把错误的(读作仍然“健康”)驱动器放入 nas,而不是关闭时仍在同步的驱动器.. 以创建新的卷 2。

所以现在我被困在一个关闭的驱动器上,但可能仍在同步操作系统和信息。实际数据的信息应该没问题。但我怀疑这是无法区分的。

驱动器分区:

/dev/sdb1  unknown    (no-mountpoint)  (no -label)    255.00 MiB  
/dev/sdb2  linux-raid /dev/md126,      AS6102T-30B9:0   2.00 GiB  
/dev/sdb3  linux-raid (no-mountpoint)  Matts-Ator:126   2.00 GiB   
/dev/sdb4  linux-raid (no-mountpoint)  AS6102T-30B9:1   7.27 TiB 

我迄今为止尝试过的:

  • sudo-i
  • root@pop-os:~# mdadm --assemble --scan
    mdadm: Merging with already-assembled /dev/md/AS6102T-30B9:1
    mdadm: failed to add /dev/sdd4 to /dev/md/AS6102T-30B9:1: Device or resource busy
    mdadm: /dev/md/AS6102T-30B9:1 assembled from -1 drives and 1 rebuilding - not enough to start the array.
    mdadm: Merging with already-assembled /dev/md/Matts-ATor:126
    mdadm: failed to add /dev/sdd3 to /dev/md/Matts-ATor:126: Device or resource busy
    mdadm: /dev/md/Matts-ATor:126 assembled from -1 drives and 1 rebuilding - not enough to start the array.
    mdadm: Found some drive for an array that is already active: /dev/md/AS6102T-30B9:0
    mdadm: giving up.
    mdadm: No arrays found in config file or automatically
  • mount -f ext4 /dev/sdb1 /mnt/oldhd (也包括/sdb2,3,4)
    mount: bad usage
  • fdisk -l /dev/sdb
Disk /dev/sdb: 7.28 TiB, 8001563222016 bytes, 15628053168 sectors
Disk model:                 
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 80C9725B-EB84-4899-8631-58B4881864EC

Device       Start         End     Sectors  Size Type

    /dev/sdb1     2048      524287      522240  255M Linux filesystem
    /dev/sdb2   524288     4718591     4194304    2G Linux RAID
    /dev/sdb3  4718592     8912895     4194304    2G Linux RAID
    /dev/sdb4  8912896 15628052479 15619139584  7.3T Linux RAID
  • 文件-s /dev/sdb1
/dev/sdb1: data
  • 文件-s /dev/sdb2
/dev/sdb2: Linux Software RAID version 1.2 (1) UUID=10a88f20:91ccdee6:ea11afed:9f053ae1 name=AS6102T-30B9:0 level=1 disks=4 !!!!
  • 文件-s /dev/sdb3
Linux Software RAID version 1.2 (1) UUID= c0fb0c9:11ec2f32:dc9646a1:dc1d1f06 name=Matts-ATor:126 level=1 disks=2
  • 文件-s /dev/sdb4
Linux Software RAID version 1.2 (1) UUID=807cfe7b:78c76a5f:  4f722d:fe27fe8b name=AS6102T-30B9:1 level=1 disks=2
  • 十六进制转储-C-n 32256 /dev/sdb
00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
000001b0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 20  |............... |
000001c0  21 00 83 a2 02 20 00 08  00 00 00 f8 07 00 00 00  |!.... ..........|
000001d0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
000001f0  02 00 ee 20 20 00 01 00  00 00 ff 07 00 00 55 aa  |...  .........U.|
00000200  45 46 49 20 50 41 52 54  00 00 01 00 5c 00 00 00  |EFI PART....\...|
00000210  c6 26 59 d2 00 00 00 00  01 00 00 00 00 00 00 00  |.&Y.............|
00000220  af 2a 81 a3 03 00 00 00  22 00 00 00 00 00 00 00  |.*......".......|
00000230  8e 2a 81 a3 03 00 00 00  5b 72 c9 80 84 eb 99 48  |.*......[r.....H|
00000240  86 31 58 b4 88 18 64 ec  02 00 00 00 00 00 00 00  |.1X...d.........|
00000250  80 00 00 00 80 00 00 00  db d7 ad b0 00 00 00 00  |................|
00000260  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000400  af 3d c6 0f 83 84 72 47  8e 79 3d 69 d8 47 7d e4  |.=....rG.y=i.G}.|
00000410  04 7c 37 51 c8 32 a3 43  b3 b7 d9 36 e8 ad b9 54  |.|7Q.2.C...6...T|
00000420  00 08 00 00 00 00 00 00  ff ff 07 00 00 00 00 00  |................|
00000430  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000480  0f 88 9d a1 fc 05 3b 4d  a0 06 74 3f 0f 84 91 1e  |......;M..t?....|
00000490  9f 20 9f 97 c1 07 15 47  81 75 00 ed 80 c0 9f c6  |. .....G.u......|
000004a0  00 00 08 00 00 00 00 00  ff ff 47 00 00 00 00 00  |..........G.....|
000004b0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000500  0f 88 9d a1 fc 05 3b 4d  a0 06 74 3f 0f 84 91 1e  |......;M..t?....|
00000510  c5 44 a7 a4 dc ec 3d 48  ae f9 8f 5a 66 c2 da cb  |.D....=H...Zf...|
00000520  00 00 48 00 00 00 00 00  ff ff 87 00 00 00 00 00  |..H.............|
00000530  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000580  0f 88 9d a1 fc 05 3b 4d  a0 06 74 3f 0f 84 91 1e  |......;M..t?....|
00000590  62 7d e4 a3 79 03 5f 4a  97 9e 9d 03 da a5 46 9d  |b}..y._J......F.|
000005a0  00 00 88 00 00 00 00 00  ff 27 81 a3 03 00 00 00  |.........'......|
000005b0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00007e00

任何关于如何进一步解决这个问题的想法都将不胜感激

提前致谢!

答案1

从那时起,我就尝试使用 r linux 进行数据恢复。扫描很顺利,但不幸的是 *.scn 文件无法正确加载。我联系了 r-linux 客户服务,他们回复得很快,信息也很详尽……但基本上说我需要再做一次扫描。

感觉不像是又一次 +10 小时的扫描,我再次搜索了选项,这次我找到了这个链接。

https://unix.stackexchange.com/questions/72279/how-do-i-recover-files-from-a-single-degraded-mdadm-raid1-drive-not-enough-to

读完之后我发现:

  • mdadm --检查 /dev/sdb4
  • losetup --find --show --read-only --offset $((262144*512)) /dev/sdb4 /dev/loop0
  • sudo mkdir /mnt/recovery
  • sudo mount -o ro /dev/loop0 /mnt/recovery

成功了,在哪里:

  • sbd4 是我的数据分区,
  • 262144 mdadm --examine 发现我的数据偏移量,
  • /dev/loop0 由 losetup 创建,具有正确的数据偏移量
  • /mnt/recovery 是我只可以读取的挂载点!挂载 /dev/loop0

希望这对其他人有帮助。

相关内容