Cosa fa dd conv = sync, noerror?

Quindi, qual è il caso quando si aggiunge la conv=sync,noerrordifferenza quando si esegue il backup di un intero disco rigido su un file di immagine? È conv=sync,noerrorun requisito quando si fa roba forense? Se è così, perché è il caso con riferimento a Fedora Linux?

Modificare:

OK, quindi se faccio dd senza conv=sync,noerrore ddriscontro un errore di lettura durante la lettura del blocco (dimensioniamo 100M), salta semplicemente il blocco 100M e legge il blocco successivo senza scrivere qualcosa ( dd conv=sync,noerrorscrive gli zero su 100M di output - quindi che dire di questo caso ?)?

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

conv=syncindica dddi riempire ogni blocco a sinistra con valori nulli, in modo che se, a causa di un errore, non è possibile leggere l'intero blocco, venga conservata l'intera lunghezza dei dati originali, anche se non tutti i dati stessi possono essere inclusi nell'immagine . in questo modo almeno sai quanto sono danneggiati i dati, il che potrebbe fornirti indizi forensi e se non riesci affatto a catturare un'immagine a causa di blocchi danneggiati o altro, non puoi analizzare nessuno dei dati. alcuni sono meglio di nessuno.

conv=sync,noerrorè necessario per impedire l' ddarresto in caso di errore e l'esecuzione di un dump. conv=syncè in gran parte insignificante 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) corrompe i tuoi dati.

A seconda dell'errore I / O riscontrato e della dimensione del blocco utilizzata (maggiore della dimensione del settore fisico?), Gli indirizzi di input e output non rimangono effettivamente sincronizzati ma finiscono con offset errati, il che rende la copia inutile per le immagini del filesystem e altro cose in cui gli offset contano.

Molti posti raccomandano l'uso conv=noerror,syncquando si hanno a che fare con dischi danneggiati. Ero solito fare la stessa raccomandazione, me stesso. Ha funzionato per me, quando ho dovuto recuperare un disco danneggiato qualche tempo fa.

Tuttavia, i test suggeriscono che questo non è effettivamente affidabile in alcun modo.

Utilizzare losetupe dmsetupper creare un A error Bdispositivo:

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 del loop A, B si presentano così:

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

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

Quindi è A, B con numeri incrementali che ci aiuteranno a verificare gli offset in un secondo momento.

Ora per inserire un errore di lettura tra i due, per gentile concessione di Linux Device Mapper:

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

Questo esempio crea AerrorBcome in 2000settori di A, seguito da 2*48settori di errore, seguito da 2000settori 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\nquando ogni riga ha 8 byte che ammontano a 1024000 byte, ovvero i nostri 2000 settori di 512 byte. Tutto sembra essere in ordine ...

Si fonderà?

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

Solo dalle dimensioni dei file puoi dire che le cose sono sbagliate per alcune dimensioni di blocco.

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è d'accordo ddrescuesolo per le dimensioni dei blocchi che risultano allineate alla nostra zona 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, ovviamente non sono sincronizzati; gli offset sono completamente fuori campo per bs = 16K, 1M, 42,64K ... solo quelli con offset 2088576sono corretti, come si può verificare con il dispositivo originale.

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

Questo comportamento previsto è dd conv=noerror,sync? Non lo so e le due implementazioni di ddcui disponevo non sono neppure d'accordo tra loro. Il risultato è molto inutile se utilizzato ddcon una scelta di grandi dimensioni performanti.

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