Devo verificare la corruzione dei file una volta fatto scp?

17

Ho trasferito in modo ricorsivo molti file e cartelle con scp, usando il comando:

scp -rp /source/folder myremoteusername@122.10.12.123:/destination/folder

Una volta completato il trasferimento, devo verificare se tutti i file sono stati trasferiti senza alcun danneggiamento o se ne scpoccupano (ad esempio visualizza un messaggio di errore se uno dei file non viene trasferito correttamente)?

scp

— Franck Dernoncourt
fonte

A meno che tu non ottenga uno stato di uscita diverso da zero scpe un messaggio di errore di accompagnamento a stderr , avrà copiato tutto correttamente e completamente.

— roaima,

un po tl; dr al mio post: usa rsyncse puoi. Copia le convalide per ogni file al termine di una transazione, quindi è una buona idea usarlo solo per essere un po 'più sicuro.

— polemon

24

scpverifica che abbia copiato tutti i dati inviati dall'altra parte. L'integrità del trasferimento è garantita dal protocollo del canale crittografico. Quindi non è necessario verificare l'integrità dopo il trasferimento. Sarebbe ridondante e molto probabilmente non rileverà alcun errore hardware poiché i dati a cui stai confrontando verrebbero probabilmente letti dalla cache. La verifica periodica dei dati può essere utile, ma verificare immediatamente dopo il trasferimento è inutile.

Tuttavia, devi assicurarti che scpnon ti dica che qualcosa è andato storto. Dovrebbe esserci un messaggio di errore, ma l'indicatore affidabile è che scprestituisce un codice di uscita diverso da zero se qualcosa è andato storto.

Più precisamente, sai che il file è stato trasmesso correttamente se scprestituisce 0 (ovvero il codice dello stato di successo). Verificare che lo stato di uscita sia 0 è necessario quando si esegue comunque un comando. Se scprestituisce uno stato di errore, o se viene ucciso da un segnale, o se non muore mai perché il sistema si arresta in modo anomalo o perde energia mentre è in esecuzione, non hai garanzie. In particolare, poiché scpcopia il file direttamente sul suo nome finale, ciò significa che puoi finire con un file parziale in caso di crash del sistema. La parte copiata è garantita come corretta ma il file potrebbe essere troncato.

Per una migliore affidabilità, utilizzare rsync invece di scp. Salvo diversa indicazione, rsync scrive su un file temporaneo e lo sposta in posizione al termine. Quindi, se rsync restituisce un codice di successo, sai che il file è presente e una copia corretta e completa; se rsync non ha restituito un codice di errore, non sarà presente alcun file (a meno che non esistesse una versione precedente del file, nel qual caso quella versione precedente non verrà modificata).

— Gilles 'SO- smetti di essere malvagio'
fonte

3

Non ho mai avuto problemi con la corruzione dopo che ho scpqualcosa, ma se sei preoccupato per questo puoi sempre eseguire md5sum <filename>su entrambi i sistemi per assicurarti che siano uguali.

— David King
fonte

3

Secondo il suggerimento di @ david-king, questa è una md5soluzione basata per verificare l'integrità dei file dopo il trasferimento. Eseguire il seguente comando una volta dopo cding a /source/foldersulla macchina locale e una volta dopo cding al /destination/foldersull'host remoto: find . -type f -print0 | xargs -0 -I {} md5sum {} | md5sum. L'hash risultante dovrebbe essere identico dopo un trasferimento riuscito.

Aggiornare: ~~Secondo questa risposta a una domanda simile su ServerFault , scpnon garantisce l'integrità dei file~~(Controlla questa risposta di @Gilles per i dettagli). In alternativa al controllo post-trasferimento degli hash dei file, è possibile utilizzarersync per trasferire i file e verificarne il codice di ritorno.

Aggiornamento 2: Di seguito viene verificato solo se i file e le rispettive dimensioni corrispondono dopo il trasferimento:find . -type f -print0 | xargs -0 -I {} stat --printf="%n %s\n" {} | sort | md5sum

— Mani M
fonte

2

Se scp restituisce 0, l'integrità è garantita. Inoltre, se scp non restituisce 0, il problema non è la corruzione generica ma in particolare il troncamento; la verifica della dimensione del file è sufficiente (a meno che non esistesse già una versione precedente del file di destinazione: se scp è stato interrotto molto presto, la versione precedente potrebbe essere ancora presente). La verifica dei checksum qui è una perdita di tempo.

— Gilles 'SO- smetti di essere cattivo' il

Giusto. Ho aggiornato la mia risposta.

— Mani M

Non hai risolto il difetto fondamentale. Il controllo scpdel codice di ritorno è sufficiente e il controllo degli hash è inutile.

— Gilles 'SO- smetti di essere malvagio' il

1

Anche se scprestituisce 0 non garantisce che il file system non ha incasinato le cose, in modo da controllare gli hash è ancora utile per verificare l'integrità dei dati sensibili, se qualcuno sceglie di utilizzare scpnel corso rsync.

— Mani M,