情况就是这样。
环境是 Linux（实际上是 Arch Linux）。
一个未压缩的 1.3TBtar文件被写入全新 XFS 格式2TB 磁盘作为备份。
后来，一个 586MB 的 UEFI 启动映像被（错误地）写入到同一个磁盘设备，命令如下：dd if=./bootimage of=/dev/sdd bs=4M。
据我所知，除了这个行为很愚蠢之外，磁盘并没有被重新格式化或擦除。”只是“其前 500+MB 的扇区已被覆盖。
我的第一次尝试是基于这样的假设：块由 XFS 线性分配，并且我知道被覆盖部分的确切大小。想法是跳过所有这些块，然后尝试将所有后续块传送到该cpio工具：它可以尽力处理损坏的tar文件（我的文件头部被截断了）。
FILESIZE=614465536
SECTSIZE=$(( 2 * 1024 * 1024 )) # 2M
SKIPSIZE=$(( $FILESIZE / $SECTSIZE ))
dd if=/dev/sdd ibs=$SECTSIZE obs=$SECTSIZE skip=$SKIPSIZE | cpio -ivd -H ustar
（我切换到 2M 块传输，因为文件大小是它的倍数，但不是 4M）。恢复完全没有运气。但现在我知道 XFS 使用的磁盘布局不是线性的。
下一步是尝试维修xfs_repair分区表修复后，我使用 恢复了文件系统（以及它的副本）fdisk。它找到了“xfs 签名”，我借助设备访问了该单个分区loop。不幸的是，xfs_repair它失败了，显示“只读 512 字节中的 0 个”。此外，似乎没有办法在 XFS 下恢复丢失的文件。
foremost第三次尝试是在和等帮助工具的帮助下进行的testdisk。但到目前为止，我的尝试收效甚微。他们实际上已经能够恢复一些文件，主要是多媒体文件（GIF、JPG、PNG、WAV 和 MP3）。但这些只是备份实际内容的一小部分。它似乎foremost专注于典型的 Windows 文件。但它们覆盖了 1.3TB 数据的约 15%。还应该有大量文本文件、libreoffice 文件以及gzip和bzip2文件。到目前为止，15% 比 0% 好。
我还搜索了我手头上的所有文档，并“谷歌”了类似的场景（也在这里服务器故障）。更相关的是将磁盘发送到数据恢复公司。互联网上似乎没有记录类似的任务。
为了最大限度地恢复文件，最好的策略是什么？
完美的方法是tar通过恢复 i 节点链的剩余部分来恢复单个文件的幸存部分。
答案1
如果有时间并且了解所涉及的细节，许多事情都可以恢复。
在这种情况下，我看不到现成的解决方案，而一个真正的问题是文件系统和 tar 文件签名的有趣部分很可能已被覆盖。
如果您确实努力独立完成此任务，我会尝试执行以下步骤：
- 对最初损坏的文件系统进行 1:1 备份。
- 只对损坏的文件系统的副本执行写入操作，因为很可能需要多次尝试才能成功。每次写入都存在更多数据被破坏的风险。
- 检查 XFS 如何将数据写入磁盘。这很可能是按顺序进行的，但一定要知道该假设是否正确，以及使用哪种类型的数据字节序/布局。
- 阅读并理解 tar 文件格式，尝试识别 tar 文件的开始/结束签名和重复模式（例如校验和等）以收集搜索块的信息。深入研究 tar 源代码以了解数据如何写入文件系统。
- 尝试恢复 tar 文件，并尝试修复它以便您可以提取文件。
所有提到的工具，如 photorec、testdisk、foremost 等，都只能让你在恢复文件方面获得有限的成功，即使恢复量相当不错，也经常会出现以下问题：大量误报、文件名缺失、没有文件夹结构。考虑到 1.3 TB 的数据，所有这些都是判断该过程是否成功的重要因素。
根据您提供的信息，似乎“只有” 500 Mb 的数据确实损坏了，其余数据应该处于“良好”状态，因此应该可以获得良好的结果，但这取决于 xfs 和 tar 如何处理数据。由于 tar 来自磁带区域，因此数据布局应该非常简单。但这个过程一点也不简单，并且在一定程度上涉及原始数据处理。