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.

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"

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

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

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.

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.

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.

¿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.

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.