Cómo acelerar la transferencia de archivos en Linux

Si usas Linux a diario es muy probable que alguna vez te hayas quedado mirando una barra de progreso eternamente lenta al copiar archivos grandes, ya sea a un disco USB, a otro servidor por red o entre discos internos. Mientras tanto, en el mismo hardware, entras en Windows y todo vuela a 60-80 MB/s. La sensación es frustrante y da la impresión de que Linux “es lento” moviendo datos.

La realidad es bastante más matizada: el sistema funciona de otra manera, el kernel usa cachés de escritura agresivas, hay parámetros por defecto conservadores, y además influyen el tipo de sistema de archivos, la forma de copiar y hasta el cifrado de la conexión. Entender qué está pasando “por debajo del capó” te permite ajustar el sistema y acercarte mucho a ese rendimiento que ves en otros sistemas.

Por qué las copias de archivos en Linux parecen tan lentas

Una de las quejas más habituales es la enorme diferencia entre la velocidad percibida en Linux y en Windows al copiar muchos gigas (o teras) a un disco USB externo. Hay usuarios que reportan casos reales: en Windows el mismo disco externo logra 60-80 MB/s estables, mientras que en Linux la copia empieza fuerte y al poco cae a 2-10 MB/s, haciendo que pasar varios terabytes sea cuestión de días, no de horas.

En otros escenarios, por ejemplo al transferir una colección de vídeos de 1 a 3 GB entre dos servidores Linux, se ven cifras de unos 20 MB/s con rsync frente a 100 MB/s usando Samba desde una máquina Windows como intermediaria. De entrada parece contraintuitivo: rsync es eficiente, viaja por SSH, y en teoría debería ser la opción más rápida.

Todo esto genera la sensación de que hay un “bug” eterno en el kernel que hace imposible usar Linux para copias grandes. En realidad, detrás de estas situaciones hay una combinación de factores: caché de escritura, parámetros del subsistema de memoria, características de USB, tipo de sistema de archivos y herramientas usadas. Ajustando cada pieza podemos mejorar mucho el rendimiento.

Además, es clave entender que en Linux la velocidad que muestra el diálogo de copia o la barra de progreso no siempre refleja lo que está pasando en el disco. Primero se copia a RAM, luego se vacía en ráfagas al dispositivo, y eso provoca picos, pausas y esa molesta sensación de “se ha quedado colgado”.

La caché de escritura del kernel: el verdadero culpable aparente

Linux confía mucho en la memoria RAM para amortiguar operaciones de disco. Cuando copias datos a una unidad lenta, como un disco duro USB o una memoria flash, el sistema no escribe inmediatamente todo en el dispositivo. Primero lo guarda en la caché (memoria sucia) y, cuando se cumplen ciertas condiciones, comienza a volcar esos datos en segundo plano.

Esto provoca un efecto engañoso: la copia empieza a toda velocidad, la barra sube muy rápido y de repente la interfaz gráfica parece quedarse congelada durante minutos. En realidad, la caché se llenó y ahora el kernel está vaciando a tirones esa memoria hacia el dispositivo USB, intentando a la vez que el equipo siga siendo usable para otras tareas.

Si usas un monitor de discos (por ejemplo los widgets de KDE Plasma) verás claramente este comportamiento: picos de escritura muy altos seguidos de espacios “vacíos” en los que apenas se escribe nada. Esos huecos entre ráfagas son precisamente los que se traducen en largos tiempos de espera y sensación de lentitud total.

Además, esto se relaciona con otro clásico: cuando terminas la copia y quieres “extraer con seguridad” la unidad USB, el sistema te dice que esperes, porque aún se están escribiendo datos. No es un error: significa que parte del contenido sigue en la caché y todavía no ha llegado físicamente al dispositivo. Si desconectases en ese momento, te arriesgarías a corromper archivos.

Una de las claves para acelerar las transferencias es reducir esos huecos inútiles entre ráfagas de escritura y hacer que el kernel vacíe la caché antes de que se llene hasta arriba, de forma más continua y predecible. Ahí entran en juego varios parámetros del subsistema de memoria virtual.

Ajustar vm.dirty_* y otros parámetros para unidades USB lentas

Cuando copias a una memoria USB, especialmente si está formateada en NTFS o FAT, entrar en el detalle de ciertos valores del kernel y saber cómo activar la caché de escritura en discos externos puede marcar una diferencia notable. Existen dos parámetros muy importantes: vm.dirty_bytes y vm.dirty_background_bytes, que definen cuánto puede crecer la caché de escritura antes de que el sistema empiece a vaciarla al disco.

Mediante comandos como:

echo $((120*1024*1024)) > /proc/sys/vm/dirty_bytes
echo $((60*1024*1024)) > /proc/sys/vm/dirty_background_bytes

le estamos indicando al kernel que, cuando los datos pendientes de escribir alcancen esos tamaños (por ejemplo, 120 MB y 60 MB), no espere a saturar la memoria y comience a transferirlos antes. De esta forma se reducen los huecos entre ráfagas que se veían en el monitor de discos y la transferencia se vuelve más fluida.

Este ajuste se nota especialmente en memorias USB con NTFS, aunque no es una bala de plata: el límite físico del dispositivo sigue mandando. Lo que sí se consigue es evitar esos ciclos de arranque a toda pastilla y frenazo completo que empeoran la experiencia y deforman las estadísticas de velocidad.

Para unidades con sistemas de archivos nativos de Linux como EXT4, se puede ir un paso más allá y tocar los tiempos de activación de los procesos de escritura, definidos por vm.dirty_writeback_centisecs y vm.dirty_expire_centisecs. Por defecto suelen tener valores pensados para no castigar al sistema, pero pueden ajustarse.

Por ejemplo:

sysctl -w vm.dirty_writeback_centisecs=30
sysctl -w vm.dirty_expire_centisecs=500

Con esto se reduce la periodicidad con la que el kernel se pone a trabajar en serio vaciando la caché sucia a disco, estrechando aún más la separación entre ráfagas de escritura. Traducido a la práctica, la gráfica de I/O se ve más “rellena” y menos a tirones, y las copias grandes se completan en menos tiempo.

Si quieres que estos cambios sean permanentes y no se pierdan al reiniciar, puedes añadir al archivo /etc/sysctl.conf entradas como:

vm.dirty_bytes=125829120
vm.dirty_background_bytes=62914560
vm.dirty_writeback_centisecs=30
vm.dirty_expire_centisecs=500

De esta forma tu sistema arrancará siempre con estos parámetros más agresivos para escritura, lo que en máquinas que copian datos a menudo a USB o discos lentos se traduce en una experiencia mucho menos desesperante.

Impacto de las mejoras del kernel en operaciones de E/S

La comunidad del kernel lleva años puliendo el subsistema de E/S para que, incluso en escenarios extremos (copias masivas a discos lentos, sistemas con poca RAM, etc.), no se bloquee todo el escritorio ni se queden congeladas aplicaciones como el navegador. En versiones recientes del kernel se han introducido mecanismos precisamente para evitar que los procesos de escritura acaparen demasiada memoria y CPU.

Entre otras cosas, se ha trabajado en limitar el número de páginas de memoria que pueden quedar en estado “sucio” a la vez y en cómo se prioriza el vaciado de esa memoria hacia el disco. Esto se nota sobre todo cuando estás copiando a un dispositivo formateado en FAT32 o NTFS y, al mismo tiempo, quieres seguir utilizando el sistema sin tirones.

En kernels anteriores era frecuente que, al mover varios gigas a una memoria USB barata, el entorno gráfico quedase prácticamente congelado durante largos segundos. Con las nuevas versiones y una configuración razonable de los parámetros de memoria, ese efecto se reduce mucho, haciendo que el proceso de copia sea menos invasivo.

Además, en el ecosistema Linux aparecen continuamente herramientas y utilidades para analizar el rendimiento de memoria caché, CPU y subsistemas de disco, como perf c2c, que permite ver patrones de uso de cachés en procesadores modernos y detectar cuellos de botella. Aunque estas herramientas están más orientadas a desarrolladores y administradores avanzados, ayudan a afinar aún más la experiencia en entornos de alto rendimiento.

Todo este trabajo se complementa con las optimizaciones específicas para plataformas como ARM y con el soporte cada vez mejor de hardware diverso. En definitiva, aunque siga habiendo margen de mejora, la situación del rendimiento de E/S en Linux dista mucho de ser un simple “bug sin arreglar”. Más bien es un equilibrio entre rendimiento bruto, estabilidad y capacidad de respuesta del sistema.

Estrategias prácticas para acelerar copias muy grandes

Más allá de tocar parámetros de kernel, hay varios trucos prácticos que cualquier usuario puede aplicar para reducir drásticamente el tiempo de transferencia de grandes cantidades de datos, tanto en copias locales como a través de la red.

Uno de los más eficaces, sobre todo cuando se trata de miles de archivos medianos o grandes, es comprimir primero los datos en origen y luego trasladar un único archivo grande a la unidad lenta. Por ejemplo, si quieres hacer copia de seguridad de tu biblioteca multimedia (Plex, fotos, vídeos, etc.), puedes crear un archivo tar comprimido:

tar -czf backup-plex.tar.gz /ruta/a/tu/mediateca

y una vez creado, copiar ese tar.gz al disco USB o al servidor remoto. Un usuario que se encontraba con una copia eternamente lenta hacia un HDD USB descubrió que, al seguir este enfoque (comprimir, mover y descomprimir en destino), el ahorro de tiempo era brutal frente a rsync moviendo directorios uno a uno.

Esto funciona especialmente bien si tu disco de origen es rápido (por ejemplo un NVMe interno) y el cuello de botella está en el disco de destino o en la red. Comprimir en el disco rápido suele ir mucho más deprisa que escribir sin parar en el lento, así que trasladar un único archivo grande reduce el overhead de miles de aperturas/cierres de ficheros y mejora sustancialmente el throughput efectivo.

En el terreno de las transferencias por red entre máquinas Linux, también puedes ganar mucho jugando con la compresión “al vuelo” de herramientas como scp o rsync, optando por transferir archivos con Snapdrop, o incluso cambiando el algoritmo de cifrado de SSH a uno más ligero cuando la CPU sea el factor limitante y no la red.

Copiar por red con SCP: sintaxis y opciones clave

Cuando tienes que mover datos entre servidores (o entre tu PC y un servidor), el comando scp es una de las formas más sencillas y habituales. SCP se apoya en SSH para establecer una conexión cifrada punto a punto, de modo que los archivos viajan protegidos sin necesidad de montar servicios adicionales como FTP.

La sintaxis básica es muy parecida al comando cp de Unix, solo que añades el usuario y host de destino. Por ejemplo, para subir un archivo local a un servidor remoto:

scp archivo-local.tar usuario@servidor:/ruta/de/destino/

Este comando copiará archivo-local.tar a la ruta indicada en el host remoto, pidiéndote la contraseña del usuario (o usando tu clave SSH si la tienes configurada). Para hacer el camino contrario, traer un archivo del servidor a tu máquina:

scp usuario@servidor:/ruta/remota/archivo.tgz archivo-en-local.tgz

En este caso se descargará archivo.tgz desde el servidor y se guardará como archivo-en-local.tgz en tu máquina. Si quieres copiar directorios completos con todo su contenido, debes incluir la opción recursiva:

scp -r carpeta/ usuario@servidor:/ruta/destino/

Esta sintaxis sencilla es uno de los motivos por los que muchos administradores prefieren SCP frente a alternativas más complejas cuando solo necesitan mover datos sin complicaciones adicionales. Además, al ir sobre SSH, no tienes que levantar servicios extra ni exponer nuevos puertos a Internet.

Hacer las transferencias de red más rápidas con SCP (-C, -c, -l, -P…)

El comando scp ofrece una serie de opciones que, bien usadas, pueden mejorar mucho tanto el rendimiento como el control sobre el ancho de banda y la seguridad de la conexión. Las más interesantes en el contexto de acelerar transferencias son las siguientes.

La opción -C activa la compresión de datos sobre la marcha. En enlaces relativamente lentos (por ejemplo, una conexión remota de pocos Mbps), comprimir los datos antes de enviarlos puede suponer una diferencia de orden de magnitud. Hay casos medidos con un archivo de unos 93 MB donde el tiempo de copia sin compresión rondaba los 1661 segundos, mientras que con -C bajaba a unos 162 segundos, unas diez veces más rápido.

Eso sí, la compresión solo ayuda si los datos no están ya comprimidos. Archivos ZIP, RAR, ISOs, imágenes JPEG, etc. apenas mejoran con -C e incluso pueden empeorar ligeramente por el trabajo extra de CPU. Para conjuntos grandes de texto, bases de datos sin comprimir, logs o binarios, puede ser una herramienta excelente.

La opción -c permite elegir el algoritmo de cifrado de SSH que se usará durante la transferencia. Por defecto suele ser AES-128, que ofrece un buen equilibrio entre seguridad y rendimiento. No obstante, si por motivos de compatibilidad quieres usar algo distinto, podrías indicar, por ejemplo:

scp -c 3des archivo usuario@servidor:/ruta/

Debes tener cuidado de no confundir -c (cipher) con -C (compression), ya que hacen cosas totalmente distintas. Cambiar de cifrado rara vez acelera dramáticamente en máquinas modernas, pero en hardware antiguo o muy limitado en CPU sí puede tener impacto.

Para no saturar la red cuando haces copias muy grandes, tienes -l, que limita el ancho de banda usado por scp en kilobits por segundo. Por ejemplo:

scp -l 400 archivo usuario@servidor:/ruta/

establece un máximo teórico de unos 50 KB/s (recuerda que 8 bits = 1 byte). Esto es útil cuando automatizas copias nocturnas o tienes otros servicios que no quieres que se queden sin ancho de banda mientras lanzas un backup enorme.

Cuando el servidor SSH escucha en un puerto no estándar, puedes indicarlo con -P (mayúscula, porque -p minúscula ya se usa para otra cosa). Por ejemplo, si el servicio está en el puerto 2249:

scp -P 2249 archivo usuario@servidor:/ruta/

Por último, hay otras opciones útiles como -p para preservar tiempos de modificación y permisos, -v para ver información de depuración (velocidad estimada, mensajes de debug de SSH, etc.) o -q para ocultar el medidor de progreso y mensajes no críticos, algo útil en scripts donde no quieres ruido en la salida.

Copias seguras a través de proxy y configuraciones avanzadas de SSH

En muchas empresas el acceso a servidores remotos pasa por un proxy HTTP o similar. De forma nativa, scp no “habla” con el proxy por sí mismo, pero se puede configurar el cliente SSH para que use herramientas como corkscrew y así tunelizar la conexión.

El flujo típico sería crear un archivo ~/.ssh/config con las directivas necesarias para que SSH se conecte al proxy (por ejemplo, en 10.0.96.6:8080) y autenticar pasando por un archivo ~/.ssh/proxyauth que contenga usuario y contraseña en texto plano. Después, las llamadas a scp funcionan de forma transparente, como si el proxy no existiera, siempre que el binario corkscrew esté instalado.

En entornos donde alternas con frecuencia entre la red corporativa (con proxy) y redes públicas sin restricciones, es incómodo editar continuamente la configuración. Aquí viene bien la opción -F de scp, que permite usar un archivo de configuración SSH alternativo:

scp -F ~/.ssh/config-empresa archivo usuario@servidor:/ruta/

De este modo, puedes tener distintos ficheros de configuración según el entorno, manteniendo la misma sintaxis de scp y sin volverte loco cambiando parámetros una y otra vez.

Elegir entre SCP y SFTP según lo que necesites

Tanto SCP como SFTP usan el mismo pilar: el protocolo SSH para cifrar y autenticar. Sin embargo, no se comportan igual ni están pensados exactamente para lo mismo, y conviene tenerlo claro para escoger la herramienta adecuada en cada caso.

SCP brilla por su simplicidad: la sintaxis es casi idéntica a cp, está pensado pura y duramente para copiar archivos de un lado a otro y no se mete en más historias. Es ligero y muy eficiente en grandes transferencias secuenciales, con poco overhead y sin capas extra de protocolo.

SFTP, en cambio, es un subsistema mucho más completo. Permite navegar por directorios, listar contenidos, cambiar permisos, borrar archivos, etc., con una experiencia similar a FTP pero con la seguridad de SSH. Muchas herramientas gráficas (como clientes “tipo FTP”) se apoyan en SFTP para dar una interfaz familiar a usuarios menos técnicos.

El coste de esa funcionalidad extra es que SFTP tiende a consumir más recursos y puede ser ligeramente más lento que SCP en grandes transferencias lineales, especialmente cuando se trabaja con muchos archivos pequeños. Aun así, para un uso interactivo o cuando quieres un “explorador remoto”, SFTP suele ser la opción más cómoda.

Como regla general: si lo que necesitas es simplemente volcar grandes ficheros de forma segura y rápida, SCP suele ser la mejor apuesta. Si en cambio quieres gestionar la estructura de directorios remota, cambiar permisos o prefieres una interfaz tipo FTP, SFTP encaja mejor.

Publicar una web o mover proyectos con SCP

El uso de scp no se limita a copias esporádicas de un par de archivos. Muchos desarrolladores lo utilizan a diario para desplegar sitios web, subir versiones de aplicaciones o sincronizar proyectos entre su equipo local y un servidor VPS o dedicado.

Imagina que tienes tu sitio web estático preparado en /home/usuario/mi-web/ y un servidor al que accedes como root en la IP 123.45.67.89. Para subir todo el contenido al directorio donde Apache o Nginx sirven la web (/var/www/html/ en muchos casos), podrías ejecutar:

scp -r /home/usuario/mi-web/* root@123.45.67.89:/var/www/html/

El indicador -r hace que se copien todos los subdirectorios y archivos, respetando la estructura. Si usas autenticación por clave privada en lugar de contraseña, puedes añadir -i para especificar la ruta de la clave:

scp -i /ruta/a/tu_clave.pem -r /home/usuario/mi-web/* root@123.45.67.89:/var/www/html/

Tras la transferencia, basta con entrar por SSH al servidor, revisar que los ficheros están donde deben con algo como:

ssh root@123.45.67.89
ls -l /var/www/html/

y comprobar que el servidor web tiene permisos para leerlos. Con el dominio apuntando a la IP del VPS vía DNS, tu sitio quedará publicado en cuestión de segundos. Esta combinación de SSH + SCP da un control muy fino sobre el servidor y evita depender de paneles o clientes FTP poco flexibles.

Alternativas gráficas en Windows: WinSCP y pscp

Si trabajas desde Windows pero tus servidores son Linux, tampoco estás atado a la línea de comandos. Herramientas como WinSCP ofrecen una interfaz gráfica cómoda para transferir archivos mediante SCP o SFTP, con paneles tipo explorador de ficheros que facilitan el arrastrar y soltar.

Por otro lado, el conocido cliente SSH PuTTY incluye pscp, una utilidad de consola muy parecida a scp que puedes usar en scripts o desde el símbolo del sistema de Windows. La sintaxis es similar, de modo que resulta sencillo trasladar tus comandos habituales de Linux a ese entorno.

En ambos casos, el principio es el mismo: aprovechar el cifrado de SSH para mover datos con seguridad, ya estés en Linux, macOS o Windows, y sin tener que habilitar servicios menos seguros como FTP clásico.

En conjunto, entender cómo funciona la caché de escritura del kernel, ajustar unos pocos parámetros de vm.dirty_*, elegir bien la herramienta de copia (scp, rsync, SFTP, compresión previa) y, cuando haga falta, apoyarte en soluciones gráficas como WinSCP, te permite pasar de copias eternas y aparentemente bloqueadas a un flujo de trabajo mucho más fluido, predecible y cercano al rendimiento máximo real de tu hardware y tu red.