Che cos'è dd conv = sync, noerror fare?

Quindi, qual è il caso di aggiungere conv=sync,noerror fa la differenza quando si esegue il backup di un integer disco rigido su un file di immagini? È conv=sync,noerror un requisito quando fa roba forense? Se è così, perché è il caso con riferimento a linux fedora?

Edit:

OK, quindi se faccio dd senza conv=sync,noerror e dd incontra l'errore durante la lettura del block (let's size 100M), dd salta solo block 100M e legge il block successivo senza scrivere qualcosa ( dd conv=sync,noerror scrive zeri a 100M di output – quindi cosa succede in questo caso?)?

E se ha hash del disco rigido originale e il file di output diverso se fatto senza conv=sync,noerror ? O è questo solo quando si è verificato un errore di lettura?

conv=sync dice dd a pad each block a sinistra con nulls, in modo che se, a causa di errore, il block completo non può essere letto, la piena lunghezza dei dati originali è conservata, anche se non tutti i dati possono essere incluso nell'image. in questo modo saprai alless quanto sia danneggiato i dati, che potrebbero fornirti indizi forensi, e se non riesci ad assumere un'image a causa di blocchi difettosi o altro, non puoi analizzare i dati. alcuni sono migliori di nessuno.

conv=sync,noerror è necessario per impedire a dd di interrompere l'errore e di eseguire un dump. conv=sync è in gran parte senza significato senza noerror.

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

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

dd conv=sync,noerror (o conv=noerror,sync ) danneggia i tuoi dati.

A seconda dell'errore di I / O rilevato e del block utilizzato (più grande della dimensione del settore fisico?), Gli indirizzi di input e output non sono sincronizzati, ma finiscono con gli offset sbagliati, rendendo inutilizzabile la copia per immagini di file system e altri cose in cui gli offset sono importnti.

Molti luoghi consigliano di utilizzare conv=noerror,sync quando si tratta di dischi difettosi. Ho usato per fare la stessa raccomandazione, io stesso. Ha funzionato per me, quando ho dovuto recuperare un disco difettoso qualche tempo fa.

Tuttavia, i test suggeriscono che questo non è affatto attendibile in alcun modo.

Utilizzare losetup e dmsetup per creare un dispositivo 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 

I dispositivi A, B loop sembrano così:

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

Quindi è A, B con numbers incrementali che ci aiuteranno a verificare gli spostamenti più tardi.

Ora per mettere un errore di lettura tra i due, per gentile concessione del mapper di dispositivi Linux:

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

Questo esempio crea AerrorB come nei settori 2000 di A , seguiti da 2*48 settori di errore, seguiti da 2000 settori di B

Solo per verificare:

 # 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 

Quindi legge fino a A127999\n , poiché each row ha 8 byte totali a 1024000 byte, che è il nostro settore 2000 di 512 byte. Tutto sembra essere in ordine …

Sarà fuso?

 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 

risultati:

 # 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 

Dalle size dei file da soli puoi dire che le cose sono sbagliate per alcuni blocchi.

checksum:

 # 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 concorda con ddrescue solo per size di block che si verificano allineate alla nostra area di errore ( 512 , 4K ).

Controlliamo i dati grezzi.

 # 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 

Mentre i dati stessi sembrano essere presenti, non è ovviamente sincronizzato; gli spostamenti sono completamente sfrenati per bs = 16K, 1M, 42,64K … solo quelli con offset 2088576 sono corretti, come può essere verificato contro il dispositivo originale.

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

Questo comportmento previsto di dd conv=noerror,sync ? Non so e le due implementazioni di dd che avevo a disposizione non sono neanche d'accordo. Il risultato è assolutamente inutile se si utilizza dd con una scelta bloccante di performance.

Quanto sopra è stato prodotto usando dd (coreutils) 8.25 , BusyBox v1.24.2 , GNU ddrescue 1.21 .