Dd fa qualche tipo di verifica?

Sto usando ddper copiare i dati da un vecchio disco rigido a uno nuovo. Voglio essere sicuro che l'integrità dei dati sia sicura.

Su questa risposta , dice Gilles

Se [dd] è terminato correttamente, il backup è corretto, salvo un errore hardware ...

Cosa significa esattamente? Ha dduna sorta di verifica integrata?

Se invece dovessi usare rsync, eseguo anche un secondo passaggio --checksumper verificarlo. Questo tipo di paranoia è giustificato?

ddo qualsiasi altra applicazione non ha "una sorta di verifica integrata" nel senso che probabilmente stai pensando: non rilegge i dati dal supporto di archiviazione per confrontarli con ciò che è stato scritto. Questo è il lavoro del sistema operativo.

Non è davvero possibile eseguire una verifica di lettura fino all'hardware da un'applicazione. Funzionerebbe in alcuni scenari, ma nella maggior parte dei casi non otterrebbe nulla. L'applicazione potrebbe rileggere ciò che ha appena scritto se sta scrivendo direttamente su un supporto di archiviazione , ma in genere questo rileggerebbe da una cache in memoria, il che non darebbe alcuna garanzia utile. In l'esempio si cita , ddsta scrivendo ad un tubo, e in quel caso non ha alcun controllo su ciò che accade ai dati più in basso la linea. Nel tuo esempio di rsync, un secondo passaggio dirsync --checksum è inutile: in teoria potrebbe rilevare un errore, ma in pratica, se si verifica un errore, il secondo passaggio probabilmente non riporterebbe nulla di sbagliato, quindi stai sprecando sforzi su qualcosa che in realtà non fornisce una garanzia utile.

Tuttavia, le applicazioni si verificano quello che succede ai dati, nel senso che essi verificare che il sistema operativo ha la responsabilità accettato per i dati. Tutte le chiamate di sistema restituiscono uno stato di errore. Se una chiamata di sistema restituisce uno stato di errore, l'applicazione dovrebbe propagare tale errore all'utente, in genere visualizzando un messaggio di errore e restituendo uno stato di uscita diverso da zero.

Attenzione che ddè un'eccezione: a seconda dei parametri della riga di comando, ddpotrebbe ignorare alcuni errori . Questo è estremamente insolito: ddè l'unico comando comune con questa proprietà. Usa catinvece di dd, in questo modo non rischi la corruzione e potrebbe essere più veloce .

In una catena di copie dei dati, possono insorgere due tipi di errori.

• Corruzione: durante il trasferimento viene capovolto un po '. Non è possibile verificarlo a livello di applicazione, perché se ciò accade, è dovuto a un bug di programmazione o a un errore hardware che è altamente probabile che causi lo stesso danneggiamento durante la lettura. L'unico modo utile per verificare che tale corruzione non si verifichi è disconnettere fisicamente il supporto e riprovare, preferibilmente su un computer diverso nel caso in cui il problema riguardasse la RAM.
• Troncamento: tutti i dati che sono stati copiati sono stati copiati correttamente, ma alcuni dei dati non sono stati copiati affatto. Questa è la pena di verificare a volte, a seconda della complessità del comando. Non è necessario leggere i dati per farlo: basta controllare le dimensioni.

No, ddnon effettua una verifica esplicita. Se desideri / hai bisogno di una copia verificata per legge del tuo disco o di una sua parte, utilizza dcfldduna versione avanzata ddsviluppata dal Dipartimento di difesa informatica del Dipartimento di Difesa degli Stati Uniti.

L'unico modo per essere "sicuri" è fare un ulteriore passaggio di lettura e confronto (dopo aver lasciato cadere le cache).

A parte quello, dd rileva gli errori di lettura e scrittura allo stesso modo di tutti gli altri programmi ... funziona se le unità (e altri componenti coinvolti) segnalano errori; per le unità che accettano silenziosamente i dati senza scriverli, sei sfortunato.

Questo tipo di paranoia è giustificato?

Se non puoi fidarti del tuo hardware per essere affidabile, le cose si complicano ...

Sì, l'hardware difettoso può inserire bit di errore casuali nei dati a una velocità pari a un bit per numero di megabyte, questo è possibile e si verifica in pratica a volte.

Di solito, utilizzo l'hash md5 o sha1 per verificare che i dati siano intatti, rileggendo sia l'origine che la destinazione, ad esempio:

dd if=/dev/sdb of=~/hd_backup
dd if=/dev/sdb | md5sum
dd if=~/hd_backup | md5sum

Ciò presuppone che i dati siano molto più grandi della cache del filesystem, altrimenti potrebbe essere necessario riavviare il sistema per verificare i dati effettivi sul supporto e non i contenuti della cache, oppure utilizzare un altro sistema per esso.

Da man dd:

Al termine, dd visualizza il numero di blocchi di input e output completi e parziali, record di input troncati e blocchi di byte-swap di lunghezza dispari nell'output di errore standard.

Un blocco di input parziale è uno in cui è stata letta una dimensione inferiore al blocco di input. Un blocco di uscita parziale è uno in cui è stata scritta una dimensione inferiore a quella del blocco di uscita. I blocchi di output parziali su dispositivi a nastro sono considerati errori fatali. Altrimenti, il resto del blocco verrà scritto. I blocchi di output parziali su dispositivi a caratteri genereranno un messaggio di avviso.

ddverifica che le dimensioni del blocco input / ouput corrispondano ogni volta che copia un blocco. In caso contrario, gestisce l'errore con un avviso o un errore irreversibile (nascosto con noerror). Ecco perché ddfunziona praticamente sempre.

Tuttavia, non sostituisce la verifica manuale dell'integrità del disco. Se le informazioni sono preziose per te, allora sì, la tua paranoia è giustificata . Esegui una verifica manuale al ddtermine.