我的目标是将分区救援到文件(不需要完整磁盘复制,或创建可启动驱动器),然后安装该映像,并将文件夹移至我的文件系统上,放到新的 3 倍大的驱动器上。但我还想知道哪些特定文件已损坏。
我希望能够从 Synology DSM 运行命令,其中源驱动器和目标驱动器均已连接(均为 ext4 非 raid 基本卷)。我找不到 DSM 的 ddrutility 包,因此可以通过网络使用它(从 Parted Magic 启动,通过 smb 网络访问图像和映射文件),或者我需要了解如何使用填充模式ddrescue 指向这些文件。
我的救援行动方针:
- 安装 synocommunity 包SynoCli 磁盘工具
- 通过 USB 将损坏的硬盘连接到 Synology DS216+II
- 如果它显示为任何外部驱动器(USB 弹出),请立即通过 Web UI 卸载它
- 通过运行命令获取设备(即
sda
)和分区(即sda1
)名称以及物理扇区大小fdisk -l
- 确保它不在命令列出的任何安装中
mount
- 运行 ddrescue 第一遍,跳过可疑部分:
ddrescue -f -n /dev/sda1 /volume2/rescue/sda1_rescue.img
- 运行第二遍并重试 3 次并直接访问磁盘:
ddrescue -d -f -r3 /dev/sda1 /volume2/rescue/sda1_rescue.img /volume2/rescue/rescue.log
- 以某种方式找出图像内哪些文件已损坏(如果有任何坏块)
- 挂载镜像:
sudo mkdir /mnt/newfolder
mount /volume2/rescue/sda1_rescue.img /mnt/newfolder -o loop,ro
cp
或rsync
从内部/mnt/newfolder
到a的一切/volume2/salvaged folder
问题:
我将使用 SATA/USB3.0 适配器连接损坏的磁盘。难道就没有必要使用USB2.0而不是USB3.0吗?
-f 强制覆盖输出文件。
如果在我的情况下写入文件,我应该跳过此选项吗?文档说“此选项只是防止无意中损坏分区的一种保护措施,对于常规文件会被忽略。”
-n 跳过抓取阶段。
我想它最好只在第一次运行时使用?
-d 直接磁盘访问。
看起来它更适合恢复,但需要正确的扇区大小才能工作。我知道我不能相信 USB 适配器的报告,但是这个数据表表明我的 WD4002FYYZ 是 512n,而不是 512e。这是否意味着我不需要明确设置大小?或者如果我使用该选项,我最好应该这样做-d
?
目标磁盘位于 SATA 上,显示为 4096 物理扇区,但我想如果我只想复制文件夹而不是重新创建可启动磁盘等,这并不重要。
-v 详细模式。
我可能不需要它?不确定它的输出是什么样的。
/dev/sda vs /dev/sda1
我是否需要为我的目的创建整个驱动器映像?据我所知,我的所有数据都位于最大的分区上,但我也有点好奇看到系统分区的内部。读取整个设备而不是分区是否会增加进一步损坏磁盘的风险?如果是这样,我可以在数据分区安全后尝试映射系统分区。我是否正确理解,如果我使用带有 ddrescue 的分区 ( /dev/sda1
),我不需要偏移选项来安装映像,并且它会像这样工作得很好? mount /volume2/rescue/sda1_rescue.img /mnt/newfolder -o loop,ro
如果您尝试挽救整个分区,请首先使用 e2fsck 或适合您尝试挽救的分区类型的其他工具修复副本,然后将修复的副本安装到某个位置并尝试恢复其中的文件。
e2fsck -v -f /dev/sdb1
在从(已安装的)目标映像复制数据之前,我是否需要在目标映像上运行 e2fsck,即使我认为只要我要复制数据就不需要它按分区运行?
现在填充模式文档的一部分让我有点困惑。
从文档看来,ddrescue 填充模式可以指出文件。但它也说填充模式不是救援模式,我不想严重影响创建的图像,或因此浪费另一个磁盘通道。尽管在 12TB 上可能有额外的空间用于第二个 4TB 映像副本进行实验。但我仍然不清楚,将最佳救援方式与通过填充模式检测受影响文件相结合的最佳方式是什么?
示例 4:找出光盘坏区中有哪些文件。
ddrescue -b2048 /dev/cdrom cdimage mapfile
printf "DEADBEEF" > tmpfile
ddrescue --fill-mode=l- tmpfile cdimage mapfile
rm tmpfile
mount -t iso9660 -o loop,ro cdimage /mnt/cdimage
find /mnt/cdimage -type f -exec grep -l "DEADBEEF" '{}' ';'
(note that my_thesis.txt has a bad sector at pos 0x12345000)
umount /mnt/cdimage
ddrescue -b2048 -i0x12345000 -s2048 -dr9 /dev/cdrom cdimage mapfile
ddrescue --fill-mode=- /dev/zero cdimage mapfile
mount -t iso9660 -o loop,ro cdimage /mnt/cdimage
cp -a /mnt/cdimage/my_thesis.txt /safe/place/my_thesis.txt
此行是否会
ddrescue --fill-mode=l- tmpfile cdimage mapfile
覆盖 cdimage?我应该在第一次进入救援模式后执行此操作吗?而且它不会以任何方式额外接触 infile(损坏的硬盘),对吧?我应该在sda1_rescue.img
或上执行此命令sda1_rescue.img.bak
吗?它是否只是将 tmpfile 文本粘贴到已经损坏的文件中?如果我需要在第二遍(重试)之前运行填充模式,我是否需要以任何方式调整我的第二遍?在示例中
ddrescue -b2048 -i0x12345000 -s2048 -dr9 /dev/cdrom cdimage mapfile
看起来你需要知道坏扇区位置之后的确切文件大小,或者其他什么,不确定-s2048
基于什么。然后它会重试 9 次以从损坏的状态恢复映像中的该文件?为什么它再次运行填充模式?
ddrescue --fill-mode=- /dev/zero cdimage mapfile
与第一次填充运行相比,没有l
密钥,因此它不会写入位置(无论如何,只有第二次救援运行才需要?)。看起来它现在在坏块上写入零,而不是在上一次无法恢复的坏块上写入特定文本,接下来的步骤是安装和恢复。这一步只是简单地将不再需要的文本替换为零吗?
我的大多数文件都是可重新下载的,如果它们损坏了,我只想从其他地方替换它们,但如果可能的话,我可能更喜欢以这种方式恢复某些文件,但我不确定该采取哪一种方法。专注于重要的濒危文件(在多次传递中每个文件一个?)而不是使用 -r3 的整个分区第二次传递对于磁盘恢复来说会更安全吗?
答案1
免责声明:我没有 Synology。我用过(并且喜欢)QNAP,它是类似的。
这个过程应该相当简单。但是,如果您的磁盘确实快要死了,您可能只有一次机会。您可能应该阅读在线文档在ddrescue
开始之前。
您可以尝试按重要性顺序恢复分区,或者只恢复整个磁盘。替换/dev/sda
为/dev/sda1
等,将分区一一剔除。请记住也要修改目标图像文件名。
确保磁盘空闲并且文件系统已卸载。不要fsck
在源盘上运行。
您只rescue.log
在每次恢复过程中需要它,因此应在每次分区恢复尝试之前将其删除。如果任何给定分区的恢复尝试被中断并需要重新启动,不要消除rescue.log
rm -f /volume2/rescue/rescue.log
ddrescue -v /dev/sda /volume2/rescue/sda_rescue.img /volume2/rescue/rescue.log
如果恢复的映像文件sda_rescue.img
代表一个磁盘,您将需要读取其分区表以确定其分区的相关偏移量。幸运的是losetup
,最新的内核通常可以为您做到这一点
losetup --find --show /volume2/rescue/sda_rescue.img
例如,如果您得到/dev/loop0
,您现在应该为磁盘映像上的每个分区找到 、 等/dev/loop0p1
。/dev/loop0p2
否则,您必须自己从分区表中计算出它们(扇区数学和偏移量)。
fsck
您可能需要在映像或其中的每个分区上运行适当的实例。尝试挂载每个镜像或分区;如果失败,请谨慎尝试fsck
。
mkdir /mnt/0p1
mount -o ro,noload /dev/loop0p1 /mnt/0p1 # ext4, readonly with no journal rollback