Esiste un comando copia e verifica in Ubuntu / Linux?


23

Eseguo il backup di tutte le mie foto digitali in un paio di posti. Ho usato il comando cp, ma - dato il valore personale - hanno iniziato a chiedermi se esiste un modo più affidabile. Non sono estraneo a Linux, Bash, Perl, ecc., Quindi potrei scrivere qualcosa per copiare e confrontare gli hash md5, ma mi chiedevo se qualcosa già esiste (reinvenzione, ruote e cosa no).

Gran parte del mio googling per la copia e (verifica | valido | verifica | hash | conferma) viene visualizzato rsync. Tuttavia, per quanto posso dire, rsync usa solo gli hash per vedere se un file deve essere aggiornato. In seguito non esegue un confronto hash.

Per questo uso, in particolare, i file sono binari e in genere 8-10 MB. Eventuali raccomandazioni per le utility o indicazioni per soluzioni fai-da-te sarebbero molto apprezzate.


Che ne dici di unisono ? Viene utilizzato per la sincronizzazione bidirezionale ma controlla sicuramente il checksum di un file.
cono

Risposte:


19

Da man rsync, sotto l' -copzione:

-c, --checksum: salta in base al checksum, non a mod-time e dimensioni

Si noti che rsync verifica sempre che ogni file trasferito sia stato correttamente ricostruito sul lato ricevente controllando un checksum di file intero che viene generato quando il file viene trasferito, ma che la verifica automatica dopo il trasferimento non ha nulla a che fare con questa opzione prima del trasferimento "Questo file deve essere aggiornato?" dai un'occhiata.


7
Alcune persone hanno capito che il manuale di rsync è fuorviante riguardo al controllo predefinito della copia post: unix.stackexchange.com/a/66702/148560 Sembra che non ci sia un tale controllo. Per verificare tutte le copie devi fare un'altra rsync con l'opzione --checksum, dicono.
Rotareti,

5

Diversi anni fa ho avuto le tue stesse richieste. La soluzione che ho scelto è stata quella di utilizzare ZFS tramite il driver ZFS-FUSE sul mio server di archiviazione. Pensavo che le mie foto personali, i documenti scansionati e altri file simili fossero cose a cui potevo accedere solo occasionalmente, quindi potrebbe passare molto tempo, diciamo un anno o più, prima di notare che un file è stato danneggiato a causa di un errore di unità o simili.

A quel punto, tutte le copie di backup che ho potrebbero essere questa versione del file.

ZFS ha un vantaggio rispetto a RAID-5 in quanto può rilevare e riparare errori nei dati memorizzati sui singoli dischi, anche se le unità non riportano un errore di lettura durante la lettura dei dati. Rileverà, tramite checksum, che uno dei dischi ha restituito informazioni danneggiate e utilizzerà i dati di ridondanza per riparare quel disco.

A causa del modo in cui è progettato il checksum in ZFS, ho pensato di poter fare affidamento su di esso per archiviare i dati utilizzati di rado per lunghi periodi di tempo. Ogni settimana eseguo uno "scrub zpool" che passa e rilegge tutti i dati e verifica i checksum.

ZFS-FUSE ha funzionato abbastanza bene per me negli ultimi anni.

In un lontano passato, per un cliente, ho implementato un sistema di database che memorizzava le informazioni di checksum su tutti i file archiviati in una directory specifica. Ho quindi avuto un altro script che sarebbe stato eseguito periodicamente e avrebbe verificato il file rispetto al checksum archiviato nel database. Con ciò potremmo rapidamente rilevare un file danneggiato e ripristinarlo dai backup. Stavamo praticamente implementando gli stessi tipi di controlli che ZFS esegue internamente.


Perché il voto negativo? Poiché non è stato lasciato alcun commento, suppongo sia un "-1, non sono d'accordo". :-)
Sean Reifschneider il

... ma poi: quale parte non è d'accordo? Anche se forse un po 'fuori tema per la domanda, questo mi sembra solido. Quindi spero che il downvote fosse per "non rispondere alla domanda" piuttosto che lasciarci ignari di un vero difetto di cui sopra ...
Arjan,

Mi sono reso conto stamattina che stavo supponendo che icyrock lo stesse chiedendo a causa delle preoccupazioni per il bit-marcio, che era la mia preoccupazione. Ma forse è in qualche modo diverso. Anche se non riesco a immaginare quale sia il caso d'uso che cambierebbe legittimamente il contenuto del file senza cambiare i tempi del file.
Sean Reifschneider,

Penso che la preoccupazione del PO fosse la corruzione dei dati in transito. Si copia un file e la copia finisce per essere diversa dall'originale.
Jon Bentley,

btrfs? che ha checksum ed è nativo ...
Dmitry Kudriavtsev il


1

Ho trovato questa utility (Linux e Windows) che fa esattamente quello che vuoi (copia con hash + verifica con hash con log): http://sourceforge.net/projects/quickhash/

L'unico aspetto negativo è che esiste solo come una GUI (nessun accesso alla riga di comando)

Dalla v1.5.0, è possibile eseguire l'hashing di una cartella di origine selezionata, quindi copiarla e ricostruirla in una cartella di destinazione in cui il contenuto viene nuovamente sottoposto a hash per la verifica. Dalla 1.5.5 è possibile utilizzare anche maschere di file selezionate (* .doc; * .xls ecc.).


0

se stai copiando il file localmente (come è implicito nel tuo riferimento cpinvece di scpetc), quindi solo cmpi file di origine e destinazione ... ma realisticamente, se cpnon sta emettendo una sorta di errore (sulla riga di comando o in il valore restituito dall'esecuzione), non c'è motivo di credere che non funzioni.

se vuoi davvero un backup legittimamente ridondante, prendi in considerazione una soluzione remota come dropbox .


+1. Non è chiaro perché questa risposta sia stata sottoposta a downgrade in quanto fornisce (ciò che mi sembra) una soluzione perfettamente valida al problema, sebbene richieda due comandi anziché uno.
Jon Bentley,

Avrai davvero bisogno di scrivere uno script con un ciclo per usare questa risposta, poiché non tiene conto di più file e cartelle.
Gringo Suave,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.