71 votos

Forma más rápida de transferir 55GB de imágenes al servidor nuevo

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

Es que la forma más rápida que acabo de sugerir, porque tarring es tomar siempre... me encontré con el comando:

el alquitrán.cvf imagesbackup.tar imágenes

y yo solo iba a scp, hágamelo saber si hay una forma más rápida, gracias!

He remoto/SSH acceso a ambos equipos.

105voto

tylerl Puntos 8195

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

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

Cualquier cadena que sigue a su "ssh" comando será ejecutado en el servidor remoto lugar de la de inicio de sesión interactivo. Usted puede tubería de entrada/salida y de los comandos del control remoto a través de SSH como si fueran locales. Poner el comando entre comillas evita cualquier confusión, especialmente cuando se utiliza la redirección.

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

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

Nota: el que usa con menos frecuencia -C opción. Significa "cambiar a este directorio primero antes de hacer nada."

O, tal vez usted quiere "tirar" desde el servidor de destino:

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

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

Yo podría fácilmente haber escrito el anterior como sigue:

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

O de la siguiente manera:

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

O, usted puede ahorrar algo de dolor y sólo tiene que utilizar rsync:

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

Por último, recuerde que comprime los datos antes de transferir va a reducir su ancho de banda, pero en una conexión muy rápida, puede hacer que la operación de tomar más tiempo. Esto es debido a que el equipo puede no ser capaz de comprimir lo suficientemente rápido como para mantener: si la compresión de 100 MB tarda más de lo que se necesitaría para enviar 100MB, entonces es más rápido enviar sin comprimir.

Alternativamente, usted puede desear considerar las tuberías de gzip sí mismo (en lugar de utilizar la opción-z), de modo que usted puede especificar un nivel de compresión. Ha sido mi experiencia que rápido en conexiones de red con datos comprimible, con gzip en el nivel 2 o 3 (el valor predeterminado es 6) da el mejor rendimiento general en la mayoría de los casos. Así:

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

69voto

Some French Guy Puntos 96

Estaría tentado a rsync que por encima de mí - se hace la compresión y controla la pérdida de enlaces.

12voto

pacey Puntos 2507

Si usted acaba de alquitrán de ellos y nada más que esto será un desperdicio de toneladas de tiempo con sólo una mínima ganancia de velocidad.

Así que simplemente taring de seguridad de los archivos con el cvf interruptores efectivamente el costo del tiempo que se tarda en leer todos los 55GB imágenes y volver a grabarlos en el disco. (Efectivamente va a ser aún más pérdida de tiempo, ya que habrá una considerable sobrecarga).

Sólo hay una ventaja ganancia de aquí, la carga para cargar muchos archivos se reduce. Usted puede obtener una transferencia más rápida de veces si se comprimen las imágenes (pero ya creo que ellos ya están en un formato comprimido esto no va a ser de mucha ayuda). Más pérdida de tiempo de computación.

La mayor desventaja de la transferencia de un enorme archivo tar sobre el alambre es que si algo va mal podría significar que usted tiene que empezar de nuevo.

Me gustaría utilizar esa manera:

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

En el nuevo servidor

md5sum /images/* > md5sum_new.txt

Y, a continuación, sólo diff. Y desde scp soporta compresión sobre la marcha no es necesario para los archivos separados.

Editar

Voy a mantener el MD5 de la información, ya que fue útil para el OP. Pero uno de los comentarios, me golpeó con una visión nueva. Así que un poco de búsqueda proporcionado esta pieza de información útil. Por favor, tenga en cuenta que el tema aquí es SFTP no directamente SCP.

En contraste con FTP, SFTP, se agrega una sobrecarga para la transferencia de archivos. Como se transfiere un archivo entre el cliente y el servidor, éste se rompe en pequeños trozos llamados "paquetes." Por ejemplo, supongamos que cada paquete es de 32 kb. El protocolo SFTP hace una suma de comprobación en cada uno de los 32 KB archivo, ya que se envía, y que incluye la suma de comprobación junto con el paquete. El receptor recibe ese paquete y descifra los datos y, a continuación, comprueba el checksum. La suma de comprobación en sí es "más fuerte" que la suma de comprobación CRC32. (Porque SFTP utiliza un cifrado de 128 bits o más de la suma de comprobación, tales como MD5 o SHA, y debido a que se realiza en cada uno de los paquetes, hay una muy granular de comprobación de integridad que se lleva a cabo como parte de la transferencia.) Así pues, el protocolo en sí es más lento (debido a la sobrecarga adicional), pero la finalización con éxito de una transferencia significa, de facto, que se ha transferido de forma integral y no hay necesidad de una comprobación adicional.

8voto

SmallClanger Puntos 6536

En la parte superior de Pacey del md5sum sugerencia, yo uso el siguiente:

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

A continuación, en el origen: tar -cvf - /path/to/source/ | nc -w5 destinationserver 4567

Es todavía una tar/untar, y no hay cifrado, pero es directo para el otro servidor. Iniciar ambos en tándem (-w5 le da 5 segundos' la gracia). y ver que se vaya. Si el ancho de banda es escaso, complemento de la z a la tar en ambos extremos.

2voto

Rowley Puntos 64

Un punto - no todos los hosts tienen rsync y puede hosts puede tener diferentes versiones de tar. Por esta razón, se podría recomendar como primer puerto de llamada con la que a menudo se descuida cpio.

Usted puede cpio a través de ssh para hacer ad-hoc de replicación de archivo/directorio de estructuras entre los hosts. De esta manera usted tiene más control sobre lo que se envía a través de ver como usted necesita para "alimentar" cpio, nom-nom. También es más argumento-portátil, cpio no cambia mucho - este es un punto importante si usted está buscando después de varios hosts en un entorno heterogéneo.

Ejemplo copiar /export/home y subdirectorios host remoto:

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

El de arriba se copia el contenido de /export/home y cualquier subdirectorio de /export/home en el host remoto.

Espero que esto ayude.

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by: