web-dev-qa-db-ja.com

dd conv = sync、noerrorとは何ですか？

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

編集する

conv=sync,noerrorを指定せずにddを実行し、ddがブロックの読み取り時に読み取りエラーに遭遇した場合（100M）、ddは100Mブロックをスキップし、次のブロックを何も書き込まずに読み取ります（dd conv=sync,noerrorは100Mの出力にゼロを書き込みます）。この件について？

conv=sync,noerrorを付けずに行うと、元のハードディスクと出力ファイルのハッシュが異なるのでしょうか。それとも読み取りエラーが発生したときだけですか？

linuxbackupddforensics
39
dding

conv=syncは、ddに各ブロックの左側にNULLを埋め込むように指示します。そのため、エラーのために全ブロックを読み取ることができない場合、元のデータの全長が保持されます画像。そうすれば、少なくともデータがどれだけ損傷しているかを知ることができます。これは法医学的な手がかりを与える可能性があります。何もないよりはましです。

conv=sync,noerrorは、ddがエラーで停止してダンプを実行しないようにするために必要です。 conv=syncは、エラーなしではほとんど意味がありません。

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

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

42
Frank Thomas

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

そのため、後でオフセットを検証するのに役立ちます。

2つの間に読み取りエラーを入れるために、Linuxデバイスマッパーの好意により：

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

この例では、AerrorBの2000セクター、次にエラーの2*48セクター、Aの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

各行は8バイトで合計1024000バイトで、これは2000セクタの512バイトですから、A127999\nまで読み取ります。すべてが順調に進んでいるようです...

混ざりますか。

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

ddは、エラーゾーン（512、4K）に合わせて配置されることがあるブロックサイズについてのみddrescueと一致します。

生データをチェックしましょう。

# 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.25、BusyBox v1.24.2、GNU ddrescue 1.21を使用して生成されました。

34
frostschutz