![可能的 NTFS 状态是什么样的?](https://linux22.com/image/1627903/%E5%8F%AF%E8%83%BD%E7%9A%84%20NTFS%20%E7%8A%B6%E6%80%81%E6%98%AF%E4%BB%80%E4%B9%88%E6%A0%B7%E7%9A%84%EF%BC%9F.png)
我弄坏了一个包含照片的外部驱动器,我想恢复这些照片。这是一个 NTFS 格式的驱动器。我做了一些初步调查,但我不明白我看到的是什么。我会提供一些背景信息、一些观察结果和一些结论,现在我只是在寻找信息 - 我是否得出了合理的结论?
语境 那是很久以前的事了,但是我思考发生的事情是:
- 我在 Windows 上用一个 NTFS 分区格式化了它,然后将照片复制到其中
- 我将其插入运行 Raspbian 的 Raspberry Pi
- 该驱动器似乎不断地循环供电(也许 RPi 无法通过 USB 为其以及另一个外部设备、键盘和鼠标供电?)
- 我推测所造成的损坏已经发生了,因此拔掉了驱动器。
观察结果 以下是各个进程报告的状态:
- 当插入 Linux 系统(没有其他磁盘的相同 RPi)时,它显示为 /dev/sda。
- 尽管它在“磁盘管理”中显示为原始磁盘,但它并没有在 Windows 中出现驱动器号。
- EaseUS 可以在扫描后显示文件结构(目录和文件名),所以我认为错误是软错误而不是物理驱动器故障。
现在,我想在摆弄磁盘之前先对其进行映像处理。但是,这是一个 1TB 的磁盘,我没有足够的空间进行完整的扇区复制。因此,我想检查磁盘的特定部分并尝试更有针对性的方法。我承认,在我不理解的地方乱摸可能会让事情变得更糟,但这就是我在这里寻找更多信息的原因。
结论 有关 NTFS 的维基百科页面似乎显示前 500 个字节左右是 NTFS 引导扇区,其中的数据描述了 NTFS 文件系统的其余部分。由于 EaseUS 能够找出仍然物理存在的文件结构,我认为大部分 NTFS 数据仍然物理存在(即有关 NTFS 内文件结构的数据,而不仅仅是文件本身)。这个假设正确吗?
因此,安装驱动器所需的任何信息都以某种方式损坏了,但假设它可以安装,那么文件结构描述仍然存在于某个地方。但这会在 NTFS 结构中的哪个位置?在主文件表中?对吗?
因此,如果大部分 NTFS 数据仍然存在,它应该在前 500 个字节中,对吗?
更多观察
我运行了ddrescue count=100 if=/dev/sda =of=~/myDisk.img conv=noerror
,但输出文件~/myDisk.img
是 51200 字节0x00
。在尝试读取扇区时ddrescue
报告了许多警告。"Inut/output error"
我也ddrescue count=100 if=/dev/sda =of=~/myDisk.img conv=noerror skip=1G
盲目猜测我的数据应该位于驱动器的开始处附近,但那里也是空的(但没有"Input/output error"
警告)。
当我运行ddrescue count=100 if=/dev/sda =of=~/myDisk.img conv=noerror skip=2G
时,ddrescue
它告诉我“skip”是一个无效参数。我认为它试图说“2G”是该skip
参数的无效值,但我不知道为什么在 1TB 驱动器上会出现这种情况。
最后的问题 我是否误解了 NTFS 的一些基本知识,或者 NTFS 引导扇区真的是空的?如果引导扇区真的是空的,那么像 EaseUS 这样的工具如何能够重建文件结构?
答案1
结论维基百科上有关 NTFS 的页面似乎显示前 500 个字节左右是 NTFS 引导扇区,其中的数据描述了 NTFS 文件系统的其余部分。由于 EaseUS 能够找出物理上仍在那里的文件结构,我认为许多 NTFS 数据也物理上仍在那里(即有关 NTFS 内文件结构的数据,而不仅仅是文件本身)。这是正确的假设吗?
是的,除了引导扇区只有一个指向文件的指针$MFT
,并且那个文件描述文件系统的所有其他信息。实际上,所有 NTFS 元数据都以带有 $ 名称的不可见文件的形式存储(您可以在同一篇文章中找到一个表格)。
更多观察我跑了
ddrescue count=100 ...
这个描述很奇怪,因为虽然你说你使用了“ddrescue”,但命令的其余部分(及其结果)看起来非常像你实际使用的普通“dd”。尽管名称相似,但这些工具实际上是完全不同的。
“ddrescue”命令的语法与“dd”不同(并且总体上工作方式也不同——它是设计从具有许多坏扇区的磁盘复制)。如 Attie 的示例所示,您应该使用:
ddrescue /dev/sda ~/mydisk.img ~/mydisk.map --size=2G
(映射文件允许您停止和恢复复制,以及以ddrescueview
图形方式查看哪些磁盘区域是坏的且无法复制。)
当我运行
ddrescue count=100 if=/dev/sda =of=~/myDisk.img conv=noerror skip=2G
时,ddrescue 告诉我“skip”是一个无效参数。我认为它试图说“2G”是 skip 参数的无效值,但我不知道为什么在 1TB 驱动器上会出现这种情况。
在 dd(不是 ddrescue!)中,诸如“count”和“skip”之类的参数始终采用块数,而不是字节数。因此,“2G”并不意味着 2 GB,而是意味着 2147483648 个 512 字节的块(或使用 指定的任何自定义大小[i]bs=
)。
此外,dd 使用二进制大小单位(其中 K=1024),而制造商使用十进制单位(其中 k=1000)销售其磁盘。
使用默认的 512 字节块大小,“skip=2G”实际上意味着正好 1 TiB(1099511627776 字节),也就是不仅仅是你的磁盘– 大多数 HDD 只有 1 TB(1000000000000 字节或略大于 931 GiB)。
最后的问题我是否误解了 NTFS 的一些基本知识,或者 NTFS 引导扇区真的是空的?如果引导扇区真的是空的,那么像 EaseUS 这样的工具如何能够重建文件结构?
NTFS 引导扇区仅存储有关文件系统的一些非常基本的参数,例如簇大小或 $MFT 文件的起始位置 - 恢复工具可以很容易猜到因为只有少数典型的簇大小,并且 $MFT 几乎总是放在相同的位置。
(引导扇区的大部分数据与文件系统本身无关,它实际上只存储用于启动操作系统的引导代码。由于 PC BIOS 引导过程的工作方式,许多文件系统为此目的保留了前几个扇区。
在 BIOS 系统中,只有一个分区(Vista 或更高版本中的隐藏“系统”分区,或 XP 或更早版本中的 C: 分区)需要具有有效的引导扇区。在 UEFI 系统上,引导机制不同,引导扇区根本不用于任何用途。)