☰

qcow2パーティションを持たないext3ファイルシステムで代替スーパーブロックを見つける方法は？

tag-icon • tag-icon loop-device rescue disk-image testdisk
qcow2パーティションを持たないext3ファイルシステムで代替スーパーブロックを見つける方法は？

e2fsckqcow2イメージファイル内のファイルシステムが認識を拒否する興味深いケースがありました。使用するとtestdiskパーティションが表示され、一部のマークが残ります。

この問題が発生する最初の理由は、仮想マシンのホストがクラッシュするためです。

Noneそのため、パーティションの「タイプ」を選択し、次のような結果を得ます。

TestDisk 6.14, Data Recovery Utility, July 2013
Christophe GRENIER <[email protected]>
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どこにあるのかわからない限り、そのうちの1つを使用するようにどのように確信できますか？

kpartxqcow2で通常の操作を実行した後/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リポジトリなので、他の場所から再インポートできます。

答え1

まあ、私の質問にすばやく答えて申し訳ありませんが、衝撃的な事実を見つけました。ファイルサイズ.qcow2は120400379904バイトで、画像を変換するとqemu-img convert -O raw128849018880バイトサイズの画像が表示されます。

大きく異なります。

これで見つかったセクタサイズを取ると、testdisk512 * 251657216が128848494592であることがわかります。これは、「オリジナル」イメージのファイルサイズよりも正確に512バイトです。これは有望に見えますが、私は中に考えました。

このファイルは数年前に作成されたため、まれな画像で作成されたかどうかはわかりません。さてさてqemu-img info、画像フォーマットを変換してみようかと思いました。元のファイルは変更されないことを覚えておいてください！

qemu-img convert -O raw input output

遅くても作業を完了します。

ファイルをやり直すとtestdisk驚くほどうまくいきましたが、-o sb=...。

TestDisk 6.14, Data Recovery Utility, July 2013
Christophe GRENIER <[email protected]>
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

関連情報