Cómo mover 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 pequeños, 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%, empiezas 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 solo 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 dentro del destino. Es la causa más frecuente de "me quedó una carpeta dentro 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 de datos: 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, comprime. Red rápida o datos ya comprimidos, no.

Muchos archivos pequeños 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 envía por SSH y lo desarma del otro lado, sin escribir un archivo intermedio. Para árboles de muchos archivos pequeños, 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 pequeños. 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 aquí.

Un experimento que ordena la discusión: ejecutar 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 ejecutarse dentro de una sesión de tmux. Si se corta tu conexión, el proceso sigue en el servidor y podrás volver a verlo.

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

Ejemplo: trasladar un backup sin interrumpir la aplicación

Cuando movés archivos grandes entre servidores, conviene medir velocidad sostenida, reintentos y verificación de integridad. rsync puede reanudar transferencias útiles y sha256sum permite comparar archivos terminados. Para una base de datos activa, copiar archivos internos del motor sin un procedimiento coherente no sustituye un backup consistente.

Si administrás VPS con ArduMaker, diferenciá la transferencia de archivos de la migración de una aplicación: además del directorio compartido quizá debas mover la base, credenciales, servicios, dominios y certificados. Planificá una ventana de corte o sincronización final, y probá que el nuevo entorno arranca antes de cambiar DNS.

Relacionado: Qué es un backup · Documentación.