¿Cómo sincronizar un archivo grande, con el menor gasto de CPU y ancho de banda posible?

13

Tengo un archivo de 500 GB que planeo hacer una copia de seguridad de forma remota. El archivo cambia a menudo. Lo estaré sincronizando desde un escritorio a un servidor. Ambos pueden ejecutar rsync cliente o servidor.

¿Cuál es el comando apropiado para esto? Los que he probado sofar se han estado tomando para siempre o simplemente han actuado de manera extraña.

Ejemplo y resultados:

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

Parece funcionar, pero solo si lo hago dos veces (?!). Además, lento.

¿El comando anterior realiza la suma de comprobación en ambas computadoras, o solo en la que envía? ¿Es correcto lo contrario?

rsync

— Johan Allgoth
fuente

¿Un archivo tan grande que cambia a menudo? Obtendrás resultados muy, muy decepcionantes con rsync ...

— Ignacio Vazquez-Abrams

¿Cualquier otra sugerencia? Debería ser factible con alguna aplicación, el cliente propietario de Dropbox lo hace muy bien. Ver foros.dropbox.com/topic.php?id=17631

— Johan Allgoth

--inplace implica --parte parcial: linux.die.net/man/1/rsync

— Ray Hulha

12

Nunca va a ser rápido, porque rsync tendrá que leer / sumar el archivo completo, y leer 500GB llevará mucho tiempo, a menos que lo tenga almacenado en SSD o algo así.

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

-csignifica que suma el archivo entero ANTES de hacer cualquier transferencia, en lugar de usar la marca de tiempo para ver si ha cambiado, lo que significa leer el archivo completo dos veces. Si la marca de tiempo no se cambia (debería), entonces podría simplemente touchel archivo antes de ejecutar rsync.

Si esto no está programado, puede agregarlo --progresspara que pueda ver cómo se está ejecutando.

— Dentrasi
fuente

Sí, sé 'archivo grande == manejo largo'. Pero siento que me falta algo aquí, vea el comentario anterior. Si Dropbox puede hacerlo, ¡nosotros también! =) No lo dije, pero también lo intenté sin -c, aún lento.

— Johan Allgoth

2

también --inplaceimplica--partial

2

Aunque no es rsync, dependiendo de lo que intente hacer, esto puede funcionar mejor. Estaba haciendo una tarea de respaldo similar y definitivamente fue más rápida.

Use netcat para hacer un tubo de alquitrán de una máquina a otra.

En su máquina fuente:

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

Está creando un tarball que conserva los permisos y el tiempo, luego lo conecta a netcat en el puerto 45454

En su máquina de respaldo

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

X.X.X.X = dirección IP local de su máquina fuente.

Para mí, esto funcionó bien. Funcionó a 25-30 MB / s sobre LAN cableada en lugar de 2-3 MB / s con rsync. La desventaja es que no se sincroniza, solo hace una copia de lo que está en su fuente. Sin embargo, para una copia de seguridad como la que está describiendo, un archivo de 500 GB, podría funcionar muy bien.

Puede que tenga que hacer esto como root para evitar problemas de permisos, o puede tener suerte.

FWIW, inicialmente aprendí sobre esto aquí: http://www.screenage.de/blog/2007/12/30/using-netcat-and-tar-for-network-file-transfer/

— SteveLambert
fuente

1

tares mejor que rsynccuando tienes muchos archivos pequeños para transferir. El uso nctambién mejora la velocidad de transferencia cuando está en una conexión rápida, porque no tiene la sobrecarga del cifrado SSH (que no necesito en una conexión de igual a igual)

— jornane

0

Para evitar la sobrecarga de la red, simplemente use el protocolo rsync y no SSH. Por defecto, rsync usa SSH cuando especifica una URL como hostname: / path. Use rsync: // hostname / path en su lugar para usar el protocolo rsync más rápido. No se necesitan trucos con tar / netcat de esta manera. El algoritmo rsync delta debería ser mucho más rápido.

Consulte también https://gergap.wordpress.com/tag/rsync/ para obtener más información.

— gergap
fuente