我尝试从 RAID-5 中删除 1 个 HDD,但出了问题,但我仍然希望能够恢复我的数据(事实上,我有所有备份,所以这只是一个mdadm
可能性问题)
我有一个 4 x 1 Tb RAID-5,其中一个磁盘开始显示大量重新分配_扇区_Ct,所以我决定删除它。
我做了什么:
mdadm --manage /dev/md0 --fail /dev/sdc
mdadm --manage /dev/md0 --remove /dev/sdc
尝试运行:
root@darkstar:/home/anton# mdadm --grow /dev/md0 --raid-devices=3 mdadm: this change will reduce the size of the array. use --grow --array-size first to truncate array. e.g. mdadm --grow /dev/md0 --array-size 1953262592
mdadm --grow /dev/md0 --array-size 1953262592
最后:
mdadm --grow /dev/md0 --raid-devices=3 --backup-file=/root/grow_md1.bak
现在重塑和恢复已完成,我无法访问我的/dev/md0(它没有安装),resize2fs /dev/md0
告诉首先运行e2fsck
,并e2fsck
告诉:
The filesystem size (according to the superblock) is 732473472 blocks
The physical size of the device is 488315648 blocks
Either the superblock or the partition table is likely to be corrupt!
另一方面,mdadm -D /dev/md0
告诉我们:
Array Size : 1953262592 (1862.78 GiB 2000.14 GB)
Used Dev Size : 976631296 (931.39 GiB 1000.07 GB)
这给我留下了一些希望,我的数据不会丢失。有人知道我应该做什么才能拥有有效的 3 x 1 Tb 磁盘 RAID-5 阵列吗?
答案1
你应该做的就是你的第一步
mdadm --manage /dev/md0 --fail /dev/sdc
此时,您的 RAID 5 阵列正在降级模式下运行,您可以更换新磁盘。
不幸的是,看起来你有被截断的您的阵列的有效大小从 2TB 到 1TB,从而破坏了文件系统的后半部分。幸运的是你说你有备份。
我有点疑惑。如果 RAID5 配置中有四个磁盘,您应该有 3TB 可用空间。但在没有看到结果的情况下,mdadm --examine
我不确定我还能为您提供什么。
答案2
你把顺序弄反了。
为了缩小,你第一的收缩文件系统 ( resize2fs
),然后第二次收缩块设备 ( mdadm
)。您所做的顺序对于扩大文件系统是正确的,但对于缩小文件系统则相反。
你已经毁掉了你的数据。要从中恢复,您首先要确认您的备份完好。然后对阵列进行 mkfs 并从备份中恢复。如果您的备份不好,您可能可以恢复文件系统第一个 2TB 上的文件。 (见下文)
PS:管理阵列的正常方式是,如果磁盘出现故障,则用相同容量或更大容量的磁盘替换该磁盘。mdadm --grow
不是处理磁盘故障的正常部分。
恢复
文件系统中原来的第 3 TB 已被覆盖;本质上,该空间现在用于奇偶校验。 (实际的扇区包含奇偶校验和从其他磁盘移动的数据的混合,这些扇区现在包含奇偶校验。)那部分数据永远消失了;如果缺乏(可能是理论上的)能够读取扇区先前内容的高成本方法,则无法恢复。
此外,ext4 并不保留文件系统开头的所有元数据;它分布在整个文件系统中。所以你也丢失了一堆元数据。重要的是,如果文件数据的任何部分或者元数据位于丢失的第三个中,该文件将无法访问。可以从第四个磁盘有限地恢复片段(该磁盘可能没有受到增长的影响,因为它当时失败了。)
第一步,也是最重要的一步,是购买 4TB 磁盘并使用它来制作文件系统的完整副本(映像)。然后,将 4 个原始磁盘放在一边。如果对原盘的可靠性有任何疑问,请进行第二复制并仅处理其中一份副本。您还需要额外的磁盘来复制恢复的文件,包括可能部分损坏的文件的多个副本。
现在您可以尝试恢复步骤在副本上。请注意,大多数这些操作都需要在新副本上完成 - 这些步骤具有破坏性,这是仅在副本上工作的众多原因之一。不要毁坏你的原件:
让我们
e2fsck -y /path/to/copy
做这件事吧。也许它会产生一些你可以安装的东西。继续这样做,复制文件。将副本扩展回原始大小(稀疏应该可以;
truncate -s
可以做到这一点)。然后它可能会安装(以只读方式执行)。复制你能复制的。卸下它,然后e2fsck -y
再次执行它的操作。再次安装并复制尽可能多的内容。运行 fsck
-y
并实际检查所有这些消息。例如,我希望它实际上可以让您选择当文件的部分数据位于丢失区域时要做什么(用 0 替换,删除文件)。也许它也提供了有关丢失元数据的选择。我会先做-y
,因为它会有一个很多向您提出的问题...如果您有旧的文件系统映像备份,请将您拥有的 2TB + 备份中缺少的 1TB 合并起来。
fsck
结果,看看是否可以从中获取任何其他文件。不过,恢复的文件损坏的风险相当高。使用扫描文件系统映像以查找数据模式的程序(例如,
photorec
查找 JPEG)。这是唯一不需要严格复制新副本的版本。理论上,“故障”磁盘 #4 的最后 1/3 中的 3/4 包含一些丢失的数据。如果您可以找出扇区/块映射(我当然不知道!),您可以从该磁盘将 ~250GB 复制回您的映像,然后重复所有上述恢复步骤以恢复其他文件。
请注意,所有这些恢复的文件可能已损坏(例如,块中充满 0 而不是数据)。如果您在某处有校验和,验证它们很容易,但否则是一个繁琐的手动过程。
我们有很多关于从损坏的文件系统中恢复数据的问题;只要你只处理副本您可以进行实验,而不会让您的数据面临进一步的风险。
答案3
总结删除设备的正确方法,首先将其标记为失败:
sudo mdadm /dev/md127 --fail /dev/sdc
估计文件系统收缩后的新大小:
sudo resize2fs -P /dev/md127
如果磁盘很大,您可能需要估计 resize2fs 命令在提交操作之前需要多长时间。看估计resize2fs收缩所需的时间 - 程序园了解详情。
缩小文件系统:
sudo resize2fs -p -M /dev/md127
验证文件系统:
sudo e2fsck -f /dev/md127
检查新的文件系统大小(请参阅如何查找文件系统的大小? - 询问Ubuntu):
sudo dumpe2fs -h /dev/md127 |& awk -F: '/Block count/{count=$2} /Block size/{size=$2} END{print count*size}'
通过尝试运行此命令并检查错误消息来估计 RAID5 阵列的新大小:
mdadm --grow --raid-devices=3 /dev/md127
验证文件系统足够小以适应。缩小块设备:
mdadm --grow /dev/md127 --array-size new_size
删除多余的设备:
mdadm --grow --raid-devices=3 /dev/md127 --backup-file /root/md127.backup
调整文件系统大小以占用所有可用空间:
resize2fs /dev/md127
正如 @roaima 指出的,设备出现故障并更换它是更常见的情况。这里提出的方法将要求您关闭实时系统,这通常是不可接受的。
也可以看看: