.png)
ddrescue を再開するときに間違った出力ファイル名を使用するという愚かなミスを犯しました。次のようなことが起こりました:
ddrescue -b 2048 -d -v /dev/sr1 IDTa.img IDTa.ddrescue.log
その後、コンピューターがクラッシュし、誤って次のように再開しました。
ddrescue -b 2048 -d -v /dev/sr1 IDTa.iso IDTa.ddrescue.log
両方のイメージ ファイルはすべてゼロで始まると理解しているので、両方のファイルをブール OR 演算すると、間違いがなかった場合に ddrescue が出力する結果と同じになると思います。
ファイルは互いに連続したものではありません(2 つの ddrescue イメージを結合するにはどうすればよいでしょうか?) は、以前に既に実行しておりddrescue -n
、正常に完了しているためです。つまり、IDTa.img にはほとんどのデータが含まれ、IDTa.iso にはイメージ全体から散在するブロックが含まれます (IDTa.img ではそれらのブロックはゼロになります)。
これを実行するためのシンプルな CLI の方法はありますか? C で実行できるかもしれませんが、私はかなりさびついています。また、Python での最初の練習としても良いかもしれません。Python はこれまで一度も学習したことがありません。とはいえ、すでに何かが存在する場合は、特に車輪の再発明をしたくはありません。パフォーマンスについてはあまり気にしていません。
アップデート:(回答への返信を投稿する場所が間違っている場合はお詫び申し上げます。「コメント」オプションでは文字数が少なすぎるようですので、ここで返信させていただきます。)
上記の解決策として、ddrescue で '--fill-mode=?' を試してみましたが、うまくいきませんでした。私がやったことは次のとおりです:
ddrescue --generate-mode -b 2048 -v /dev/sr1 IDTa.img IDTa.img.log
cp IDTa.img IDTa.img.backup
ddrescue '--fill-mode=?' -b 2048 -v IDTa.iso IDTa.img IDTa.img.log
確認するために、IDTa.iso にデータがある最初の位置を探しました。
hexdump -C IDTa.iso |less
出力は次のようになりました:
00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
001da800 00 00 01 ba 21 00 79 f3 09 80 10 69 00 00 01 e0 |....!.y....i....|
...
001db000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
...
IDTa.img で 001da800 を調べました:
hexdump -C IDTa.img |less
/001da800
出力:
001da800 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
001db000 00 00 01 ba 21 00 7b 00 bf 80 10 69 00 00 01 e0 |....!.{....i....|
...
つまり、位置 001da800 のデータはファイル IDTa.iso から IDTa.img にコピーされていないということですか?
IDTa.img.log を確認しています:
# Mapfile. Created by GNU ddrescue version 1.22
# Command line: ddrescue --fill-mode=? -b 2048 -v IDTa.iso IDTa.img IDTa.img.log
# Start time: 2021-06-28 13:52:39
# Current time: 2021-06-28 13:52:46
# Finished
# current_pos current_status current_pass
0x299F2000 + 1
# pos size status
0x00000000 0x00008000 ?
0x00008000 0x001D2800 +
0x001DA800 0x00000800 ?
0x001DB000 0x00049000 +
...
そして現実を直視しましょう:
diff -q IDTa.img IDTa.img.backup
違いは返されません。
アップデート2:
@Kamil は、引数を削除してソリューションを編集しました (下記参照) --fill-mode=?
。 動作するようです!
答え1
これはそれ自体で実行できると思いますddrescue
。 が必要です--generate-mode
。
ddrescue
オプション付きで が呼び出されると--generate-mode
、デフォルトの「レスキュー モード」とは異なる「生成モード」で動作します。つまり、「生成モード」ではddrescue
何もレスキューしません。後で使用するために を生成することだけを試みますmapfile
。[…]
ddrescue
は、場合によっては、と の(部分的な)コピーmapfile
から、正確な とほぼ同じ品質の近似 を生成できます。これは、すべてゼロを含むセクターが救済されなかったと単純に仮定することによって行われます。infile
outfile
mapfile
[…]
ddrescue --generate-mode infile outfile mapfile
(ソース)
念のため、2 つのイメージのコピーを作成します。ファイルシステムが CoW コピーをサポートしている場合は、cp --reflink=always
各イメージに を使用して、ほぼ瞬時にコピーを作成します。
2 つの画像が同じサイズであることを確認する必要があります。どちらかが小さい場合は、拡大する必要があります。つまり、ゼロ (まばらなゼロの可能性あり) を追加する必要があります。このコードはこれを自動的に実行します (truncate
は必須です)。
( f1=IDTa.img
f2=IDTa.iso
s1="$(wc -c <"$f1")"
s2="$(wc -c <"$f2")"
if [ "$s2" -gt "$s1" ]; then
truncate -s "$s2" "$f1"
else
truncate -s "$s1" "$f2"
fi
)
(サブシェルを使用したので、変数はサブシェルとともに消滅し、メインシェルは影響を受けません。)
次に、ツールで最初のイメージを分析し、どのセクターがおそらく救出されなかったかを調べます。
ddrescue --generate-mode -b 2048 -v /dev/sr1 IDTa.img new_mapfile
new_mapfile
ここに新しいファイルがあります。ないあなたのIDTa.ddrescue.log
。触らないでくださいIDTa.ddrescue.log
。
が生成された後、対応するフラグメントが「レスキュー済み」と見なされたか「未試行」と見なされたかに応じて、その中の行にステータスまたはがnew_mapfile
表示されます。+
?
ここで、 の「未試行」ブロックを のIDTa.img
データで埋めますIDTa.iso
。次のコマンドは を変更しますIDTa.img
。
IDTa.img
からデータを読み取って、の「未試行」ブロックを救出しますIDTa.iso
:
ddrescue -b 2048 -v IDTa.iso IDTa.img new_mapfile
これで、修正されたIDTa.img
部分も修正IDTa.ddrescue.log
されていない部分も、間違いを犯していなかったのと同じくらい良好な状態になるはずです。
ノート:
- すべてゼロのセクターが実際に救出された可能性があります。
--generate-mode
はそれらを として分類します?
。それらは「無駄に」取得されたデータで埋められますIDTa.iso
。この他のファイルでもすべてゼロであるため、最終的な結果には影響しません。 IDTa.iso
手順全体でと を入れ替えても結果は同じになるはずですIDTa.img
(ただし、これを行うと結果は になることに注意してくださいIDTa.iso
)。したがって、選択肢があります。 では、--generate-mode
すべてゼロのセクターが少ないと予想されるファイルを使用します。これにより、最後のコマンドの作業量が最小限に抑えられるためです。- この方法は、通常のファイルと に有効です
IDTa.iso
。IDTa.img
いずれかにブロック デバイスがある場合は、 を使用する前の「ランダム」なコンテンツがddrescue
干渉して結果を台無しにします (したがって、 が役に立たない、異なるサイズに関する潜在的な問題を解決する意味はありませんtruncate
)。 - 私はあなたのミスを再現した後、この手順をテストしました。不安定なデバイス。