Cómo transferir archivos gigantes entre dos servidores usando rsync por SSH de forma rápida y segura

El comando rsync a través de SSH es una de las formas más prácticas en Linux para transferir archivos grandes entre dos servidores de manera rápida, segura y resistente a interrupciones. Especialmente al mover cientos de GB de archivos de sitios web, respaldos, carpetas multimedia o datos de aplicaciones, rsync ofrece una ventaja significativa frente a los métodos clásicos de copia al transferir solo los bloques modificados. La lógica básica es la siguiente: los archivos en el servidor origen se sincronizan cifrados vía un túnel SSH hacia el servidor destino; si se pierde la conexión, la transferencia puede continuar desde donde se interrumpió.

En procesos como migración de servidores, actualización de hosting, cambio de centro de datos o tareas de respaldo, no solo la velocidad sino también la integridad de los datos es fundamental. Descargar un archivo enorme en una sola pieza para luego subirlo de nuevo consume tiempo y puede obligarte a empezar desde cero ante cualquier fallo de conexión. Aquí es donde rsync destaca al preservar marcas de tiempo, permisos, propiedad y estructura de carpetas. Por eso, administradores Linux, equipos DevOps y expertos en hosting lo usan habitualmente en sus operaciones diarias.

En esta guía abordaremos paso a paso cómo transferir archivos gigantes entre dos servidores Linux mediante rsync sobre SSH, con ejemplos de comandos reales. También cubriremos parámetros para mejorar el rendimiento, controles de seguridad, manejo de errores, pruebas previas y puntos clave antes de pasar a producción. Si planeas migrar a un VPS o nuevo entorno de hosting, asegúrate antes de disponer suficiente espacio en disco, acceso SSH y permisos adecuados en ambos servidores. Para elegir la infraestructura adecuada, puedes consultar las páginas de Soluciones de servidor VPS Hostragons y Paquetes de Hosting Linux.

¿Qué es rsync y por qué es ideal para mover archivos grandes?

rsync es una potente herramienta de línea de comandos para sincronizar archivos y directorios localmente o entre servidores remotos. Su característica más destacada es el algoritmo delta, que evita reenviar todo el archivo cada vez, transfiriendo solo los cambios. Por ejemplo, si un respaldo de 80 GB tiene solo 2 GB modificados, rsync enviará únicamente esos bloques actualizados en lugar de todo el archivo.

SSH aporta cifrado a la transferencia, por lo que rsync no envía los datos en texto plano por la red. Esto es crucial para proteger datos de clientes, registros de pedidos de comercio electrónico, archivos multimedia, copias de base de datos y archivos de aplicaciones privadas. La seguridad en hosting no se limita al certificado SSL para el tráfico web; la transferencia entre servidores también debe cifrarse usando SSH. Mientras para el tráfico web se emplea certificado SSL, para la transferencia de archivos entre servidores se recomienda cifrado SSH.

rsync es más flexible que FTP o descargas manuales: puede preservar permisos, manejar enlaces simbólicos, borrar archivos eliminados en origen, limitar ancho de banda y permitir pruebas previas. En operaciones críticas como mover archivos grandes, este nivel de control es una gran ventaja.

¿Cuándo usar rsync por SSH?

El comando rsync sobre SSH es ideal para mover archivos voluminosos, numerosos o que cambian frecuentemente. Para carpetas de imágenes pequeñas puede bastar un SFTP manual, pero cuando hay miles de archivos, permisos variados o grandes archivos comprimidos, rsync se vuelve mucho más confiable.

• Si trasladas un sitio web de un servidor antiguo a un VPS nuevo.
• Cuando migras carpetas con miles de archivos multimedia, como la carpeta uploads de WordPress.
• Al copiar respaldos diarios, semanales o mensuales a otro servidor.
• Si cambias de centro de datos o proveedor de hosting.
• Cuando sincronizas archivos de aplicaciones entre producción y entorno de respaldo.
• Si planeas transferencias largas con riesgo de pérdida de conexión.

Por ejemplo, descargar una carpeta multimedia de 250 GB a tu PC para luego subirla al nuevo servidor implica dos transferencias separadas, alargando el proceso y saturando tu conexión doméstica o de oficina. Con rsync puedes transferir directamente del servidor origen al destino, evitando ese paso intermedio.

Requisitos previos

Para que la transferencia con rsync sea exitosa, no basta con conocer el comando. Verificar las condiciones de ambos servidores ayuda a minimizar pérdidas o transferencias incompletas. Los siguientes puntos deben revisarse especialmente en entornos de producción.

1. Verificar acceso SSH

Debe poder establecerse conexión SSH desde el servidor origen al destino. La prueba estándar es: ssh usuario@ip-servidor-destino. Si SSH funciona en un puerto distinto, se prueba así: ssh -p 2222 usuario@ip-servidor-destino. Si la conexión falla, rsync tampoco funcionará. Verifica firewall, Fail2ban, puerto SSH, permisos de usuario y autenticación por contraseña o clave.

2. Confirmar instalación de rsync

La mayoría de distribuciones Linux traen rsync instalado; no obstante, conviene comprobarlo. En sistemas basados en Debian o Ubuntu, ejecuta rsync --version. Si falta, se instala con apt install rsync. En AlmaLinux, Rocky Linux o CentOS, usa dnf install rsync o yum install rsync. En VPS Linux de Hostragons, la instalación suele ser cuestión de segundos.

3. Calcular espacio en disco

Si no hay suficiente espacio en el servidor destino, la transferencia se interrumpe. Para conocer el tamaño de la carpeta origen, usa du -sh /ruta/origen. Para ver espacio libre en destino, df -h. Planifica dejar espacio extra para archivos temporales y logs. Por ejemplo, para mover 500 GB, reserva al menos 550-600 GB libres.

4. Planificar servicios críticos y archivos en cambio

En sitios web activos, los archivos pueden cambiar durante la transferencia, sobre todo cargas de usuarios, cachés y logs. En migraciones grandes, primero se transfiere la mayor parte de datos, luego se pone el sitio en modo mantenimiento para sincronizar los cambios finales con otro rsync. Así se reduce el tiempo de interrupción a minutos. Para sitios WordPress, puedes apoyarte en guías como Guía para migrar hosting de WordPress.

Comando básico rsync para transferir archivos entre servidores

La estructura más común es: rsync -avz /ruta/origen/ usuario@ip-destino:/ruta/destino/. Aquí, -a es modo archivo que preserva permisos, marcas de tiempo y enlaces simbólicos; -v muestra detalles; -z comprime la transferencia. La barra al final de la ruta origen es clave: /ruta/origen/ copiará solo el contenido, mientras que /ruta/origen copiará la carpeta completa dentro del destino.

Imaginemos que quieres mover los 180 GB de /var/www/site/public_html/ del servidor antiguo al nuevo en la misma ruta. El comando sería: rsync -avz /var/www/site/public_html/ root@203.0.113.20:/var/www/site/public_html/. Esto transfiere los archivos vía SSH del servidor origen al destino.

Si prefieres no usar root, crea un usuario con permisos de escritura en la carpeta destino, por ejemplo deploy, y ajusta la propiedad de los directorios. Aunque usar root es práctico en producción, por seguridad es mejor usuarios con permisos limitados.

Parámetros recomendados para transferencias seguras y resistentes

Para grandes archivos no basta con el comando básico. Hay que contemplar desconexiones, archivos parciales, borrados accidentales y redes lentas. Un comando robusto para muchos casos es:

rsync -aHAXv --numeric-ids --partial --progress --append-verify -e ssh /ruta/origen/ usuario@ip-destino:/ruta/destino/

En este comando -a es modo archivo, -H preserva hard links, -A mantiene permisos ACL, -X conserva atributos extendidos. --numeric-ids usa IDs numéricos en lugar de nombres de usuario, útil si cambian entre servidores. --partial guarda archivos incompletos para continuar después. --progress muestra el avance. --append-verify continúa archivos grandes desde donde quedaron, verificando la parte añadida.

No todos los parámetros son necesarios siempre. Para un sitio web simple, -aHAX puede ser suficiente; en aplicaciones con permisos especiales, ACL y atributos extendidos son críticos. Por eso siempre conviene hacer pruebas.

¿Usas un puerto SSH diferente? Así se ajusta el comando

Por seguridad, SSH puede funcionar en un puerto distinto al 22. Entonces hay que indicarlo en rsync. Un intento común es: rsync -avz -e ssh -p 2222 /ruta/origen/ usuario@ip-destino:/ruta/destino/, pero esto es incorrecto porque -p es parámetro de ssh, no de rsync. La forma correcta es:

rsync -avz -e 'ssh -p 2222' /ruta/origen/ usuario@ip-destino:/ruta/destino/

En algunos paneles o JSON, las comillas simples pueden comportarse distinto, por eso verifica que en el terminal las uses bien. Si usas autenticación por clave privada, añade -i:

rsync -avz -e 'ssh -p 2222 -i /root/.ssh/id_rsa' /ruta/origen/ usuario@ip-destino:/ruta/destino/

Este método es común en automatizaciones y tareas programadas (cron).

Prueba previa: uso de --dry-run

Antes de mover datos importantes, un paso profesional es usar --dry-run. Este parámetro simula la transferencia sin copiar archivos, mostrando qué se transferiría. Así se detectan errores de rutas, directorios o borrados inesperados.

Ejemplo: rsync -avz --dry-run /var/www/site/ usuario@ip-destino:/var/www/site/. La salida indica archivos que se copiarían, directorios creados y resumen. Si usas --delete (que borra en destino archivos que no están en origen), la prueba es aún más crítica para evitar pérdidas.

El flujo recomendado es: prueba SSH, verifica espacio en disco, ejecuta rsync con --dry-run, hace una prueba real con carpeta pequeña y luego la transferencia principal. Aunque toma minutos extra, evita horas de errores costosos.

Optimización: compresión, ancho de banda y cifrado

El rendimiento de rsync depende de más que el tamaño de los archivos. CPU, tipo de disco, latencia de red, ancho de banda y cantidad de archivos influyen. Muchas carpetas con archivos pequeños tardan más que uno con pocos archivos grandes, por el manejo de metadatos. VPS con discos NVMe suelen ser más rápidos en lectura/escritura. Si planeas transferencias intensas, considera opciones como servidor VPS NVMe.

-z comprime datos en tránsito, útil para archivos de texto, logs o backups no comprimidos. Pero no acelera archivos ya comprimidos como zip, tar.gz, jpg o mp4 y puede consumir CPU innecesariamente. En conexiones rápidas (1 Gbps) y archivos multimedia grandes, desactivar -z puede mejorar la velocidad. En redes lentas y archivos textuales, -z ahorra ancho de banda.

Para limitar ancho de banda, usa --bwlimit. Por ejemplo, --bwlimit=50000 limita a unos 50 MB/s. Esto es útil para no afectar el tráfico de un sitio en producción. Programar transferencias en horarios de baja actividad, poner límites y monitorizar carga (load average) es una buena práctica.

Comparativa: rsync, scp, SFTP y FTP

Hay varias formas de mover archivos, cada una con ventajas y desventajas. La siguiente tabla resume cuál es mejor según el escenario de archivos grandes o migraciones:

Como se ve, rsync es superior para sincronizaciones repetidas y archivos grandes. scp es simple y útil, pero menos inteligente con cambios incrementales. FTP sin cifrado no cumple estándares modernos. En paneles de hosting FTP puede ser cómodo, pero para transferencias críticas se recomienda SSH.

Ejemplo de flujo para migrar un sitio web en vivo

Al mover un sitio, no solo se copian archivos: también hay que validar DNS, base de datos, SSL, versión PHP, permisos y correo. Aquí un flujo de ejemplo para sitios con archivos grandes y mínima interrupción:

• Prepara en el servidor nuevo el servidor web, PHP, base de datos y módulos necesarios.
• Reduce el TTL DNS a valores bajos (ej. 300 segundos) antes de la migración. Para gestionar dominios, consulta Consulta de dominio y gestión de dominio.
• Inicia la primera transferencia rsync con el sitio activo, moviendo la mayoría de datos.
• Exporta y transfiere la base de datos al nuevo servidor.
• Activa modo mantenimiento para el sitio.
• Ejecuta un segundo rsync para sincronizar los últimos cambios.
• Actualiza la base de datos o usa estrategias incrementales.
• Verifica permisos, funcionalidad y logs en el nuevo servidor.
• Instala o renueva el certificado SSL. Para ello, puede ayudarte instalación de certificado SSL.
• Actualiza registros DNS para apuntar a la nueva IP.

La transferencia principal se hace con el sitio activo, reduciendo el tiempo de caída a lo necesario para último rsync y cambio DNS. En sitios WordPress con archivos multimedia grandes, este método puede reducir horas de inactividad a minutos.

Verificación de integridad de datos

Tras finalizar la transferencia, no basta con que el comando haya terminado. Debes comparar número de archivos, tamaños y contenido crítico. Para una revisión rápida, compara tamaño de carpetas con du -sh en origen y destino. Ten en cuenta que puede haber pequeñas diferencias por el sistema de archivos.

Para mayor precisión, ejecuta rsync otra vez con los mismos parámetros. Si no hay archivos nuevos que copiar, la salida será mínima.

Para validar con checksum, usa:

rsync -avc --dry-run /ruta/origen/ usuario@ip-destino:/ruta/destino/

El parámetro -c compara archivos por checksum además de fecha y tamaño. Esto puede consumir CPU y disco, así que úsalo con precaución en archivos muy grandes. Es recomendable para archivos críticos, dumps de base de datos o documentos sensibles.

Si migraste un sitio web, revisa también desde la aplicación: página principal, panel de administración, subida de imágenes, procesos de pago, formularios y logs de errores. En e-commerce no basta con archivos; integra y prueba pagos y cron jobs en el nuevo servidor.

Errores comunes y soluciones

Error Permission denied

Este fallo suele deberse a permisos insuficientes del usuario SSH, falta de escritura en destino o problemas con claves. Primero prueba conexión SSH con el usuario indicado. Si funciona, intenta crear un archivo en destino. Ajusta propietarios con chown o considera usar sudo si es necesario.

Error No space left on device

Cuando no hay espacio suficiente en destino, la transferencia se detiene. Usa df -h para revisar discos. A veces la partición raíz está libre, pero /tmp o el punto de montaje destino está lleno. Limpia logs, backups antiguos o cachés. Si es recurrente, considera ampliar disco o subir a un VPS con mayor capacidad.

Error Connection reset o Broken pipe

Las desconexiones en transferencias largas son comunes. Si usas --partial y --append-verify, puedes reanudar con el mismo comando. Ajustar keepalive en SSH ayuda: en cliente, ServerAliveInterval 60 reduce desconexiones por inactividad.

Transferencia muy lenta

La lentitud puede venir de muchos archivos pequeños, limitaciones de disco o CPU, compresión inadecuada o ancho de banda. Para muchos archivos pequeños, crear primero un archivo tar puede acelerar el proceso, aunque pierdes la ventaja incremental de rsync. Para archivos grandes y comprimidos, prueba sin -z. Usa herramientas como iotop, htop e iftop para identificar el cuello de botella.

Buenas prácticas de seguridad

No descuides la seguridad al transferir archivos entre servidores. El acceso root, claves SSH y datos sensibles deben protegerse. Prioriza acceso mediante claves SSH con passphrase en lugar de contraseñas. Protege permisos de archivos de claves y nunca compartas claves privadas.

Crea usuarios temporales con acceso solo a las carpetas necesarias para la transferencia. Una vez finalizado el proceso, revoca permisos o desactiva la cuenta. Limita acceso SSH por IP, configura firewall, usa Fail2ban y mantén OpenSSH actualizado.

Para archivos de base de datos, documentos de clientes o datos personales, elimina archivos temporales en origen y destino después de la transferencia. Evita dejar archivos .sql, .zip o .tar accesibles desde el directorio web, ya que es un riesgo de seguridad. Guarda estos archivos en carpetas fuera del alcance público o bórralos tras el proceso.

Uso de rsync para copias de seguridad automáticas

rsync no solo sirve para migraciones puntuales, sino también para respaldos regulares. Puedes programar tareas cron que cada noche copien una carpeta a un servidor de respaldo usando rsync con clave SSH sin contraseña. Así solo se transfieren archivos nuevos o modificados, y puedes limitar ancho de banda.

Ejemplo:

rsync -a --delete --bwlimit=30000 /var/www/site/ backup@ip-respaldo:/backup/site/

Este comando sincroniza la carpeta destino con el origen, borrando archivos en destino que ya no existan en origen. Usa --delete con precaución para evitar pérdidas. Para estrategias críticas, combina con snapshots, carpetas diarias o sistemas de versionado.

En hosting, la regla 3-2-1 es referencia: al menos 3 copias de los datos, en 2 medios diferentes, con 1 copia en ubicación distinta. rsync facilita la parte de replicar datos entre servidores. Para infraestructuras más avanzadas, revisa Soluciones de copia de seguridad y servicios de hosting corporativo para complementar tu plan.

Lista rápida antes de iniciar la transferencia

Antes de empezar la transferencia de archivos grandes, sigue esta lista para minimizar riesgos. En entornos de producción debería ser un procedimiento estándar.

• ¿rsync está instalado en origen y destino?
• ¿Se comprobó la conexión SSH con usuario y puerto correctos?
• ¿Hay suficiente espacio libre en destino?
• ¿Se hizo una prueba con --dry-run?
• ¿Se planificó modo mantenimiento y sincronización final para el sitio en vivo?
• ¿Si usas --delete, se verificaron bien las rutas destino?
• ¿Se realizará revisión de tamaños, permisos y pruebas de aplicación tras la transferencia?
• ¿Se limpiarán archivos temporales y backups seguros después?

Aunque simple, esta lista previene los errores más frecuentes: rutas erróneas, permisos insuficientes, espacio insuficiente y cambios DNS sin planificar. Un proceso rsync bien planificado reduce tiempos y facilita recuperaciones.

Preguntas frecuentes

Si la conexión se pierde durante rsync por SSH, ¿la transferencia empieza de nuevo?

No, si usas los parámetros correctos no. Las opciones --partial y --append-verify permiten conservar archivos incompletos y reanudar la transferencia desde donde se interrumpió. Aun así, en procesos críticos revisa espacio en destino y estado de archivos antes de reintentar.

¿Se puede migrar una base de datos directamente con rsync?

rsync solo copia archivos; mover archivos de bases de datos en uso no es seguro. Para MySQL o MariaDB usa mysqldump o herramientas de backup físico. Luego transfiere el archivo generado con rsync. En sistemas activos planifica modo mantenimiento o replicación para garantizar consistencia.

¿Se requiere acceso root en ambos servidores para usar rsync?

No es obligatorio. Basta un usuario con permisos de escritura en la carpeta destino. Pero para conservar propiedad, ACL o permisos especiales puede ser necesario más privilegios. Por seguridad, lo ideal es usar usuarios limitados con solo los permisos necesarios.

¿Es seguro usar --delete?

Si se usa bien, --delete sincroniza el destino exactamente con origen. Pero si se ejecuta en rutas erróneas puede borrar datos importantes. Por eso siempre prueba con --dry-run y verifica rutas antes de usarlo.

¿En transferencias grandes, rsync o scp es mejor?

Para copias pequeñas y puntuales, scp puede ser suficiente. Pero en grandes volúmenes, múltiples archivos o sincronizaciones repetidas, rsync es superior al detectar cambios, reanudar transferencias, limitar ancho de banda y permitir pruebas.

Resumen y próximos pasos

Transferir archivos gigantes entre dos servidores con rsync sobre SSH es un método rápido, seguro y fácil de controlar. Con los parámetros adecuados, resiste desconexiones, copia solo cambios y reduce interrupciones en sitios en vivo. Para mejores resultados, primero verifica SSH y espacio en disco, prueba con --dry-run y luego ejecuta la transferencia principal de forma planificada.

Si planeas migrar a un servidor nuevo, almacenamiento de alta capacidad o hosting más potente, revisa las soluciones de Hostragons y complementa con VPS, hosting, dominios y SSL para hacer tu migración más segura. Comienza con pruebas pequeñas, mide resultados y programa la sincronización final cuidadosamente para un cambio sin sorpresas.