¿Vale la pena cambiar rsync por rclone? Mi experiencia real en entornos de verdad

Durante muchos años rsync ha sido mi herramienta por defecto en Linux para casi todo: backups, despliegues, sincronizaciones entre servidores, migraciones… Es sólida, predecible y muy difícil de romper. La mayoría de sysadmins la tenemos la primera opción para utilizar.

Pero en los últimos tiempos, trabajando con volúmenes cada vez más grandes —sobre todo cuando el destino es almacenamiento en la nube—, empecé a notar que las sincronizaciones tardaban más de lo razonable. No era por falta de ancho de banda ni por CPU saturada… era simplemente el modelo de ejecución de rsync el que empezaba a sufrir.

Ahí fue cuando decidí darle una oportunidad seria a rclone.

Esta nota no va de enterrar rsync ni de decir que «rclone es el futuro y ya«. Es más bien una reflexión honesta, desde la trinchera, sobre en qué casos rclone me ha dado una mejora real y en cuáles sigo prefiriendo rsync sin dudarlo.

El talón de Aquiles de rsync (en algunos escenarios concretos)

rsync es imbatible en lo que fue diseñado para hacer:

• Transferencia diferencial por bloques (solo envía lo que cambió dentro del archivo).
• Preservación casi perfecta de permisos, ACLs, atributos extendidos, hardlinks…
• Replicación muy fiel en entornos POSIX.
• Sincronización eficiente cuando hay pocos archivos grandes con cambios pequeños.

Pero hay un detalle clave en su arquitectura: carga toda la lista de archivos en memoria (tanto del origen como del destino) y luego procesa la transferencia de manera básicamente secuencial, archivo por archivo. En árboles de directorios pequeños o medianos esto no molesta. El problema aparece cuando tienes:

• Millones de archivos pequeños.
• Estructuras de directorios muy profundas.
• Latencia de red notable (incluso en enlaces rápidos).
• Conexiones de alta capacidad (10 Gbps o más).

En esos casos, el tiempo que se va en recorrer metadatos, hacer stat(), comparar checksums y gestionar cada archivo individualmente empieza a pesar más que la propia transferencia de datos. El enlace de red se queda medio vacío, los discos no van al límite… simplemente la herramienta no escala tan bien como podría.

Qué trae rclone a la mesa (y por qué cambia el juego)

rclone nació pensando en almacenamiento de objetos (S3, Google Cloud Storage, Backblaze B2, etc.), pero también funciona perfectamente entre rutas locales o con backends como SFTP, WebDAV, etc.La gran diferencia no es que sea “más nuevo” o tenga un algoritmo mágico. Es que desde el diseño está pensado para paralelismo configurable.

Por defecto ya hace varias transferencias simultáneas, y puedes subir o bajar el número según necesites:

rclone sync /data remoto:backup \
  --transfers 16 \
  --checkers 32 \
  --progress

• –transfers –> cuántos archivos se copian en paralelo.
• –checkers –> cuántos hilos comparan origen vs destino (muy útil cuando hay millones de archivos).

En datasets con muchos ficheros pequeños la diferencia es brutal. En mi caso, sincronizando varios millones de objetos hacia almacenamiento remoto, el tiempo total se quedó en menos de la mitad solo con ajustar el paralelismo. No porque el algoritmo sea “mejor” en teoría, sino porque aprovecha mucho mejor la CPU, los discos y la red disponibles hoy en día.

Comparativa rápida y sin fanatismos

Esto deja claro lo principal: no son herramientas que hagan exactamente lo mismo. Son complementarias más que enemigas.

Escenarios donde rsync sigue siendo mi primera opción

Hay casos en los que no se me ocurriría cambiar:

• Backups bare-metal o clonado fiel de servidores enteros.
• Necesidad estricta de preservar ACLs, atributos extendidos, hardlinks…
• Sincronizaciones donde solo cambian partes pequeñas de archivos grandes (logs rotados, bases de datos con appends, etc.).

Aquí el algoritmo delta de rsync sigue siendo imbatible en consumo de ancho de banda y tiempo real.

Dónde rclone me ha hecho ganar mucho tiempo

Lo elijo sin pensarlo dos veces cuando:

• El destino es un bucket S3, GCS, Azure Blob, B2…
• Tengo millones (o cientos de miles) de objetos/archivos pequeños.
• La ventana de backup o migración es crítica.
• Quiero saturar de verdad un enlace de 10 Gbps o superior.

También es la opción lógica cuando el cuello de botella real no es la red, sino el procesamiento secuencial de la herramienta que estás usando.

Ojo: subir mucho –transfers sin medir puede saturar discos HDD, disparar IOPS en bases de datos o incluso hacer que el sistema se vuelva inestable. Siempre hay que probar con números razonables según el hardware (8–16–32 suele ser un buen rango de prueba).

Lo que me llevo después de usar ambos a diario

La conclusión más honesta que saqué es que no se trata de moderno vs clásico. Se trata de arquitectura y tipo de workload.

rsync sigue siendo una herramienta brutalmente buena dentro de su nicho. rclone simplemente encaja mejor en infraestructuras cloud-native y en datasets masivos con mucha concurrencia.

En mi día a día ya no uso rsync para todo. Sigo tirando de él para tareas donde la fidelidad POSIX absoluta es imprescindible (clonados de servidores, copias locales críticas, etc.). Pero para sincronizaciones grandes hacia la nube o buckets remotos, rclone se ha convertido en mi opción por defecto.

Si estás empezando a lidiar con volúmenes grandes o con almacenamiento cloud, te recomiendo hacer la prueba tú mismo:

1. Elige un dataset representativo de tu entorno.
2. Mide rsync con las opciones que más sueles usar (-aHAX –info=progress2 por ejemplo).
3. Prueba rclone con –transfers 8..32, –checkers 16..64 y –fast-list si el backend lo soporta.
4. Compara tiempos reales y saturación de red/CPU/disco.

Muchas veces la respuesta no es “una herramienta gana siempre”, sino “esta me ahorra 3–4 horas cada noche… pues ya se que voy a usar”.

¡Gracias por llegar hasta aquí! Sigamos administrando.