dd conv = sync、noerrorは何をしますか?


39

それでは、conv=sync,noerrorハードディスク全体をイメージファイルにバックアップするときに、追加が違いを生む場合はどうなりますか?conv=sync,noerror法医学的なことをするときの要件はありますか?もしそうなら、なぜLinux fedoraを参照しているのですか?

編集:

OK、だからddをせずconv=sync,noerrordd、ブロックの読み取り時に読み取りエラーが発生した場合(サイズを100Mとしましょう)、ddは100Mブロックをスキップし、何も書き込まずに次のブロックを読み取ります(dd conv=sync,noerror100Mの出力に0を書き込みます。 ?)?

元のハードディスクと出力ファイルのハッシュが異なる場合、異なる場合はどうなりますconv=sync,noerrorか?または、これは読み取りエラーが発生したときのみですか?


3
「法医学的なことをするとき、conv = sync、noerrorは要件ですか?」という質問に対する賛成票
nergeia 14

回答:


46

conv=syncddすべてのデータ自体を画像に含めることができない場合でも、エラーのためにブロック全体を読み取ることができない場合、元のデータの全長が保持されるように、各ブロックの左側にヌルを埋め込むように指示します。そうすれば、少なくともデータの損傷の程度を知ることができ、法医学的な手がかりが得られる可能性があります。また、不良ブロックなどが原因で画像をまったく取得できない場合は、データを分析できません。いくつかはどれもより良いです。

conv=sync,noerrorddエラーで停止してダンプを実行するのを防ぐために必要です。conv=syncエラーなしではほとんど意味がありません。

http://linuxcommand.org/man_pages/dd1.html

http://vlinux-freak.blogspot.com/2011/01/how-to-use-dd-command.html


1
質問:conv = syncなしでddを実行すると、ハードディスクと画像ファイルのハッシュが異なるエラーになりますか?
ディング

また、ddが読み取りエラーに遭遇した場合、その瞬間に停止しますか?
ディング

3
dd自体はハッシュしないので、dcflDD forensicswiki.org/wiki/Dcflddのようなツールについて考えていますか?理論的には、ハッシュを計算するツールが同じ方法でエラーに遭遇する限り、ディスクのハッシュとイメージのハッシュは同じでなければなりません。
フランクトーマス

質問に明確に回答するこの質問に対する唯一の回答であることに賛成しましたが、実際にバックアップを破損するという他の回答の結論をどう思いますか?あなたの2つの答えは互いに矛盾しているように見えますが、多分私は誤解しています。
ハシム

36

dd conv=sync,noerror(またはconv=noerror,sync)データが破損しています。

発生したI / Oエラー、および使用されているブロックサイズ(物理セクターサイズよりも大きい?)に応じて、入力アドレスと出力アドレスは実際には同期しませんが、間違ったオフセットで終了するため、ファイルシステムイメージなどのコピーは役に立たなくなりますオフセットが重要なこと。

多くの場所でconv=noerror,sync、不良ディスクを扱うときに使用することをお勧めします。私も同じ勧告を自分でしていました。しばらく前に不良ディスクを回復しなければならなかったとき、それは私にとってはうまくいきました。

ただし、テストでは、これは実際にはまったく信頼できないことが示唆されています。

使用losetupしてdmsetup作成するにはA error B、デバイスを:

truncate -s 1M a.img b.img
A=$(losetup --find --show a.img)
B=$(losetup --find --show b.img)
i=0 ; while printf "A%06d\n" $i ; do i=$((i+1)) ; done > $A
i=0 ; while printf "B%06d\n" $i ; do i=$((i+1)) ; done > $B

A、Bループデバイスは次のようになります。

# head -n 3 $A $B
==> /dev/loop0 <==
A000000
A000001
A000002

==> /dev/loop1 <==
B000000
B000001
B000002

そのため、後でオフセットを検証するのに役立つ、増分する番号を持つA、Bです。

次に、Linuxデバイスマッパーの好意により、2つの間に読み取りエラーを挿入します。

# dmsetup create AerrorB << EOF
0 2000 linear $A 0
2000 96 error
2096 2000 linear $B 48
EOF

この例ではAerrorB、asの2000セクターを作成しA、その後2*48にエラーのセクターが続き、その後にの2000セクターが続きますB

確認するだけです:

# blockdev --getsz /dev/mapper/AerrorB
4096
# hexdump -C /dev/mapper/AerrorB
00000000  41 30 30 30 30 30 30 0a  41 30 30 30 30 30 31 0a  |A000000.A000001.|
00000010  41 30 30 30 30 30 32 0a  41 30 30 30 30 30 33 0a  |A000002.A000003.|
[...]
000f9fe0  41 31 32 37 39 39 36 0a  41 31 32 37 39 39 37 0a  |A127996.A127997.|
000f9ff0  41 31 32 37 39 39 38 0a  41 31 32 37 39 39 39 0a  |A127998.A127999.|
000fa000
hexdump: /dev/mapper/AerrorB: Input/output error

したがってA127999\n、各行には8バイトがあり、合計で1024000バイトになります。これは、2000セクターの512バイトです。すべてが整然としています...

ブレンドしますか?

for bs in 1M 64K 16K 4K 512 42
do
    dd bs=$bs conv=noerror,sync if=/dev/mapper/AerrorB of=AerrorB.$bs.gnu-dd
    busybox dd bs=$bs conv=noerror,sync if=/dev/mapper/AerrorB of=AerrorB.$bs.bb-dd
done

ddrescue /dev/mapper/AerrorB AerrorB.ddrescue

結果:

# ls -l
-rw-r--r-- 1 root root 2113536 May 11 23:54 AerrorB.16K.bb-dd
-rw-r--r-- 1 root root 2064384 May 11 23:54 AerrorB.16K.gnu-dd
-rw-r--r-- 1 root root 3145728 May 11 23:54 AerrorB.1M.bb-dd
-rw-r--r-- 1 root root 2097152 May 11 23:54 AerrorB.1M.gnu-dd
-rw-r--r-- 1 root root 2097186 May 11 23:54 AerrorB.42.bb-dd
-rw-r--r-- 1 root root 2048004 May 11 23:54 AerrorB.42.gnu-dd
-rw-r--r-- 1 root root 2097152 May 11 23:54 AerrorB.4K.bb-dd
-rw-r--r-- 1 root root 2097152 May 11 23:54 AerrorB.4K.gnu-dd
-rw-r--r-- 1 root root 2097152 May 11 23:54 AerrorB.512.bb-dd
-rw-r--r-- 1 root root 2097152 May 11 23:54 AerrorB.512.gnu-dd
-rw-r--r-- 1 root root 2162688 May 11 23:54 AerrorB.64K.bb-dd
-rw-r--r-- 1 root root 2097152 May 11 23:54 AerrorB.64K.gnu-dd
-rw-r--r-- 1 root root 2097152 May 11 23:54 AerrorB.ddrescue

ファイルサイズだけから、いくつかのブロックサイズでは問題があることがわかります。

チェックサム:

# md5sum *
8972776e4bd29eb5a55aa4d1eb3b8a43  AerrorB.16K.bb-dd
4ee0b656ff9be862a7e96d37a2ebdeb0  AerrorB.16K.gnu-dd
7874ef3fe3426436f19ffa0635a53f63  AerrorB.1M.bb-dd
6f60e9d5ec06eb7721dbfddaaa625473  AerrorB.1M.gnu-dd
94abec9a526553c5aa063b0c917d8e8f  AerrorB.42.bb-dd
1413c824cd090cba5c33b2d7de330339  AerrorB.42.gnu-dd
b381efd87f17354cfb121dae49e3487a  AerrorB.4K.bb-dd
b381efd87f17354cfb121dae49e3487a  AerrorB.4K.gnu-dd
b381efd87f17354cfb121dae49e3487a  AerrorB.512.bb-dd
b381efd87f17354cfb121dae49e3487a  AerrorB.512.gnu-dd
3c101af5623fe8c6f3d764631582a18e  AerrorB.64K.bb-dd
6f60e9d5ec06eb7721dbfddaaa625473  AerrorB.64K.gnu-dd
b381efd87f17354cfb121dae49e3487a  AerrorB.ddrescue

ddddrescue、エラーゾーン(5124K)に位置合わせされるブロックサイズについてのみ同意します。

生データを確認しましょう。

# grep -a -b --only-matching B130000 *
AerrorB.16K.bb-dd:  2096768:B130000
AerrorB.16K.gnu-dd: 2047616:B130000
AerrorB.1M.bb-dd:   2113152:B130000
AerrorB.1M.gnu-dd:  2064000:B130000
AerrorB.42.bb-dd:   2088578:B130000
AerrorB.42.gnu-dd:  2039426:B130000
AerrorB.4K.bb-dd:   2088576:B130000
AerrorB.4K.gnu-dd:  2088576:B130000
AerrorB.512.bb-dd:  2088576:B130000
AerrorB.512.gnu-dd: 2088576:B130000
AerrorB.64K.bb-dd:  2113152:B130000
AerrorB.64K.gnu-dd: 2064000:B130000
AerrorB.ddrescue:   2088576:B130000

データ自体は存在しているように見えますが、明らかに同期していません。bs = 16K、1M、42,64Kの場合、オフセットは完全に外れ2088576ています。元のデバイスに対して検証できるように、オフセットのあるものだけが正しいです。

# dd bs=1 skip=2088576 count=8 if=/dev/mapper/AerrorB 
B130000

これは予想される動作dd conv=noerror,syncですか?私は知らないし、dd私が利用可能だった2つの実装は互いに同意さえしません。ddパフォーマンスのブロックサイズを選択して使用した場合、結果はほとんど役に立ちません。

上記を使用して製造しましたdd (coreutils) 8.25BusyBox v1.24.2GNU ddrescue 1.21


3
非常に興味深く、詳細ですが、それでも混乱します。これはバグだと思いますか?報告されていますか?または、ユーザーがデバイスの実際のブロックサイズに対応するbs =引数を必ず使用する必要があるということですか?
nealmcb

@frostschutzは、不良セクタのあるドライブで作業するときではddrescueなく、使用することをお勧めしddますか?
-ljk

2
いいえ。sync引数は出力に正しい長さを保つためにそれを伝えます。間違ったブロックサイズを使用すると動作しませんので、それをしないでください。
-psusi

12
ねえ、iflag=fullblockそれを保存するようです。がmd5sumで作られた画像のSはiflag=fullblock-まだ(!つまり量の読み取りエラーのためにスキップされたバイト数が異なるため、もちろん異なる\0が、アライメントが一緒に保存されるの画像が異なる)iflag=fullblockgrep -a -b --only-matching B130000リターン2088576すべての画像のために。
サーシャ

3
@Sashaは正しいですし、より多くの賛成票が必要です!fullblockは、ドキュメントに記載されていますgnu.org/software/coreutils/manual/html_node/dd-invocation.html
mlt
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.