更新：Linux 中的设备识别

Question 1

首先，不要在磁盘上执行任何其他操作（至少永远不会写磁盘不被认可（而不是“被识别但发现是空的或包含不可读数据”）似乎表明磁盘已经完全损坏（通常chkdsk不会发生这种情况），或者磁盘的分区表或几何结构存在问题，或者 USB 外壳处理磁盘的方式存在问题。也可能是硬件故障。

这可以而且将会发生当 USB 外壳尝试在磁盘和它们所连接的计算机之间进行协商时。因此，要做的第一件事是在ddLinux 下使用尽可能接近物理级别的磁盘（显然更大）拍摄磁盘映像。然后，您可以随心所欲地摆弄映像副本，而不会有进一步损坏真实磁盘的风险。

更新：Linux 中的设备识别

我们不少于三我们“外部磁盘”中的实体。USB 外壳硬件，显示为块设备。外壳内的物理磁盘。物理设备，即从第一个到最后一个 LBA 扇区的序列。最后是零个或多个数据分区，托管文件系统。要“识别”并显示在桌面中，链的所有链接都需要正常工作。但要获取物理设备的图像，您只需要前两个。如果您插入设备并运行命令行dmesg（以 root 身份），您应该会看到类似以下内容：

[4984939.028491] usb 8-6: new high speed USB device using ehci_hcd and address 3
[4984939.166658] usb 8-6: configuration #1 chosen from 1 choice
[4984939.170660] scsi7 : SCSI emulation for USB Mass Storage devices
[4984939.172003] usb-storage: device found at 3
[4984939.172005] usb-storage: waiting for device to settle before scanning

...即外壳被识别，然后识别其自身及其内容：

[4984939.170660] usb 8-6: New USB device found, idVendor=1058, idProduct=1021
[4984939.170660] usb 8-6: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[4984939.170660] usb 8-6: Product: Ext HDD 1021
[4984939.170660] usb 8-6: Manufacturer: Western Digital
[4984939.170660] usb 8-6: SerialNumber: 574D43305431303831303734
[4984944.400970] usb-storage: device scan complete

接下来，您将看到驱动程序告知其几何形状、性质，并隐含地告知其设备节点，如下所示sdd（对于 SCSI 磁盘四，因为sda、sdb和sdc已被占用）：

[4984944.404739] scsi 7:0:0:0: Direct-Access     WD      Ext HDD 1021    2021 PQ: 0 ANSI: 4
[4984944.404739] sd 7:0:0:0: [sdd] 1953519616 512-byte hardware sectors (1000202 MB)
[4984944.407367] sd 7:0:0:0: [sdd] Write Protect is off
[4984944.407369] sd 7:0:0:0: [sdd] Mode Sense: 17 00 10 08
[4984944.407371] sd 7:0:0:0: [sdd] Assuming drive cache: write through
[4984944.408741] sd 7:0:0:0: [sdd] 1953519616 512-byte hardware sectors (1000202 MB)

然后内核识别出有一个分区（如果您没有看到这个，则表示该分区不存在或无效）：

[4984944.411497]  sdd: sdd1

现在 Linux 已拥有其所需的一切并报告附加成功：

[4984944.416739] sd 7:0:0:0: [sdd] Attached SCSI disk
[4984944.416739] sd 7:0:0:0: Attached scsi generic sg4 type 0

因此开始搜索数据分区，即，好的，我们有sdd1，但是那里有什么？，答案是：

[4984997.498613] NTFS driver 2.1.29 [Flags: R/W MODULE].
[4984997.554613] NTFS volume version 3.1.
[4984997.568859] NTFS-fs error (device sdd1): load_system_files(): $LogFile is not clean.  Mounting read-only.  Mount in Windows.
[4985390.027808] NTFS-fs error (device sdd1): ntfs_remount(): Volume has errors and is read-only.  Cannot remount read-write.
[4985442.423299] NTFS volume version 3.1.
[4985442.425032] NTFS-fs error (device sdd1): load_system_files(): $LogFile is not clean.  Mounting read-only.  Mount in Windows.

上面的这个是“良好”的安装。但只要知道设备是sdd、或sdc或sdb，我就可以制作二进制副本（假设上有足够的可用空间/mnt/backupdisk）：输入文件/dev/sdd、输出文件DiskImage.raw、块大小 1 MB：

# dd if=/dev/sdd of=/mnt/backupdisk/DiskImage.raw bs=1M

笔记输入文件是/dev/sdd 并不是 /dev/sdd1 （或任何其他数字）。现在，如果我愿意，我可以找出数据分区的偏移量DiskImage.raw，并借助循环设备将其挂载。这里你会发现肮脏的细节。

首次恢复尝试

第二件事是将物理磁盘放入另一个机箱，从而确保机箱完好无损，并有机会让新机箱正确解释磁盘。如果磁盘再次出现，则可能是之前的机箱坏了。以防万一，请备份所有新发现的驱动器内容，核实备份，使用磁盘覆盖实用程序将磁盘清零，以便完全地愚蠢（您不能在设备链中拥有两个意见不同的设备），从 Windows 本地重新格式化并恢复数据。这是一次幸运的尝试，但我亲眼目睹了这一切；而且尝试的成本并不太高，好的外壳新售价约为 19.99 美元。

如果原来的外壳损坏，您将无法重新格式化磁盘，或者磁盘将无法访问。您可以重试新的外壳，如果可以，请更换旧外壳，或继续使用新外壳（但如果新外壳损坏，则值得这样做）相当比 19.99 美元的 El Cheapo 更好）。

专业康复

专业恢复服务，您可以通过 Google 找到这些服务。一种不太诚实的做法是发送物理磁盘，如果您得到的答案是“是的，没有硬件损坏，我们可以恢复您的所有数据，只需花费 $$$,$$$ 美元！”那么您就可以知道数据仍然可以挽救。因此，您可以尝试免费使用您制作的映像备份自行修复，只需支付诊断和磁盘 S&H 费用。如果失败，您仍然可以选择支付所要求的钱。如果是硬件损坏，专业服务基本上是你的仅有的选项。有几种巫术可以（暂时）恢复“死”磁盘，通常时间足够长，至少可以恢复最重要的数据，但没有任何每次都能保证有效的方法（加热磁盘、冷却磁盘、“旋转”磁盘——我甚至看到有人建议巧妙地将其敲击在坚硬的表面上）。所有这些方法都会造成更大的损害，也就是说，你必须确保使用第一次就有效的技巧，否则你将永远毁掉磁盘。我只是想解释一下为什么你会看到关于恢复磁盘的成功案例：是这样的事。但如果你想（基本）确定它会发生你那么，聘请一位专业人士吧。

如果您确定硬件没有问题 - 磁盘旋转，没有嘎嘎声，没有奇怪的声音或嗡嗡声，没有咔嗒咔嗒的重新校准 - 那么发生的“一切”就是chkdsk弄乱了一些数据。

DIY 恢复

“家庭”恢复通常会像这样进行（基本上与硬件损坏排除后专业人员会做的事情相同），处理磁盘映像副本：

检查磁盘映像的第一个扇区是否是有效的分区表。如果不是，则扫描磁盘映像以查找有效的分区表或可识别的 NTFS 或 FAT32 引导扇区，具体取决于设备上的 FS（对于 1 TB 设备，NTFS 似乎是唯一合理的可能性）。无论哪种方式，您都应该在前几兆字节中找到一些东西。
如果找到分区表，请验证数据分区是否位于分区表所指示的位置。如果不是，那么这是个好消息：大概分区表就是所有错误所在。修复它很容易（一些 Linux 分区编辑器可以做到这一点），并且磁盘可能有望 100% 恢复。为了安全起见，请尝试在 Linux 中使用循环设备以只读模式安装数据分区，以查看它是否可读。如果是，则确认分区损坏，并且可能宣布磁盘正在可靠和完全恢复的路上。如果不是，则分区可能是正确的，并且数据分区的（部分）已被重写。这很糟糕；请参阅下面的“事情变糟”部分。
如果找到并且有效，则根据驱动器几何结构进行检查，如果不匹配，这实际上也是一个好的事情，因为你可能已经找到了问题的根源。你可以强制物理几何为内核（并且在 Linux 启动时获取)。查看新的几何结构是否会导致 Linux 识别磁盘。如果可以，请备份数据，验证备份是否正确，然后将磁盘清零dd（将几兆字节的零输入到相应的sd设备就足够了）。关闭计算机（不要只是重新启动；好吧，这有点偏执，但成本不高，可能会有所成就），然后启动 Windows 并让其将现在毫无头绪的磁盘格式化为其认为最好的格式。这确保不会与 Windows 发生冲突。恢复磁盘上的数据。尽情享受吧。
如果几何技巧不起作用，或者找不到分区，或者找到后分区看起来是空的，事情就会变得糟糕。你需要一些能够扫描磁盘映像中搜索丢失数据的数据区域（MFT 等）。一旦找到，就对其进行解释以获取数据。这是一项艰巨的工作，并不总是能够完全自动化。在较低且更绝望的级别，这涉及扫描丢失数据的签名个人文件，希望它们位于磁盘的连续块中。不过，这种操作我很乐意留给专业人士。我使用旧的 FAT 磁盘做过几次，每次都成功。我又用更新、更大、碎片更多的 FAT32 磁盘做了一次，成功率约为 50%。我尝试有几次，结果很差（但我有完整的备份，并没有真正全力以赴），在更复杂的 NTFS 和 ext4 文件系统上。

从 Linux 手动恢复

好的，您尝试在 Linux 中挂载分区并收到错误（注意 /dev/sdc 和 /dev/sdcN 是不同的东西——图像指的是/dev/sdc）。

# mount -t ntfs /dev/sdc1 /mnt/recovery
ntfs_mst_post_read_fixup_warn: magic: 0x00000000  size: 1024   usa_ofs: 0  usa_count: 65535: Invalid argument
Record 1 has no FILE magic (0x0)
Failed to open inode $MFTMirr: Input/output error

...这似乎表明分区，正如系统所认为的那样，有误或损坏严重。我们先来看看第一个选项：

# fdisk /dev/sdc

你会得到类似这样的结果：

Disk /dev/sdc: 1000.2 GB, 1000204885504 bytes
1 heads, 63 sectors/track, 31008335 cylinders, total 1953525167 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x9d2b7596

Device       Boot      Start    End          Blocks       Id  System
/dev/sdc1              63       1953520127   976760032+   7   HPFS/NTFS/exFAT

下一步是检查实际分区的开始位置。通过进入映像文件（或/dev/sdc），我们将搜索 NTFS 签名：

  00000000:EB 52 90 4E 54 46 53 20 -20 20 20 00 02 08 00 00 .R.NTFS ........ 
  00000010:00 00 00 00 00 F8 00 00 -3F 00 FF 00 3F 00 00 00 ........?...?... 
  00000020:00 00 00 00 80 00 80 00 -4A F5 7F 00 00 00 00 00 ........J....... 

# dd if=/dev/sdc bs=512 count=1 skip=63 2>/dev/null | hexdump -C | head -n 1

...根据上述数据，我们预计 NTFS 启动位于第 63 扇区，因此我们设置了skip。此外，我们将尝试使用每一个第一个（比如说）兆字节中的扇区......

# dd if=/dev/sdc bs=512 count=2000000 2>/dev/null | hexdump -C | grep "00:EB 52 90 4E 54 46 53"

...只是为了确保只有一个引导扇区（我也遇到过这种情况。在 FAT32 磁盘上，但是仍然) 并且任何地方都没有读取错误。

你的结果

00007e00  eb 52 90 4e 54 46 53 20  20 20 20 00 02 08 00 00  |.R.NTFS    .....|

正是我们所期望的：扇区 63 的偏移量为 63×512 = 32256 = 7e00 十六进制。NTFS 引导扇区存在，并且分区表似乎正确。

因此，我们现在可以将一大块复制/dev/sdc1到 Linux 上，/tmp/mydisk.img然后尝试从 Linux 修复它。这不会损坏物理磁盘，它仍然可以不加改变地用于其他尝试。而且，既然现在我们知道 PT 是正确的，我们可以将其用于/dev/sdc1复制，并怀抱以前无法实现的希望：

# dd if=/dev/sdc1 of=/tmp/mydisk.img bs=1G count=10
...after copying 10 gigabytes...

# ntfsfix /tmp/mydisk.img

如果 NTFSfix 不起作用，那我们就有麻烦了。更准确的实用工具不过，你可以尝试一下。如果你需要恢复 JPEG 图片文件，并且文件系统没有碎片，可以通过查找 JPEG 标头自动完成此操作。PDF、TIFF 和 Office 文档也几乎如此，只是我不知道如何识别它们（对于 JPEG，我会 :-) ）。作为最后的选择，我发现这些家伙– 我不认识他们，与他们没有关系，也不会接受任何指责。然而，随着这些事情的发展，代价是非常合理的。

Answer

首先，不要在磁盘上执行任何其他操作（至少永远不会写磁盘不被认可（而不是“被识别但发现是空的或包含不可读数据”）似乎表明磁盘已经完全损坏（通常chkdsk不会发生这种情况），或者磁盘的分区表或几何结构存在问题，或者 USB 外壳处理磁盘的方式存在问题。也可能是硬件故障。

这可以而且将会发生当 USB 外壳尝试在磁盘和它们所连接的计算机之间进行协商时。因此，要做的第一件事是在ddLinux 下使用尽可能接近物理级别的磁盘（显然更大）拍摄磁盘映像。然后，您可以随心所欲地摆弄映像副本，而不会有进一步损坏真实磁盘的风险。

更新：Linux 中的设备识别

我们不少于三我们“外部磁盘”中的实体。USB 外壳硬件，显示为块设备。外壳内的物理磁盘。物理设备，即从第一个到最后一个 LBA 扇区的序列。最后是零个或多个数据分区，托管文件系统。要“识别”并显示在桌面中，链的所有链接都需要正常工作。但要获取物理设备的图像，您只需要前两个。如果您插入设备并运行命令行dmesg（以 root 身份），您应该会看到类似以下内容：

[4984939.028491] usb 8-6: new high speed USB device using ehci_hcd and address 3
[4984939.166658] usb 8-6: configuration #1 chosen from 1 choice
[4984939.170660] scsi7 : SCSI emulation for USB Mass Storage devices
[4984939.172003] usb-storage: device found at 3
[4984939.172005] usb-storage: waiting for device to settle before scanning

...即外壳被识别，然后识别其自身及其内容：

[4984939.170660] usb 8-6: New USB device found, idVendor=1058, idProduct=1021
[4984939.170660] usb 8-6: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[4984939.170660] usb 8-6: Product: Ext HDD 1021
[4984939.170660] usb 8-6: Manufacturer: Western Digital
[4984939.170660] usb 8-6: SerialNumber: 574D43305431303831303734
[4984944.400970] usb-storage: device scan complete

接下来，您将看到驱动程序告知其几何形状、性质，并隐含地告知其设备节点，如下所示sdd（对于 SCSI 磁盘四，因为sda、sdb和sdc已被占用）：

[4984944.404739] scsi 7:0:0:0: Direct-Access     WD      Ext HDD 1021    2021 PQ: 0 ANSI: 4
[4984944.404739] sd 7:0:0:0: [sdd] 1953519616 512-byte hardware sectors (1000202 MB)
[4984944.407367] sd 7:0:0:0: [sdd] Write Protect is off
[4984944.407369] sd 7:0:0:0: [sdd] Mode Sense: 17 00 10 08
[4984944.407371] sd 7:0:0:0: [sdd] Assuming drive cache: write through
[4984944.408741] sd 7:0:0:0: [sdd] 1953519616 512-byte hardware sectors (1000202 MB)

然后内核识别出有一个分区（如果您没有看到这个，则表示该分区不存在或无效）：

[4984944.411497]  sdd: sdd1

现在 Linux 已拥有其所需的一切并报告附加成功：

[4984944.416739] sd 7:0:0:0: [sdd] Attached SCSI disk
[4984944.416739] sd 7:0:0:0: Attached scsi generic sg4 type 0

因此开始搜索数据分区，即，好的，我们有sdd1，但是那里有什么？，答案是：

[4984997.498613] NTFS driver 2.1.29 [Flags: R/W MODULE].
[4984997.554613] NTFS volume version 3.1.
[4984997.568859] NTFS-fs error (device sdd1): load_system_files(): $LogFile is not clean.  Mounting read-only.  Mount in Windows.
[4985390.027808] NTFS-fs error (device sdd1): ntfs_remount(): Volume has errors and is read-only.  Cannot remount read-write.
[4985442.423299] NTFS volume version 3.1.
[4985442.425032] NTFS-fs error (device sdd1): load_system_files(): $LogFile is not clean.  Mounting read-only.  Mount in Windows.

上面的这个是“良好”的安装。但只要知道设备是sdd、或sdc或sdb，我就可以制作二进制副本（假设上有足够的可用空间/mnt/backupdisk）：输入文件/dev/sdd、输出文件DiskImage.raw、块大小 1 MB：

# dd if=/dev/sdd of=/mnt/backupdisk/DiskImage.raw bs=1M

笔记输入文件是/dev/sdd 并不是 /dev/sdd1 （或任何其他数字）。现在，如果我愿意，我可以找出数据分区的偏移量DiskImage.raw，并借助循环设备将其挂载。这里你会发现肮脏的细节。

首次恢复尝试

第二件事是将物理磁盘放入另一个机箱，从而确保机箱完好无损，并有机会让新机箱正确解释磁盘。如果磁盘再次出现，则可能是之前的机箱坏了。以防万一，请备份所有新发现的驱动器内容，核实备份，使用磁盘覆盖实用程序将磁盘清零，以便完全地愚蠢（您不能在设备链中拥有两个意见不同的设备），从 Windows 本地重新格式化并恢复数据。这是一次幸运的尝试，但我亲眼目睹了这一切；而且尝试的成本并不太高，好的外壳新售价约为 19.99 美元。

如果原来的外壳损坏，您将无法重新格式化磁盘，或者磁盘将无法访问。您可以重试新的外壳，如果可以，请更换旧外壳，或继续使用新外壳（但如果新外壳损坏，则值得这样做）相当比 19.99 美元的 El Cheapo 更好）。

专业康复

专业恢复服务，您可以通过 Google 找到这些服务。一种不太诚实的做法是发送物理磁盘，如果您得到的答案是“是的，没有硬件损坏，我们可以恢复您的所有数据，只需花费 $$$,$$$ 美元！”那么您就可以知道数据仍然可以挽救。因此，您可以尝试免费使用您制作的映像备份自行修复，只需支付诊断和磁盘 S&H 费用。如果失败，您仍然可以选择支付所要求的钱。如果是硬件损坏，专业服务基本上是你的仅有的选项。有几种巫术可以（暂时）恢复“死”磁盘，通常时间足够长，至少可以恢复最重要的数据，但没有任何每次都能保证有效的方法（加热磁盘、冷却磁盘、“旋转”磁盘——我甚至看到有人建议巧妙地将其敲击在坚硬的表面上）。所有这些方法都会造成更大的损害，也就是说，你必须确保使用第一次就有效的技巧，否则你将永远毁掉磁盘。我只是想解释一下为什么你会看到关于恢复磁盘的成功案例：是这样的事。但如果你想（基本）确定它会发生你那么，聘请一位专业人士吧。

如果您确定硬件没有问题 - 磁盘旋转，没有嘎嘎声，没有奇怪的声音或嗡嗡声，没有咔嗒咔嗒的重新校准 - 那么发生的“一切”就是chkdsk弄乱了一些数据。

DIY 恢复

“家庭”恢复通常会像这样进行（基本上与硬件损坏排除后专业人员会做的事情相同），处理磁盘映像副本：

检查磁盘映像的第一个扇区是否是有效的分区表。如果不是，则扫描磁盘映像以查找有效的分区表或可识别的 NTFS 或 FAT32 引导扇区，具体取决于设备上的 FS（对于 1 TB 设备，NTFS 似乎是唯一合理的可能性）。无论哪种方式，您都应该在前几兆字节中找到一些东西。
如果找到分区表，请验证数据分区是否位于分区表所指示的位置。如果不是，那么这是个好消息：大概分区表就是所有错误所在。修复它很容易（一些 Linux 分区编辑器可以做到这一点），并且磁盘可能有望 100% 恢复。为了安全起见，请尝试在 Linux 中使用循环设备以只读模式安装数据分区，以查看它是否可读。如果是，则确认分区损坏，并且可能宣布磁盘正在可靠和完全恢复的路上。如果不是，则分区可能是正确的，并且数据分区的（部分）已被重写。这很糟糕；请参阅下面的“事情变糟”部分。
如果找到并且有效，则根据驱动器几何结构进行检查，如果不匹配，这实际上也是一个好的事情，因为你可能已经找到了问题的根源。你可以强制物理几何为内核（并且在 Linux 启动时获取)。查看新的几何结构是否会导致 Linux 识别磁盘。如果可以，请备份数据，验证备份是否正确，然后将磁盘清零dd（将几兆字节的零输入到相应的sd设备就足够了）。关闭计算机（不要只是重新启动；好吧，这有点偏执，但成本不高，可能会有所成就），然后启动 Windows 并让其将现在毫无头绪的磁盘格式化为其认为最好的格式。这确保不会与 Windows 发生冲突。恢复磁盘上的数据。尽情享受吧。
如果几何技巧不起作用，或者找不到分区，或者找到后分区看起来是空的，事情就会变得糟糕。你需要一些能够扫描磁盘映像中搜索丢失数据的数据区域（MFT 等）。一旦找到，就对其进行解释以获取数据。这是一项艰巨的工作，并不总是能够完全自动化。在较低且更绝望的级别，这涉及扫描丢失数据的签名个人文件，希望它们位于磁盘的连续块中。不过，这种操作我很乐意留给专业人士。我使用旧的 FAT 磁盘做过几次，每次都成功。我又用更新、更大、碎片更多的 FAT32 磁盘做了一次，成功率约为 50%。我尝试有几次，结果很差（但我有完整的备份，并没有真正全力以赴），在更复杂的 NTFS 和 ext4 文件系统上。

从 Linux 手动恢复

好的，您尝试在 Linux 中挂载分区并收到错误（注意 /dev/sdc 和 /dev/sdcN 是不同的东西——图像指的是/dev/sdc）。

# mount -t ntfs /dev/sdc1 /mnt/recovery
ntfs_mst_post_read_fixup_warn: magic: 0x00000000  size: 1024   usa_ofs: 0  usa_count: 65535: Invalid argument
Record 1 has no FILE magic (0x0)
Failed to open inode $MFTMirr: Input/output error

...这似乎表明分区，正如系统所认为的那样，有误或损坏严重。我们先来看看第一个选项：

# fdisk /dev/sdc

你会得到类似这样的结果：

Disk /dev/sdc: 1000.2 GB, 1000204885504 bytes
1 heads, 63 sectors/track, 31008335 cylinders, total 1953525167 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x9d2b7596

Device       Boot      Start    End          Blocks       Id  System
/dev/sdc1              63       1953520127   976760032+   7   HPFS/NTFS/exFAT

下一步是检查实际分区的开始位置。通过进入映像文件（或/dev/sdc），我们将搜索 NTFS 签名：

  00000000:EB 52 90 4E 54 46 53 20 -20 20 20 00 02 08 00 00 .R.NTFS ........ 
  00000010:00 00 00 00 00 F8 00 00 -3F 00 FF 00 3F 00 00 00 ........?...?... 
  00000020:00 00 00 00 80 00 80 00 -4A F5 7F 00 00 00 00 00 ........J....... 

# dd if=/dev/sdc bs=512 count=1 skip=63 2>/dev/null | hexdump -C | head -n 1

...根据上述数据，我们预计 NTFS 启动位于第 63 扇区，因此我们设置了skip。此外，我们将尝试使用每一个第一个（比如说）兆字节中的扇区......

# dd if=/dev/sdc bs=512 count=2000000 2>/dev/null | hexdump -C | grep "00:EB 52 90 4E 54 46 53"

...只是为了确保只有一个引导扇区（我也遇到过这种情况。在 FAT32 磁盘上，但是仍然) 并且任何地方都没有读取错误。

你的结果

00007e00  eb 52 90 4e 54 46 53 20  20 20 20 00 02 08 00 00  |.R.NTFS    .....|

正是我们所期望的：扇区 63 的偏移量为 63×512 = 32256 = 7e00 十六进制。NTFS 引导扇区存在，并且分区表似乎正确。

因此，我们现在可以将一大块复制/dev/sdc1到 Linux 上，/tmp/mydisk.img然后尝试从 Linux 修复它。这不会损坏物理磁盘，它仍然可以不加改变地用于其他尝试。而且，既然现在我们知道 PT 是正确的，我们可以将其用于/dev/sdc1复制，并怀抱以前无法实现的希望：

# dd if=/dev/sdc1 of=/tmp/mydisk.img bs=1G count=10
...after copying 10 gigabytes...

# ntfsfix /tmp/mydisk.img

如果 NTFSfix 不起作用，那我们就有麻烦了。更准确的实用工具不过，你可以尝试一下。如果你需要恢复 JPEG 图片文件，并且文件系统没有碎片，可以通过查找 JPEG 标头自动完成此操作。PDF、TIFF 和 Office 文档也几乎如此，只是我不知道如何识别它们（对于 JPEG，我会 :-) ）。作为最后的选择，我发现这些家伙– 我不认识他们，与他们没有关系，也不会接受任何指责。然而，随着这些事情的发展，代价是非常合理的。

Question 2

只需以管理员权限进入 cmd 并输入 chkdsk X: /f（“X”是驱动程序的卷名，“/f”是修复）

Answer

只需以管理员权限进入 cmd 并输入 chkdsk X: /f（“X”是驱动程序的卷名，“/f”是修复）

Question 3

对于我和我的同事来说，一个简单的解决方案是安装磁盘并chkdsk在 Windows 7 上使用。

Answer

对于我和我的同事来说，一个简单的解决方案是安装磁盘并chkdsk在 Windows 7 上使用。

更新：Linux 中的设备识别

答案1

更新：Linux 中的设备识别

首次恢复尝试

专业康复

DIY 恢复

从 Linux 手动恢复

答案2

答案3

相关内容