Per i file di grandi dimensioni comprimere prima quindi trasferire o rsync -z? quale sarebbe più veloce?

Ho un sacco di relatività piccoli file di dati ma occupano circa 50 GB e ho bisogno che vengano trasferiti su una macchina diversa. Stavo cercando di pensare al modo più efficiente per farlo.

Pensavo di dover decomprimere tutto, quindi risincronizzarlo e decomprimerlo, fare affidamento su rsync -z per la compressione, gzip quindi utilizzare rsync -z. Non sono sicuro di quale sarebbe il più efficiente poiché non sono sicuro di come sia implementata esattamente rsync -z. Qualche idea su quale opzione sarebbe la più veloce?

Non puoi "gzip il tutto" in quanto gzip comprime solo un file, puoi creare un file tar e gzip per "gzip il tutto" ma perderai la capacità rsync di copiare solo il file modificato.

Quindi la domanda è: è meglio archiviare i file che devo rsync gziped o fare affidamento sull'opzione -z di rsync.
La risposta è probabilmente che non vuoi che il file venga decompresso sul tuo server? Immagino di si, quindi non vedo come potresti riuscire a gzip file prima di fare rsync.

Forse non hai bisogno della capacità rsync di copiare solo file modificati? In questo caso, perché usare rsync invece di fare uno scp di un file tar.gz contenente le tue cose?

Comunque per rispondere alla domanda, rsync gzip sarà un po 'meno efficiente del file gziping con gzip. Perché ? poiché rsync gzip i pezzi di dati per pezzo, quindi verrà utilizzato un set di dati più piccolo per creare la tabella utilizzata da gzip per eseguire la compressione, un set di dati più grande (gzip userebbe l'intero file in una sola volta) per fornire una tabella di compressione migliore. Ma la differenza sarà molto piccola nella maggior parte dei casi, ma in casi molto rari la differenza può essere più importante (se si dispone di un file molto grande con partern molto lungo che si ripete molte volte sul file ma lontano l'uno dall'altro) (Questo è un esempio molto semplificato)

Se stai copiando i dati solo una volta, rsync non sarà una grande vittoria in sé e per sé. Se ti piace gzip, (o tar + gzip, poiché hai molti file), potresti provare qualcosa del tipo:

tar -cz /home/me/source/directory | ssh target tar -xz --directory /home/you/target/directory

Ciò otterrebbe la compressione che stai cercando e basta copiare direttamente senza coinvolgere rsync.

@radius, un piccolo pignolo da scegliere su come gzipfunziona - gzipè un algoritmo di compressione basato su blocchi e abbastanza semplice. L'intero file non viene considerato per la tabella di compressione, ma solo per ciascun blocco. Altri algoritmi possono utilizzare l'intero contenuto del file e ce ne sono alcuni che utilizzano il contenuto di più blocchi o persino blocchi di dimensioni variabili. Un esempio affascinante è lrziplo stesso autore di rsync!

L' gzipalgoritmo skinny on .

Quindi, in sintesi, l'utilizzo rsync -zprobabilmente produrrà la stessa compressione del gzipprimo - e se stai facendo un trasferimento differenziale, meglio a causa rsyncdell'algoritmo diffing.

Detto questo, penso che uno lo troverà regolare scp battitirsync per i trasferimenti non differenziali - perché avrà un sovraccarico molto inferiore rispetto rsyncall'algoritmo (che userebbe comunque scpsotto il cofano!)

Se la rete non diventi un collo di bottiglia, poi si vorrebbe utilizzare la compressione sul filo.

Se tuo dischi sono il collo di bottiglia, è meglio quando lo streaming in un file compresso. (ad esempio, netcatda una macchina all'altra, streaming in gzip -c)

Di solito, se la velocità è la chiave, la compressione di un file esistente prima è dispendiosa.

TIMTOWTDI, YMMV, IANAL, ecc.

Secondo questo ragazzo potrebbe essere più veloce da usare rsync -z, anche se immagino che sarebbe quasi efficiente quanto comprimere ogni file prima di trasferirlo. Dovrebbe essere più veloce della compressione del flusso tar, come suggerito da altri.

Dalla pagina man:

          Note  that  this  option  typically  achieves better compression
          ratios than can be achieved by using a compressing remote  shell
          or  a  compressing  transport  because it takes advantage of the
          implicit information in the matching data blocks  that  are  not
          explicitly sent over the connection.

Poiché sia ​​scp di file compresso che rsync impiegheranno tempi di trasferimento molto simili, il "modo più efficiente per farlo" sarebbe la compressione al volo piuttosto che la compressione, il trasferimento.

Oltre alla "solidità", altre considerazioni includono:

rsync può essere facilmente riavviato se non tutti i file vengono trasferiti.

rsync può essere usato per conservare i file sul computer remoto.

tar locale o gzip richiede spazio locale.

Considerazioni sull'utilizzo delle porte sia per la macchina target che per i firewall: 1) scp utilizza la porta 22 (per impostazione predefinita) che potrebbe non essere accettabile. 2) porta utenti rsync 873 (per impostazione predefinita)

Non sono sicuro del motivo per cui raggio si aspetta che il poster originale NON desideri che vengano archiviati i file decompressi.