vdfuse
を使用してVDIをマウントし、dd_rescue
を使用して中断されたパーティションをレスキューして、破損したVDIを回復しようとしています。
dd_rescue
は正常に機能しているようですが、パーティションの約半分に達すると、停止して次のエラーが発生します。
ddrescue: write error: Read-only file system
待って..何?突然FS回復したパーティションを読み取り専用ファイルシステムに書き込んでいます。ええと...なぜですか?これを完了できないのでしょうか?どうなっているのでしょうか?
更新-2012年12月2日
コンピュータの電源が切れたときにVBoxを実行していましたが、バックアップを開始してvboxインスタンスを実行しようとすると、HDDにオペレーティングシステムがないことがわかりました。
そのため、そのプロファイルのBIOSオプションとVBox設定を確認した後、そのVDIを使用して新しいプロファイルを作成し、同じエラーが発生しました。これは、VDIが実際に読み取れず、プロファイルが台無しにされただけではないことを証明しました。
VDIは、4つのパーティションを備えた500GBのディスクです。 vdfuse
を使用してVDIをフォルダーにマウントすると、ループバックデバイスとして4つのパーティションが含まれます(Partition1
、Partition2
など)
最初のパーティションをマウントしようとすると、正常に動作します。ブートパーティションだったので、何も役に立ちません。しかし、ユーザーのホームパーティションであるPartition4
をマウントしようとすると、Bad superblock at offset ######
と何度か表示され、マウントに失敗します。
そこで、ddrescue Partition4 ../partition4_restore.img
を実行すると、約260 GBに達する(「レスキュー」)まで正常に動作し、停止して「読み取り専用ファイルシステム」エラーが発生します。
Imgファイルを置く場所には660GBの空き容量があります。
vdfuse
でマウントした後、testdisk
を使用して、Partition4
ファイル内のファイルのリストを表示およびコピーできるようにしました。
1。 ddrescue
エラーのトラブルシューティング:
ターゲットボリュームに関連しているとされるエラーで書き込みが失敗しています。このような大きなファイルをターゲットボリュームに実際に書き込むことができることを確認することをお勧めします。
`dd if=/dev/zero of=testfile bs=32M count=15000`
その操作が成功した場合、問題がddrescue
操作に固有であると合理的に確信できます。失敗した場合は、問題がターゲットボリュームにあることがわかります。
2。元の問題の修正:
もちろん、選択した戦略から一歩後退して、単にfsck -b
を使用して 代替スーパーブロックを復元する を試してみるのは非常に理にかなっています。
Dd_rescueの代わりにGNU dd_rescue( http://www.gnu.org/software/ddrescue/ddrescue.html )を使用する必要がありますが、これは同じではありません。元のdd_rescueは安全ではありませんが、GNU dd_rescueは安全です。
ただし、書き込みエラーが発生した場合は、最初にターゲットパーティションをチェックして、そのような大きなファイルを保存できるかどうか(ほとんどのFATパーティションは保存できません)、ターゲットパーティションに十分な空き領域があるかどうかを確認します。