Come risincronizzare un file di grandi dimensioni, con il minor costo possibile di CPU e larghezza di banda?

13

Ho un file da 500 GB di cui prevedo di eseguire il backup in remoto. Il file cambia spesso. Lo sincronizzerò da un desktop a un server. Entrambi possono eseguire client o server rsync.

Qual è il comando corretto per questo? Quelli che ho provato con Sofar sono durati da sempre o hanno semplicemente agito in modo strano.

Esempio e risultati:

rsync -cv --partial --inplace --no-whole-file /desktop/file1 myserver.com::module/file1

Sembra funzionare, ma solo se lo faccio due volte (?!). Inoltre, lento.

Il comando sopra fa il checksum su entrambi i computer o solo su quello di invio? È corretto altrimenti?

rsync

— Johan Allgoth
fonte

Un file così grande che cambia spesso? Otterrai risultati molto, molto deludenti con rsync ...

— Ignacio Vazquez-Abrams,

Altri suggerimenti? Dovrei essere fattibile con alcune app, il client proprietario di Dropbox lo fa molto bene. Vedi forum.dropbox.com/topic.php?id=17631

— Johan Allgoth,

--inplace implica --partial see: linux.die.net/man/1/rsync

— Ray Hulha

12

Non sarà mai veloce, perché rsync dovrà leggere / fare il checksum dell'intero file e la lettura di 500 GB richiederà molto tempo, a meno che tu non lo abbia archiviato su SSD o qualcosa del genere.

Prova rsync -vhz --partial --inplace <file/server stuff>.

-csignifica che esegue il checksum dell'intero file PRIMA di eseguire qualsiasi trasferimento, anziché utilizzare il timestamp per vedere se è cambiato, il che significa leggere l'intero file due volte. Se il timestamp non viene modificato (dovrebbe), è possibile solo touchil file prima di eseguire rsync.

Se questo non è scritto, puoi aggiungere in --progressmodo da poter vedere come sta andando.

— Dentrasi
fonte

Sì, conosco "file di grandi dimensioni == gestione lunga". Ma sento che mi manca qualcosa qui, vedi il commento sopra. Se Dropbox può farlo, anche noi! =) Non ho detto, ma ho anche provato senza -c, ancora lento.

— Johan Allgoth,

2

--inplaceimplica anche--partial

2

Anche se non è rsync, a seconda di cosa stai cercando di fare questo potrebbe funzionare meglio. Stavo eseguendo un'attività di backup simile ed era decisamente più veloce.

Usa netcat per creare un tubo di catrame da una macchina all'altra.

Sul tuo computer di origine:

tar -cpv --atime-preserve=system . | nc -q 10 -l -p 45454

Stai creando un tarball che conserva permessi e tempo, quindi lo instrada in netcat sulla porta 45454

Sul tuo computer di backup

nc -w 10 X.X.X.X 45454 | tar -xpv

X.X.X.X = indirizzo IP locale del computer di origine.

Per me, ha funzionato bene. Funzionava a 25-30 MB / s su LAN cablata rispetto a 2-3 MB / s con rsync. Lo svantaggio è: non si sincronizza, crea solo una copia di ciò che è sulla tua fonte. Per un backup come quello che stai descrivendo, un file da 500 GB, potrebbe funzionare molto bene.

Potrebbe essere necessario eseguire questa operazione come root per evitare problemi con le autorizzazioni, oppure potresti essere fortunato.

FWIW, inizialmente ho imparato questo qui: http://www.screenage.de/blog/2007/12/30/using-netcat-and-tar-for-network-file-transfer/

— SteveLambert
fonte

1

tarè meglio di rsyncquando hai molti file di piccole dimensioni da trasferire. L'utilizzo ncmigliora anche la velocità di trasferimento su una connessione veloce, perché non si ha l'overhead della crittografia SSH (che non mi serve su una connessione peer-to-peer)

— jornane,

0

Per evitare il sovraccarico della rete basta usare il protocollo rsync e non SSH. Per impostazione predefinita, rsync utilizza SSH quando si specifica un URL come hostname: / path. Utilizzare invece rsync: // nomehost / percorso invece di utilizzare il protocollo rsync più veloce. In questo modo non sono necessari trucchi con tar / netcat. L'algoritmo delta rsync dovrebbe essere molto più veloce.

Vedi anche https://gergap.wordpress.com/tag/rsync/ per ulteriori informazioni.

— gergap
fonte