La forma más rápida de transferir 55 GB de imágenes a un nuevo servidor


64

Actualmente tengo dos servidores CentOS. ¿Necesito saber cómo y cuál sería la forma más rápida de "tar" en el directorio de imágenes y SCP?

¿Es esa la forma más rápida que acabo de sugerir, porque la tardanza está tomando una eternidad ... Ejecuté el comando:

tar cvf imagesbackup.tar images

Y yo solo iba a analizarlo.

Avísame si hay una manera más rápida. Tengo acceso remoto / SSH a ambas máquinas.


12
Sneakernet?
Nick T

Respuestas:


98

En lugar de usar tar para escribir en su disco local, puede escribir directamente en el servidor remoto a través de la red usando ssh.

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

Cualquier cadena que siga su comando "ssh" se ejecutará en el servidor remoto en lugar del inicio de sesión interactivo. Puede canalizar la entrada / salida hacia y desde esos comandos remotos a través de SSH como si fueran locales. Poner el comando entre comillas evita cualquier confusión, especialmente cuando se usa la redirección.

O bien, puede extraer el archivo tar en el otro servidor directamente:

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

Tenga en cuenta la -Copción rara vez utilizada . Significa "cambiar a este directorio primero antes de hacer algo".

O, tal vez desee "extraer" del servidor de destino:

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

Tenga en cuenta que la <(cmd) construcción es nueva para bash y no funciona en sistemas más antiguos. Ejecuta un programa y envía la salida a una tubería, y la sustituye en el comando como si fuera un archivo.

Podría haber escrito fácilmente lo anterior de la siguiente manera:

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

O como sigue:

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

O bien, puede ahorrarse algo de pena y simplemente usar rsync:

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

Finalmente, recuerde que comprimir los datos antes de la transferencia reducirá su ancho de banda, pero en una conexión muy rápida, puede hacer que la operación tome más tiempo . Esto se debe a que es posible que su computadora no pueda comprimir lo suficientemente rápido como para mantener el ritmo: si comprimir 100 MB demora más de lo necesario para enviar 100 MB, entonces es más rápido enviarlo sin comprimir.

Alternativamente, es posible que desee considerar la canalización para gzip usted mismo (en lugar de usar la opción -z) para que pueda especificar un nivel de compresión. Según mi experiencia, en conexiones de red rápidas con datos comprimibles, el uso de gzip en el nivel 2 o 3 (el valor predeterminado es 6) proporciona el mejor rendimiento general en la mayoría de los casos. Al igual que:

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

Rsync funcionó de maravilla: comprime sobre la marcha, copia carpetas completas, reanuda el enlace roto. Todo en un simple comando. Quiéralo. Estas son las opciones que encontré útiles: z: comprimir r: recurse = copiar subcarpeta v: detallado. Ejemplo de mi comando Rsync: rsync -azvr / src-path / username @ dest_server: / dest / path /
Bastión

68

Me sentiría tentado a sincronizarlo conmigo mismo: hace la compresión y maneja bien la pérdida de enlaces.


14
rsync es exactamente la herramienta correcta.
Rico

44
+1 - ¡Yay rsync!
Evan Anderson

1
+1, solo para apilar. Además, me gusta mucho rsync.
Steven lunes

1
Pero cuando se utiliza rsync tendrá que comprimir los datos manualmente de todos modos (si desea almacenar los datos comprimidos)
Wlk

¿Cómo puede almacenar los archivos comprimidos con rsync?
Dolan Antenucci

12

Si solo los alquilas y nada más, esto perderá toneladas de tiempo con una ganancia de velocidad mínima.

Por lo tanto, simplemente tarar los archivos con los conmutadores cvf costará efectivamente el tiempo que lleva leer todas las imágenes de 55 GB y volver a escribirlas en el disco. (Efectivamente, se perderá aún más tiempo ya que habrá una sobrecarga considerable).

Aquí solo hay una ventaja: se reduce la sobrecarga para cargar muchos archivos. Puede obtener tiempos de transferencia más rápidos si comprime las imágenes (pero como creo que ya están en un formato comprimido, esto no será de mucha ayuda). Simplemente más pérdida de tiempo de computación.

La mayor desventaja de transferir un archivo de alquitrán enorme por cable es que si algo sale mal, podría significar que debe comenzar de nuevo.

Yo usaría de esa manera:

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

En el nuevo servidor

md5sum /images/* > md5sum_new.txt

Y luego solo diff. Y dado que scp admite la compresión sobre la marcha, no hay necesidad de archivos separados.

Editar

Mantendré la información MD5 ya que fue útil para el OP. Pero un comentario me golpeó con una nueva visión. Así que un poco de búsqueda proporcionó esta información útil. Tenga en cuenta que el tema aquí es SFTP, no directamente SCP .

A diferencia de FTP, SFTP agrega gastos generales a la transferencia de archivos. A medida que un archivo se transfiere entre el cliente y el servidor, se divide en fragmentos más pequeños llamados "paquetes". Por ejemplo, supongamos que cada paquete es de 32 KB. El protocolo SFTP realiza una suma de comprobación en cada archivo de 32 KB a medida que se envía, e incluye esa suma de comprobación junto con ese paquete. El receptor obtiene ese paquete y descifra los datos, y luego verifica la suma de verificación. La suma de verificación en sí es "más fuerte" que la suma de verificación CRC32. (Debido a que SFTP utiliza una suma de verificación de 128 bits o más, como MD5 o SHA, y debido a que esto se hace en todos y cada uno de los paquetes, hay una verificación de integridad muy granular que se realiza como parte de la transferencia). Por lo tanto, el protocolo en sí es más lento (debido a la sobrecarga adicional), pero la finalización exitosa de una transferencia significa, de hecho


Muchas gracias, ¿qué está haciendo el md5sum? y que es diff? Gracias, actuando ahora!
Andrew Fashion

2
md5sum (o md5) toma una suma de verificación de los archivos. Diff busca diferencias en los archivos (man diff). La suma de comprobación crea una cadena, un hash, que si el archivo se cambia en tránsito ... un poco volteado, un error ... no coincidirá cuando lo vuelva a tomar del otro lado. Para archivos grandes tiene una mayor probabilidad de errores. Es por eso que cuando ve sitios que le permiten descargar archivos .iso, a menudo tienen una suma de comprobación MD5 para que pueda comparar el archivo descargado para asegurarse de que coincida y no esté dañado.
Bart Silverstrim

3
scp está encriptado y garantiza la integridad sobre la línea. Todavía hay una pequeña posibilidad de que los datos estén corruptos en la memoria o en el disco, por supuesto, pero eso es bastante raro.
Ryan Bair

1
¿La sobrecarga de las sumas de verificación SFTP realmente importa en algún sentido práctico? No me lo puedo imaginar. 4 bytes por cada 32768 no suena significativo. Eso es 128 kB por GB. Llamar a eso "más lento" parece una exageración en cualquier cosa, excepto en un sentido teórico aburrido.
underscore_d

8

Además de la sugerencia md5sum de Pacey, usaría lo siguiente:

En el destino: nc -w5 -l -p 4567 | tar -xvf -

Luego en la fuente: tar -cvf - /path/to/source/ | nc -w5 destinationserver 4567

Todavía es un tar / untar, y no hay cifrado, pero es directo al otro servidor. Comience a ambos en tándem ( -w5le da 5 segundos de gracia) y vea cómo se va. Si el ancho de banda es escaso, agregue -z al alquitrán en ambos extremos.


1
Creo que es al revés primero que tiene que ejecutar en el destino (para abrir el zócalo) y luego en la fuente (para enviar)
Dimitrios Mistriotis

en lugar del servidor de destino, ¿acabo de poner root@1.1.1.1?
Andrew Fashion

No, solo la IP. netcat no está utilizando un protocolo que no sea TCP :) Este comando también será el más rápido de todos los comandos anteriores. Hay exactamente una lectura por archivo en la fuente, el tráfico de red mínimo exacto para transferir los archivos y exactamente una escritura por archivo en el destino. Si tiene ciclos de CPU adicionales, agregar el indicador -z (para compresión) lo acelerará aún más, ya que se deben transferir menos datos de red.
Jeff McJunkin

@ user36845 - Verdadero. No estaba implicando una cronología con el pedido anterior, pero tienes razón, primero será necesario abrir el zócalo. Lo editaré para aclararlo. :)
SmallClanger

No estoy seguro de por qué ssh / scp tenían un límite de 125 MB / s a ​​133 MB / s, pero netcat puede canalizar esos datos a ~ 380 MB / s fácilmente (mismo enlace)
ThorSummoner

1

Un punto: no todos los hosts tienen rsync y es posible que los hosts tengan diferentes versiones de tar. Por esta razón, uno podría recomendar como primer puerto de escala el uso de cpio, que a menudo se descuida.

Puede cpio sobre ssh para hacer una replicación ad-hoc de estructuras de archivos / directorios entre hosts. De esta manera usted tiene un control más fino sobre lo que se envía, ya que necesita "alimentar" a cpio, nom-nom. También es más compatible con argumentos, cpio no cambia mucho: este es un punto importante si está cuidando múltiples hosts en un entorno heterogéneo.

Ejemplo de copia / exportación / inicio y subdirección a host remoto:

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

Lo anterior copiaría el contenido de / export / home y cualquier subdirección a / export / home en el host remoto.

Espero que esto ayude.


Mencionó que eran dos cajas CentOS, por lo que tendrían versiones de tar compatibles con rsync y archivos. Se crearon herramientas como rsync para reemplazar herramientas como cpio :). No puede "reanudar" con cpio, al menos sin saber exactamente desde dónde quiere comenzar y filtrar su búsqueda según corresponda. Lo cual es un tiempo innecesario sobrecarga. Habiendo dicho eso, información útil para los 'viejos' cuadros de UNIX :)
Rafiq Maniar

Sí, ese cmmand me perdió jaja
Andrew Fashion

1

Si tiene acceso ssh, tiene acceso 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/

Si recibe un error como "error rsync: algunos archivos no se pudieron transferir (código 23) en main.c (977) [remitente = 2.6.9]", verifique su usuario y grupos entre los servidores; Es posible que tenga una falta de coincidencia.

Use la opción rsync "-z" si desea que rsync comprima la transferencia. Esta opción usará más CPU pero menos ancho de banda, así que tenga en cuenta eso.

Hay una opción "--progress" que le dará un porcentaje transferido, lo cual es bastante bueno si le gusta ese tipo de cosas.


0

¿Están en una red compartida en lugar de necesitar internet para transferir archivos? NFS o FTP pueden ser mucho más rápidos que los gastos generales de SCP, aunque perderá el cifrado durante la transferencia.


diferentes servidores en ubicaciones remotas
Andrew Fashion

0

O siempre puedes usar tubos de alquitrán:

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

'j' = bzip2, puede usar 'z' para gzip o --lzma si su tar lo admite.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.