如何在無分區 qcow2 的 ext3 文件系統中找到替代超級塊？

我有一個有趣的案例，e2fsck拒絕辨識 qcow2 圖像文件中的文件系統。使用testdisk我可以看到分區，所以會留下一些標記。

出現這個問題的原因首先是因為虛擬機的主機死了。

所以我選擇None分區的“類型”並得到以下內容。

TestDisk 6.14, Data Recovery Utility, July 2013
Christophe GRENIER <grenier@cgsecurity.org>
http://www.cgsecurity.org

Disk /dev/loop0 - 120 GB / 112 GiB - 235156929 sectors

The harddisk (120 GB / 112 GiB) seems too small! (< 4079258 TB / 3710063 TiB)
Check the harddisk size: HD jumpers settings, BIOS detection...

The following partitions can't be recovered:
    Partition               Start        End    Size in sectors
>  ext3                         640  251657855  251657216 [DATA]
  ext3                     1864062  253521277  251657216 [DATA]
  ext3                     1864064  253521279  251657216 [DATA]
  ext3                     2387454  254044669  251657216 [DATA]
  ext3                     2387456  254044671  251657216 [DATA]
  ext3                     2911614  254568829  251657216 [DATA]
  ext3                     2911616  254568831  251657216 [DATA]
  ext3                     3435774  255092989  251657216 [DATA]
  ext3                     3435776  255092991  251657216 [DATA]
  ext3                     3959934  255617149  251657216 [DATA]

[ Continue ]
ext3 blocksize=4096 Large file Sparse superblock, 128 GB / 119 GiB

似乎超級塊仍然存在並且完好無損，但是mount只要我不知道它們的位置，我怎麼能說服使用其中一個超級塊呢？

kpartx在我為 qcow2/dev/loop0做了通常的操作後，沒有看到任何內容。losetup -o 32256 /dev/loop0 imagefile

圖像本身是 ( qemu-img info)：

file format: qcow2
virtual size: 120G (128849018880 bytes)
disk size: 112G
cluster_size: 65536
Format specific information:
   compat: 0.10

注意：我確實有備份，但它們是幾週前的，如果可能的話，我會將磁碟上的內容與備份進行比較。大多數是 Git 和 Mercurial 儲存庫，因此可以從其他地方再次獲取它們。

好的，很抱歉這麼快就回答了我自己的問題，但我注意到了一些令人震驚的事情。該.qcow2文件的大小為 120400379904 字節，而圖像的轉換qemu-img convert -O raw給了我一個大小為 128849018880 字節的圖像。

很不一樣。

現在，如果我們採用找到的扇區大小testdisk，我們確實會注意到 512*251657216 是 128848494592，這恰好比“原始”圖像的文件大小多 512 字節。這看起來很有希望，我心想。

幾年前我生成了這些文件，所以我不確定我是否將它們創建為稀疏圖像。不過，如果這樣qemu-img info顯示，我心想，讓我們嘗試轉換圖像格式。請記住，這不會更改原始文件！

qemu-img convert -O raw input output

完成這項工作，儘管速度很慢。

testdisk在該文件上再次執行執行得非常好，儘管我仍然無法說服 mount 使用不同的超級塊，儘管-o sb=....

TestDisk 6.14, Data Recovery Utility, July 2013
Christophe GRENIER <grenier@cgsecurity.org>
http://www.cgsecurity.org

Disk bigdata/vm_disk_vdb.img - 128 GB / 120 GiB - CHS 15666 255 63
    Partition               Start        End    Size in sectors
>P ext3                     0   1  1 15664 239 62  251657216 [DATA]


Structure: Ok.


Keys T: change type, P: list files,
    Enter: to continue
ext3 blocksize=4096 Large file Sparse superblock, 128 GB / 119 GiB

之後，我可以testdisk將文件複製到一個目錄中，並將其與我的備份進行比較。

有一些腐敗，例如：

ext2fs_read_inode(ino=384492884) failed with error 2133571369.

還有其他小問題，但這些問題僅影響了所有文件和文件夾的 0.1% 左右。如下開始testdisk，以便能夠確定哪些文件必須被視為已損壞：

testdisk /log imagefile.img

引用自：https://unix.stackexchange.com/questions/132824