2 つのバイナリ イメージ ファイルをブール OR で結合します (ddrescue 出力ファイル名の間違い)

2 つのバイナリ イメージ ファイルをブール OR で結合します (ddrescue 出力ファイル名の間違い)

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から、正確な とほぼ同じ品質の近似 を生成できます。これは、すべてゼロを含むセクターが救済されなかったと単純に仮定することによって行われます。infileoutfilemapfile

[…]

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.isoIDTa.imgいずれかにブロック デバイスがある場合は、 を使用する前の「ランダム」なコンテンツがddrescue干渉して結果を台無しにします (したがって、 が役に立たない、異なるサイズに関する潜在的な問題を解決する意味はありませんtruncate)。
  • 私はあなたのミスを再現した後、この手順をテストしました。不安定なデバイス

関連情報