Al momento ho due server CentOS. Devo sapere come e quale sarebbe il modo più veloce per "tarare" la directory delle immagini e SCP su di essa?

È questo il modo più rapido che ho appena suggerito, perché il tarring richiede sempre ... Ho eseguito il comando:

tar cvf imagesbackup.tar images

E stavo per scappare.

Fammi sapere se c'è un modo più veloce. Ho accesso remoto / SSH ad entrambe le macchine.

Invece di usare tar per scrivere sul tuo disco locale, puoi scrivere direttamente sul server remoto sulla rete usando ssh.

server1$ tar -zc ./path | ssh server2 "cat > ~/file.tar.gz"

Qualsiasi stringa che segue il comando "ssh" verrà eseguita sul server remoto invece dell'accesso interattivo. È possibile reindirizzare input / output da e verso quei comandi remoti tramite SSH come se fossero locali. Mettere il comando tra virgolette evita qualsiasi confusione, specialmente quando si utilizza il reindirizzamento.

In alternativa, è possibile estrarre direttamente il file tar sull'altro server:

server1$ tar -zc ./path | ssh server2 "tar -zx -C /destination"

Nota l' -Copzione usata di rado . Significa "passare a questa directory prima di fare qualsiasi cosa".

O forse vuoi "estrarre" dal server di destinazione:

server2$ tar -zx -C /destination < <(ssh server2 "tar -zc -C /srcdir ./path")

Nota che il <(cmd) costrutto è nuovo per bash e non funziona su sistemi più vecchi. Esegue un programma e invia l'output a una pipe e sostituisce quella pipe nel comando come se fosse un file.

Avrei potuto facilmente scrivere quanto sopra come segue:

server2$ tar -zx -C /destination -f <(ssh server2 "tar -zc -C /srcdir ./path")

O come segue:

server2$ ssh server2 "tar -zc -C /srcdir ./path" | tar -zx -C /destination

Oppure, puoi risparmiare un po 'di dolore e usare semplicemente rsync:

server1$ rsync -az ./path server2:/destination/

Infine, ricorda che la compressione dei dati prima del trasferimento ridurrà la larghezza di banda, ma su una connessione molto veloce, l'operazione potrebbe richiedere più tempo . Questo perché il tuo computer potrebbe non essere in grado di comprimere abbastanza velocemente da tenere il passo: se comprimere 100 MB impiega più tempo di quello necessario per inviare 100 MB, allora è più veloce inviarlo non compresso.

In alternativa, potresti prendere in considerazione l'idea di eseguire il piping di gzip (anziché utilizzare l'opzione -z) in modo da poter specificare un livello di compressione. È stata la mia esperienza che su connessioni di rete veloci con dati comprimibili, l'uso di gzip a livello 2 o 3 (il valore predefinito è 6) offre la migliore velocità complessiva nella maggior parte dei casi. Così:

server1$ tar -c ./path | gzip -2 | ssh server2 "cat > ~/file.tar.gz"

Sarei tentato di risincronizzarlo su di me: fa la compressione e gestisce bene la perdita dei collegamenti.

Se li accumuli e nient'altro, questo farà perdere tonnellate di tempo con un guadagno di velocità minimo.

Quindi semplicemente tarare i file con gli switch cvf costerà effettivamente il tempo necessario per leggere tutte le immagini da 55 GB e riscriverle sul disco. (In effetti sarà ancora più tempo sprecato poiché ci sarà un notevole sovraccarico).

C'è solo un vantaggio che ottieni qui, l'overhead per il caricamento di molti file è stato ridotto. Potresti ottenere tempi di trasferimento più rapidi se comprimi le immagini (ma poiché credo che siano già in un formato compresso questo non sarà di grande aiuto). Solo più spreco di tempo di elaborazione.

Il più grande svantaggio derivante dal trasferimento di un enorme archivio tar su filo è che se qualcosa va storto potrebbe significare che devi ricominciare da capo.

Vorrei usare in questo modo:

md5sum /images/* > md5sum.txt
scp -r images/* user@host:/images/

Sul nuovo server

md5sum /images/* > md5sum_new.txt

E poi solo diff. E poiché scp supporta la compressione al volo non è necessario disporre di archivi separati.

modificare

Manterrò le informazioni MD5 poiché erano utili all'OP. Ma un commento mi ha colpito con nuove intuizioni. Quindi un po 'di ricerca ha fornito questa utile informazione. Si prega di notare che l'oggetto qui è SFTP non direttamente SCP .

A differenza di FTP, SFTP aggiunge sovraccarico al trasferimento di file. Quando un file viene trasferito tra client e server, viene suddiviso in blocchi più piccoli chiamati "pacchetti". Ad esempio, supponiamo che ogni pacchetto sia di 32 KB. Il protocollo SFTP esegue un checksum su ciascun file da 32 KB al momento dell'invio e include tale checksum insieme a quel pacchetto. Il destinatario ottiene quel pacchetto e decodifica i dati, quindi verifica il checksum. Il checksum stesso è "più forte" del checksum CRC32. (Poiché SFTP utilizza un checksum a 128 bit o superiore, come MD5 o SHA, e poiché questo viene eseguito su ogni singolo pacchetto, esiste un controllo di integrità molto granulare che viene eseguito come parte del trasferimento.) Pertanto, il protocollo di per sé è più lento (a causa del sovraccarico aggiuntivo), ma il completamento con successo di un trasferimento significa, di fatto,

Oltre al suggerimento md5sum di Pacey, utilizzerei quanto segue:

Sulla destinazione: nc -w5 -l -p 4567 | tar -xvf -

Quindi sulla fonte: tar -cvf - /path/to/source/ | nc -w5 destinationserver 4567

È ancora un tar / untar e non c'è crittografia, ma è diretto all'altro server. Iniziali entrambi in tandem ( -w5ti dà 5 secondi di grazia.) E guardalo andare. Se la larghezza di banda è ridotta, aggiungi -z al tar su entrambe le estremità.

Un punto: non tutti gli host hanno rsync e gli host potrebbero avere versioni diverse di tar. Per questo motivo, si potrebbe raccomandare come prima porta di chiamata utilizzando il cpio spesso trascurato.

È possibile cpio su ssh per eseguire la replica ad hoc delle strutture di file / directory tra host. In questo modo hai un controllo più preciso su ciò che viene inviato visto che è necessario "alimentare" cpio, nom-nom. È anche più portatile, cpio non cambia molto - questo è un punto importante se stai cercando più host in un ambiente eterogeneo.

Esempio di copia / esportazione / home e sottocartelle sull'host remoto:

cd /export/ find . home -print | cpio -oaV | ssh 10.10.10.10 'cd /export/home; cpio -imVd'

Quanto sopra copierebbe il contenuto di / export / home e tutti i sottodirectory in / export / home sull'host remoto.

Spero che sia di aiuto.

Se hai accesso ssh, hai accesso rsync.

rsync -av -e ssh /storage/images/ user@[ip or domain name]:/storage/images/

o

rsync -av -e "ssh -l user" /storage/images/ [ip or domain name]:/storage/images/

Se ricevi un errore come "errore rsync: alcuni file non possono essere trasferiti (codice 23) su main.c (977) [mittente = 2.6.9]", controlla il tuo utente e i gruppi tra i server; potresti non avere una corrispondenza.

Utilizzare l'opzione "-z" di rsync se si desidera che rsync comprima il trasferimento. Questa opzione utilizzerà più CPU ma meno larghezza di banda, quindi fai attenzione.

C'è un'opzione "--progress" che ti darà una percentuale trasferita, il che è carino se ti piace quel genere di cose.

Sono su una rete condivisa invece di aver bisogno di Internet per trasferire file? NFS o FTP potrebbero essere molto più veloci del sovraccarico di SCP, anche se si perderebbe la crittografia durante il trasferimento.

Oppure puoi sempre usare i tubi di catrame:

(cd /path && tar -cjf - * ) | ssh user@host 'tar -xjf - -C /path'

'j' = bzip2, puoi usare 'z' per gzip o --lzma se il tuo tar lo supporta.