¿La forma más fácil de transferir archivos rápidamente entre servidores Linux?

16

Necesito transferir archivos de un servidor CentOS a otro. Transferirá archivos de 5 MB aproximadamente cada 10 minutos. No necesita encriptación.

¿Qué es fácil para la transferencia rápida de archivos?

¿Hay algo más simple que ftp?

¡Gracias!

linux file-transfer Alex L
fuente
1
Tengo fe en que el alquitrán sobre netcat triunfará ... je je ...: serverfault.com/questions/18125/…
Evan Anderson
Como no necesito cifrado pero sí velocidad, prefiero rsync.
Alex L
Acabo de enterarme de que las transferencias http no tienen mucha sobrecarga, por lo que tal vez podría usar eso.
Alex L
No edite una respuesta en su pregunta, publíquela como respuesta. Retrotraído.
HopelessN00b
para "rápido" ver también unix.stackexchange.com/questions/48399/…
rogerdpack

Respuestas:

25

rsync

Usaría rsync antes de usar ftp o tftp.

Más opciones y (en mi experiencia) una transferencia más confiable.

KPWINC
fuente
1
También descubrí que rsync generalmente obtiene un rendimiento más alto que cualquier otra cosa (scp, cifs, nfs)
Ophidian
¿Qué pasa con las transferencias http?
Alex L
@ Ofidian ¿Te refieres a usar rsync como demonio? De lo contrario, ¿cómo puede ser más rápido que scp, ya que ambos usan ssh y hay cifrado?
balki
@balki Sí, el demonio rsync. No es particularmente hablador, hace un buen trabajo al alimentar los datos del disco a la línea, y realiza el trabajo tan pequeño como sea necesario para completar la solicitud (por ejemplo, se aplican diferencias para los archivos de texto).
Ophidian
21

tar over ssh está bien, ¡pero tar over TCP a través de netcat es tan bajo como puede obtener! Si esto es una cosa de una sola vez, intente esto:

En el receptor:

nc -l -p 8989 | tar x

En el remitente:

tar cf - /source-path | nc (receiving host ip address) 8989

Si esto es algo que vas a hacer regularmente, probablemente usaría rsync.

Evan Anderson
fuente
+1 para netcat, la navaja suiza
chmeee
Lo mismo para ti por no leer a Evan. ¡Jajaja! En realidad no es una cosa de una sola vez. Dijo que va a transferir archivos de 5 MB aproximadamente cada 10 minutos. ¿Quizás enviar por código Morse sería una buena alternativa? ;-) (nota: broma privada entre Evan y yo)
KPWINC
8

Dos personas han mencionado alquitrán sobre ssh, pero no dijeron cómo hacerlo. Para el registro, el procedimiento básico es ejecutar:

tar cf - files... | ssh remotehost 'cd /destination && tar xvf -'

O, si desea iniciar transferencias desde el extremo receptor:

ssh remotehost 'cd /source && tar cf - files' | tar xvf -

La ventaja de hacerlo de esta manera sobre la solución netcat de Evan es que todo se puede iniciar desde una computadora; no tiene que coordinar dos invocaciones de netcat. Si necesita que esto se ejecute automáticamente, puede configurar una clave ssh que le permita hacer conexiones sin una frase de contraseña, y usar esa clave para estas conexiones.

ssh tiene una opción -C para comprimir su flujo de datos, o puede usar la capacidad de compresión incorporada de GNU tar:

tar zcf - files... | ssh remotehost 'cd /destination && tar xzvf -'

Rsync es otra opción, pero su fuerte es la actualización de archivos que ya existen en el extremo receptor. He encontrado que es más lento que scp o tar / ssh cuando lo uso para transferir archivos que aún no existen en el otro extremo.

Kenster
fuente
1
+1 ¿Qué, quieres decir que no todo el mundo sabe intuitivamente cómo hacer tar sobre ssh? Extraño. :)
caos
El alquitrán, por sí solo, no es confiable: no hay verificación de integridad, sin embargo, con SSH (TLS) se obtiene integridad debido a la capacidad de TLS de detectar cambios en los datos en vuelo. Rsync es una mejor opción y Rsync ya que hará una mejor verificación de integridad sin cifrado; El OP declaró que el cifrado no era necesario.
Kilo el
¿Qué comprobación de integridad necesita el alquitrán? Las capas TCP y ssh proporcionan un transporte de datos confiable. Si está afirmando que el propio alquitrán puede tener errores, debe tratar a rsync de la misma manera. De hecho, las transferencias de rsync se congelaron debido a problemas de protocolo. No recuerdo una tubería tar / untar que haya hecho eso.
Kenster
6

Lo usaría scpo tarmás ssh, honestamente. El cifrado ralentiza las cosas, pero la facilidad de configuración y uso, la confiabilidad y (subjetivamente, por supuesto) la familiaridad me hacen estar dispuesto a recibir el golpe, a menos que realmente necesite esa velocidad.

Puede acelerar la transferencia ssh diciéndole que use un cifrado más rápido que el predeterminado, también. El valor predeterminado generalmente es 3desy usted puede hacerlo -c des, por lo que obviamente será más rápido y también -c blowfishse representa como rápido, aunque no lo he probado con exactitud.

(En los días de SSHv1, a menudo se podía hacer -c none, pero supongo que alguien decidió que era un mal juju).

caos
fuente
4

Si tiene que pasar por scp / ssh, mis experimentos muestran que el cifrado más rápido habilitado por defecto en estos días es RC4. Usted especifica el cifrado a través de ' -c arcfour ' en su comando ssh / scp:

para copia inicial:

  • scp -c arcfour -r foo/ desthost:/destdir

para actualizaciones:

  • rsync -e 'ssh -c arcfour' -r foo/ desthost:/destdir
alaryin
fuente
3

Rsync es un buen camino a seguir porque si te encuentras transfiriendo los mismos archivos más de una vez, acelerará la copia, como se muestra con esta cita de la página del manual. 

   rsync is a program that behaves in much the same way that rcp does, but
   has many more options and uses  the  rsync  remote-update  protocol  to
   greatly  speed  up  file  transfers  when the destination file is being
   updated.
   The rsync remote-update protocol allows rsync to transfer just the dif-
   ferences between two sets of files across the network connection, using
   an efficient  checksum-search  algorithm  described  in  the  technical
   report that accompanies this package.
thepocketwade
fuente
2

FTP es bastante simple, pero una forma aún más simple puede ser crear un recurso compartido NFS en una máquina y montarlo en la otra. Luego, copiar los archivos consistirá en hacer un cp de un directorio a otro.

Swoogan
fuente
Dependiendo de los requisitos. No usaría NFS en Internet, por ejemplo.
Kyle Hodgson
1
Buen punto. En ese caso, recomendaría rsync ya que puede reanudarse donde se dejó si se interrumpe. También porque solo transfiere el delta entre el origen y el destino.
Swoogan
la pregunta era muy general, me gusta la soulution publicada por Swoogan, especialmente que el autor mencionó que necesita la solución más simple y no requiere cifrado
integratorIT
2

Si quieres velocidad, puedes usar netcat y tar. Será más rápido que ssh, rsync o scp en una red local donde el cifrado no es una preocupación. Google "netcat tar".

DestinationServer

nc -l -p 7878 | tar -C /target/dir -xzf -

SourceServer

tar -cz /source/dir | nc DestinationServer 7878

Obviamente, esto requiere que netcat esté realmente instalado. Google "netcat tar" para más información.

robertmoggach
fuente
1

Creo que ya resolvió su problema, pero en caso de que su ssh funcione en otro puerto (no en el puerto estándar 22), puede usar esto

rsync -avz --rsh = 'ssh -pXXXXX' / local / dir / [email protected]: / remote / dir

Nota: - reemplace XXXXX con su número de puerto - reemplace 192.16.1.2 con la IP correcta del servidor remoto

mangia
fuente