☰

从发生故障且可能部分被覆盖的 mdadm raid1 中恢复数据

tag-icon • tag-icon mdadm raid1 luks
从发生故障且可能部分被覆盖的 mdadm raid1 中恢复数据

我有一块故障硬盘（我们称之为sda），其中包含一个 1.5 TB 分区（我们称之为sda3）。还有另一块磁盘（sdb），也有一个 1.5 TB 分区（sdb1）。两者均曾是使用元数据版本 1.2 的 mdadm 1 级 RAID 的一部分。在这个 RAID 分区（我们称之为 id md5）内，有一个 LUKS 加密容器（我们称之为md5_uncrypted）。此容器应包含一个 ext4 分区。

大约在 2012 年 8 月 10 日的某个时间，我以某种方式重新启动了sdb1丢失的 RAID 阵列，甚至没有注意到这一点。昨天（三个月后）我想更换 RAID 时，我开始从中复制数据，sdb1直到我意识到它已经过期。所以我看了一下旧的sda3。我错误地运行了mdadm --create而不是mdadm --assemble重新启动md5，只sda3使用可用。因此，我忽略了所有警告并继续mdadm --create。cryptsetup不喜欢新 RAID 的内容。我实际上没有想到mdadm --create如果使用相同的元数据版本会损坏数据？好吧，显然它确实损坏了。

sda3我比较了和的前 20 MB sdb1，发现它们从大约 8 MB 开始相等。因此，我将 的前 8 MB 复制到sdb1(sda3我有 的前 20 MB 的旧备份sda3) 并尝试组装md5(仅使用单个驱动器sda3)。不幸的是，这给了我一个错误：

failed to add /dev/sdb1: Invalid argument

sdb1我还尝试在全新的mdadm --created上使用 LUKS 标头sda3，cryptsetup当然，它很高兴能做到，但它包含垃圾。

我的问题是：是否有机会恢复至少部分数据sda3？由于我有三个月前的状态，所以一切都有帮助，即使只是一个文件列表，或者一个带有修改日期的文件列表。

编辑：

# mdadm --examine /dev/sdb1
         Magic : a92b4efc
       Version : 1.2
   Feature Map : 0x0
    Array UUID : 76a25475:70aa881c:dd30cc93:bbae03b7
          Name : ubuntu:0
 Creation Time : Fri Mar 16 20:52:16 2012
    Raid Level : raid1
  Raid Devices : 2

Avail Dev Size : 2930272256 (1397.26 GiB 1500.30 GB)
    Array Size : 1465129848 (1397.26 GiB 1500.29 GB)
 Used Dev Size : 2930259696 (1397.26 GiB 1500.29 GB)
   Data Offset : 2048 sectors
  Super Offset : 8 sectors
         State : clean
   Device UUID : b9012482:afa502cf:7794f4fb:2a0da196

   Update Time : Wed Nov 21 20:51:51 2012
      Checksum : 4e54a07 - correct
        Events : 15003


  Device Role : Active device 1
  Array State : .A ('A' == active, '.' == missing)

# mdadm --examine /dev/sda3
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x0
     Array UUID : 54ea031e:42367512:b6a8675b:91f2cb6f
           Name : willow:5  (local to host willow)
  Creation Time : Wed Nov 21 18:03:35 2012
     Raid Level : raid1
   Raid Devices : 2

 Avail Dev Size : 2929999872 (1397.13 GiB 1500.16 GB)
     Array Size : 1464999744 (1397.13 GiB 1500.16 GB)
  Used Dev Size : 2929999488 (1397.13 GiB 1500.16 GB)
    Data Offset : 262144 sectors
   Super Offset : 8 sectors
          State : active
    Device UUID : 93c70c36:3cc540a5:13817695:bd4f327c

    Update Time : Wed Nov 21 18:03:35 2012
       Checksum : 321ddb3e - correct
         Events : 0


   Device Role : Active device 1
   Array State : .A ('A' == active, '.' == missing)

答案1

首先，如果您有备用硬盘，我强烈建议您镜像 sda3 并使用镜像进行操作。

除非最初创建阵列的版本和当前版本之间未指定的选项的默认值发生变化，否则使用相同选项的 mdadm --create 不会损坏数据。

您是否使用 mdadm --examine 比较了 sdb1 和 sda3 上的超级块？

除非您添加/更改/删除了密钥，否则 luks 标头应该相同。您是否尝试过将 luksHeaderBackup 从 sdb1 阵列恢复到 sda3 上创建的阵列？

sdb1 和 sda3 上 luks 标头 {'L','U','K','S',0xba,0xbe} 的不同偏移量将解释 luks 卷中的垃圾。

相关内容