Mi ritrovo spesso a inviare cartelle con 10K - 100K di file a una macchina remota (all'interno della stessa rete nel campus).

Mi chiedevo solo se ci sono ragioni per crederlo,

 tar + rsync + untar

O semplicemente

 tar (from src to dest) + untar

potrebbe essere più veloce in pratica di

rsync 

quando si trasferiscono i file per la prima volta .

Sono interessato a una risposta che affronti quanto sopra in due scenari: usare la compressione e non usarla.

Aggiornare

Ho appena eseguito alcuni esperimenti spostando 10.000 piccoli file (dimensione totale = 50 MB) ed è tar+rsync+untarstato costantemente più veloce rispetto all'esecuzione rsyncdiretta (entrambi senza compressione).

Quando si invia lo stesso set di file, rsyncè più adatto perché invierà solo differenze. tarinvierà sempre tutto e questo è uno spreco di risorse quando molti dei dati sono già lì. In tar + rsync + untarquesto caso perde questo vantaggio, oltre al vantaggio di mantenere sincronizzate le cartelle rsync --delete.

Se copi i file per la prima volta, prima impacchettando, poi inviando, quindi spacchettando (AFAIK rsyncnon accetta l'input di piping) è ingombrante e sempre peggio del semplice risincronizzazione, perché rsyncnon dovrà svolgere alcuna attività più che tarcomunque.

Suggerimento: rsync versione 3 o successive esegue una ricorsione incrementale, il che significa che inizia a copiare quasi immediatamente prima di contare tutti i file.

Suggerimento 2: se usi rsyncoltre ssh, puoi anche usare uno di questitar+ssh

tar -C /src/dir -jcf - ./ | ssh user@server 'tar -C /dest/dir -jxf -'

o solo scp

scp -Cr srcdir user@server:destdir

Regola generale, mantienila semplice.

AGGIORNARE:

Ho creato 59M di dati dimostrativi

mkdir tmp; cd tmp
for i in {1..5000}; do dd if=/dev/urandom of=file$i count=1 bs=10k; done

e testato più volte il trasferimento dei file su un server remoto (non nella stessa lan), usando entrambi i metodi

time rsync -r  tmp server:tmp2

real    0m11.520s
user    0m0.940s
sys     0m0.472s

time (tar cf demo.tar tmp; rsync demo.tar server: ; ssh server 'tar xf demo.tar; rm demo.tar'; rm demo.tar)

real    0m15.026s
user    0m0.944s
sys     0m0.700s

mantenendo registri separati dai pacchetti di traffico ssh inviati

wc -l rsync.log rsync+tar.log 
   36730 rsync.log
   37962 rsync+tar.log
   74692 total

In questo caso, non riesco a vedere alcun vantaggio in meno traffico di rete utilizzando rsync + tar, che è previsto quando il mtu predefinito è 1500 e mentre i file hanno dimensioni 10k. rsync + tar ha generato più traffico, è stato più lento per 2-3 secondi e ha lasciato due file spazzatura che dovevano essere ripuliti.

Ho fatto gli stessi test su due macchine sulla stessa lan, e lì rsync + tar ha fatto tempi molto migliori e molto meno traffico di rete. Presumo causa di frame jumbo.

Forse rsync + tar sarebbe meglio di rsync su un set di dati molto più grande. Ma sinceramente non penso che valga la pena, hai bisogno di doppio spazio su ogni lato per l'imballaggio e il disimballaggio, e ci sono un paio di altre opzioni come ho già menzionato sopra.

rsyncfa anche la compressione. Usa la -zbandiera. Se lo investi ssh, puoi anche usare la modalità di compressione di ssh. La mia sensazione è che livelli ripetuti di compressione non siano utili; brucerà solo cicli senza risultati significativi. Consiglierei di sperimentare con la rsynccompressione. Sembra abbastanza efficace. E suggerirei di saltare l'utilizzo taro qualsiasi altra compressione pre / post.

Di solito uso rsync come rsync -abvz --partial....

Oggi ho dovuto eseguire il backup della mia home directory sul NAS e ho partecipato a questa discussione, pensando di aggiungere i miei risultati. Per farla breve, eseguire il taring sulla rete verso il file system di destinazione è molto più veloce nel mio ambiente rispetto alla sincronizzazione verso la stessa destinazione.

Ambiente: computer desktop i7 di origine utilizzando il disco rigido SSD. Macchina di destinazione Synology NAS DS413j su una connessione lan gigabit alla macchina di origine.

Le specifiche esatte del kit coinvolto avranno un impatto sulle prestazioni, naturalmente, e non conosco i dettagli della mia configurazione esatta per quanto riguarda la qualità dell'hardware di rete ad ogni estremità.

I file di origine sono la mia cartella ~ / .cache che contiene 1,2 GB di file per lo più molto piccoli.

1a/ tar files from source machine over the network to a .tar file on remote machine

$ tar cf /mnt/backup/cache.tar ~/.cache

1b/ untar that tar file on the remote machine itself

$ ssh admin@nas_box
[admin@nas_box] $ tar xf cache.tar

2/ rsync files from source machine over the network to remote machine

$ mkdir /mnt/backup/cachetest
$ rsync -ah .cache /mnt/backup/cachetest

Ho tenuto 1a e 1b come passaggi completamente separati solo per illustrare l'attività. Per applicazioni pratiche consiglierei ciò che Gilles ha pubblicato sopra che coinvolge l'output di catrame via ssh a un processo non impegnativo sul ricevitore.

Tempi:

1a - 33 seconds

1b - 1 minutes 48 seconds

2 - 22 minutes

È molto chiaro che rsync ha funzionato incredibilmente male rispetto a un'operazione tar, che presumibilmente può essere attribuita a entrambe le prestazioni di rete sopra menzionate.

Consiglierei a chiunque voglia eseguire il backup di grandi quantità di file per lo più piccoli, come un backup della directory principale, utilizzare l'approccio tar. rsync sembra una scelta molto scarsa. Tornerò a questo post se mi sembra di essere stato impreciso in nessuna delle mie procedure.

tacca

L'uso di rsync per inviare un archivio tar come richiesto in realtà sarebbe uno spreco o risorse, dal momento che aggiungerebbe un livello di verifica al processo. Rsync eseguirà il checksum del file tar per la correttezza, quando preferisci avere il controllo sui singoli file. (Non aiuta a sapere che il file tar che potrebbe essere stato difettoso sul lato mittente mostra già lo stesso effetto sul lato ricevente). Se stai inviando un archivio, ssh / scp è tutto ciò di cui hai bisogno.

L'unico motivo per cui potresti dover selezionare l'invio di un archivio sarebbe se il tar di tua scelta fosse in grado di preservare un numero maggiore di speciali del filesystem, come Elenco controllo accessi o altri metadati spesso memorizzati in Attributi estesi (Solaris) o Forks Ressource (MacOS ). Quando si affrontano queste cose, la principale preoccupazione sarà su quali strumenti sono in grado di conservare tutte le informazioni associate al file sul filesystem di origine, a condizione che anche il filesystem di destinazione abbia la possibilità di tenerne traccia.

Quando la velocità è la tua principale preoccupazione, dipende molto dalla dimensione dei tuoi file. In generale, una moltitudine di piccoli file si ridimensionerà male su rsync o scp, poiché tutti sprecheranno singoli pacchetti di rete ciascuno, dove un file tar ne includerebbe diversi nel carico di dati di un singolo pacchetto di rete. Ancora meglio se il file tar fosse compresso, dal momento che i file piccoli molto probabilmente comprimerebbero meglio nel loro insieme che individualmente. Per quanto ne so, sia rsync che scp non riescono a ottimizzare quando si inviano interi file singoli come in un trasferimento iniziale, avendo ogni file occupa un intero frame di dati con il suo intero overhead di protocollo (e sprecando di più nel controllo avanti e indietro). Comunque Janecekafferma che questo vale solo per scp, trattenendo che rsync ottimizzerebbe il traffico di rete ma a costo di costruire enormi strutture di dati in memoria. Vedi l'articolo Efficient File Transfer, Janecek 2006 . Quindi secondo lui è ancora vero che sia scp che rsync si scalano male su file di piccole dimensioni, ma per ragioni completamente diverse. Immagino che dovrò scavare nelle fonti questo fine settimana per scoprirlo.

Per rilevanza pratica, se sai che stai inviando file per lo più grandi, non ci sarà molta differenza nella velocità e l'uso di rsync ha l'ulteriore vantaggio di essere in grado di riprendere da dove è stato interrotto.

Postscriptum: oggigiorno rdist sembra sprofondare nell'oblio, ma prima dei giorni di rsync era uno strumento molto capace e ampiamente usato (sicuro se usato su ssh, non sicuro altrimenti). Non mi sarei comportato bene come rsync, dato che non si ottimizzava solo per trasferire il contenuto che era cambiato. La sua principale differenza con rsync sta nel modo in cui è configurato e nel modo in cui sono spiegate le regole per l'aggiornamento dei file.

Per le directory piccole (piccole come nello spazio su disco utilizzato), dipende dal sovraccarico di controllare le informazioni sui file per i file da sincronizzare. Da un lato, rsyncconsente di risparmiare il tempo di trasferimento dei file non modificati, dall'altro, infatti, deve trasferire informazioni su ciascun file.

Non conosco esattamente gli interni di rsync. Il ritardo tra le statistiche dei file dipende dal modo in cui i rsyncdati vengono trasferiti: se le statistiche dei file vengono trasferite una ad una, RTT può rendere tar + rsync + untar più veloce.

Ma se hai, diciamo 1 GiB di dati, rsync sarà molto più veloce, beh, a meno che la tua connessione non sia davvero veloce!

Ho dovuto spostare alcuni terabyte di dati in tutto il paese, esattamente una volta. Come esperimento, ho eseguito due trasferimenti usando rsynce ssh/tarper vedere come si confrontano.

I risultati:

• rsync trasferito i file a una velocità media di 2,76 megabyte al secondo.
• ssh/tar trasferito i file a una velocità media di 4,18 megabyte al secondo.

I dettagli: I miei dati sono costituiti da milioni di file compressi .gz, la cui dimensione media è di 10 megabyte ma alcuni hanno dimensioni superiori a un gigabyte. C'è una struttura di directory ma è sminuita dalla dimensione dei dati all'interno dei file. Se avessi avuto quasi qualcos'altro da fare, avrei usato solo, rsyncma in questo caso, ssh/tarè una soluzione funzionale.

Il mio lavoro rsyncconsiste in:

rsync --compress --stats --no-blocking-io --files-from=fileList.txt -av otherSystem:/the/other/dir/ dest/

dove fileList.txt è un lungo elenco dei relativi percorsi dei file sull'altro lato. (Ho notato che --compressnon è produttivo per i file compressi dopo l'avvio, ma non avevo intenzione di tornare indietro.)

Ne ho iniziato un altro con ssh e tar che ha:

ssh otherSystem "cd /the/other/dir/;  tar cf - ." | tar xvf -

Osserverai tutto questo, mi dispiace che questo non sia un confronto al 100% tra mele e mele.

Dovrei aggiungere che mentre sto usando la rete aziendale interna, devo passare attraverso un intermediario per accedere al computer dell'origine dati. Il tempo di ping dal mio computer di destinazione all'intermediario è di 21 ms e dall'intermediario all'origine dati è di 26 ms. Questo è stato lo stesso per entrambi i trasferimenti.

La connessione SSL tramite l'intermediario viene effettuata tramite la ~/.ssh/configvoce:

Host otherSystem
    Hostname dataSource.otherSide.com
    User myUser
    Port 22
    ProxyCommand ssh -q -W %h:%p intermediary.otherSide.com
    IdentityFile   id_rsa.priv

Tempo questo:

tar cf - ~/.cache | ssh admin@nas_box "(cd /destination ; tar xf -)"