Cómo se mueven archivos grandes por la red sin sufrir

Publicado el 2026-09-12 por frfrand

Por qué copiar 200 GB con el método equivocado tarda el triple, qué hace rsync que scp no puede, y cómo diagnosticar si el cuello está en el disco, la red o la CPU.

Copiar un archivo de 200 MB no tiene ciencia. Copiar 200 GB, o cien mil archivos chicos, es otro problema: aparecen interrupciones, límites de disco y decisiones que cambian el tiempo total por un factor de tres.

La diferencia entre scp y rsync

scp copia. Punto. Si la conexión se corta al 90%, empezás de cero. Si el archivo ya está del otro lado, lo copia igual.

rsync compara antes de copiar. Mira qué hay en el destino y transfiere sólo lo que falta o cambió. Si se corta, retoma desde donde quedó.

rsync -avzP --partial origen/ servidor:/destino/

Las banderas, una por una:

• a (archive): preserva permisos, fechas y enlaces, y baja recursivamente.
• v (verbose): muestra qué está haciendo.
• z: comprime durante el envío.
• P: muestra progreso y habilita retomar archivos parciales.

Un detalle que muerde: la barra final del origen importa. Con "origen/" se copia el contenido de la carpeta; sin la barra, se copia la carpeta entera adentro del destino. Es la causa más frecuente de "me quedó una carpeta adentro de otra".

Cuándo comprimir y cuándo no

La bandera de compresión parece gratis y no lo es: consume CPU en los dos extremos.

• Conviene con texto, código, logs, volcados de base: comprimen muchísimo.
• No conviene con archivos ya comprimidos (vídeo, imágenes, zips): la CPU trabaja para no reducir nada, y si la red es rápida, la compresión pasa a ser el cuello de botella.

Regla práctica: red lenta y datos comprimibles, comprimí. Red rápida o datos ya comprimidos, no.

Muchos archivos chicos es otro problema

Transferir cien mil archivos de 10 KB es mucho más lento que un archivo de 1 GB, aunque el total sea parecido. Cada archivo implica metadatos, permisos y una ida y vuelta.

La solución es empaquetar en origen y desempaquetar en destino, en una sola tubería:

tar czf - carpeta/ | ssh servidor "tar xzf - -C /destino"

Eso arma el paquete al vuelo, lo manda por SSH y lo desarma del otro lado, sin escribir un archivo intermedio. Para árboles de muchos archivos chicos, la diferencia es enorme.

Dónde está realmente el cuello de botella

Antes de culpar a la red conviene mirar, porque en la mitad de los casos no es la red:

• El disco. Un disco mecánico ronda los 100 a 150 MB/s en lectura secuencial y mucho menos con archivos chicos. Si tu red da más que eso, el disco es el límite.
• La CPU. Con compresión activada y una red rápida, el procesador puede ser el freno. Se nota mirando el uso de CPU durante la transferencia.
• La red. Recién acá.

Un experimento que ordena la discusión: correr la transferencia sin compresión y comparar. Si va igual o más rápido, la compresión estaba estorbando.

Dos costumbres que evitan sufrimiento

Usá tmux. Cualquier transferencia de más de unos minutos debería correr dentro de una sesión de tmux. Si se corta tu conexión, el proceso sigue en el servidor y volvés a verlo.

Verificá al final. Comparar el tamaño no alcanza: una transferencia truncada puede coincidir. Comparar el hash sí.

sha256sum archivo.tar.gz # en los dos lados

Para volcados de base de datos y cualquier cosa que vayas a necesitar en serio, ese paso vale los treinta segundos que cuesta.