{"id":163,"date":"2026-02-12T07:48:51","date_gmt":"2026-02-12T11:48:51","guid":{"rendered":"https:\/\/juredev.com\/blog\/?p=163"},"modified":"2026-02-16T10:22:27","modified_gmt":"2026-02-16T14:22:27","slug":"vale-la-pena-cambiar-rsync-por-rclone","status":"publish","type":"post","link":"https:\/\/juredev.com\/blog\/2026\/02\/vale-la-pena-cambiar-rsync-por-rclone\/","title":{"rendered":"\u00bfVale la pena cambiar rsync por rclone? Mi experiencia real en entornos de verdad"},"content":{"rendered":"\n

Durante muchos a\u00f1os rsync <\/strong>ha sido mi herramienta por defecto en Linux para casi todo: backups, despliegues, sincronizaciones entre servidores, migraciones\u2026 Es s\u00f3lida, predecible y muy dif\u00edcil de romper. La mayor\u00eda de sysadmins la tenemos la primera opci\u00f3n para utilizar.<\/p>\n\n\n\n

Pero en los \u00faltimos tiempos, trabajando con vol\u00famenes cada vez m\u00e1s grandes \u2014sobre todo cuando el destino es almacenamiento en la nube\u2014, empec\u00e9 a notar que las sincronizaciones tardaban m\u00e1s de lo razonable. No era por falta de ancho de banda ni por CPU saturada\u2026 era simplemente el modelo de ejecuci\u00f3n de rsync <\/strong>el que empezaba a sufrir.<\/p>\n\n\n\n

Ah\u00ed fue cuando decid\u00ed darle una oportunidad seria a rclone<\/strong>.<\/p>\n\n\n\n

Esta nota no va de enterrar rsync <\/strong>ni de decir que \u00abrclone es el futuro y ya<\/strong>\u00ab. Es m\u00e1s bien una reflexi\u00f3n honesta, desde la trinchera, sobre en qu\u00e9 casos rclone <\/strong>me ha dado una mejora real y en cu\u00e1les sigo prefiriendo rsync <\/strong>sin dudarlo.<\/p>\n\n\n\n

El tal\u00f3n de Aquiles de rsync (en algunos escenarios concretos)<\/h2>\n\n\n\n

rsync <\/strong>es imbatible en lo que fue dise\u00f1ado para hacer:<\/p>\n\n\n\n

    \n
  • Transferencia diferencial por bloques (solo env\u00eda lo que cambi\u00f3 dentro del archivo).<\/li>\n\n\n\n
  • Preservaci\u00f3n casi perfecta de permisos, ACLs, atributos extendidos, hardlinks\u2026<\/li>\n\n\n\n
  • Replicaci\u00f3n muy fiel en entornos POSIX.<\/li>\n\n\n\n
  • Sincronizaci\u00f3n eficiente cuando hay pocos archivos grandes con cambios peque\u00f1os.<\/li>\n<\/ul>\n\n\n\n

    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\u00e1sicamente secuencial, archivo por archivo. En \u00e1rboles de directorios peque\u00f1os o medianos esto no molesta. El problema aparece cuando tienes:<\/p>\n\n\n\n

      \n
    • Millones de archivos peque\u00f1os.<\/li>\n\n\n\n
    • Estructuras de directorios muy profundas.<\/li>\n\n\n\n
    • Latencia de red notable (incluso en enlaces r\u00e1pidos).<\/li>\n\n\n\n
    • Conexiones de alta capacidad (10 Gbps o m\u00e1s).<\/li>\n<\/ul>\n\n\n\n

      En esos casos, el tiempo que se va en recorrer metadatos, hacer stat(), comparar checksums y gestionar cada archivo individualmente empieza a pesar m\u00e1s que la propia transferencia de datos. El enlace de red se queda medio vac\u00edo, los discos no van al l\u00edmite\u2026 simplemente la herramienta no escala tan bien como podr\u00eda.<\/p>\n\n\n\n

      Qu\u00e9 trae rclone a la mesa (y por qu\u00e9 cambia el juego)<\/h2>\n\n\n\n

      rclone <\/strong>naci\u00f3 pensando en almacenamiento de objetos (S3, Google Cloud Storage, Backblaze B2, etc.), pero tambi\u00e9n funciona perfectamente entre rutas locales o con backends como SFTP, WebDAV, etc.La gran diferencia no es que sea \u201cm\u00e1s nuevo\u201d o tenga un algoritmo m\u00e1gico. Es que desde el dise\u00f1o est\u00e1 pensado para paralelismo configurable.<\/p>\n\n\n\n

      Por defecto ya hace varias transferencias simult\u00e1neas, y puedes subir o bajar el n\u00famero seg\u00fan necesites:<\/p>\n\n\n\n

      rclone sync \/data remoto:backup \\\n  --transfers 16 \\\n  --checkers 32 \\\n  --progress<\/code><\/pre>\n\n\n\n
        \n
      • –transfers –> cu\u00e1ntos archivos se copian en paralelo.<\/li>\n\n\n\n
      • –checkers –> cu\u00e1ntos hilos comparan origen vs destino (muy \u00fatil cuando hay millones de archivos).<\/li>\n<\/ul>\n\n\n\n
        En datasets con muchos ficheros peque\u00f1os la diferencia es brutal. En mi caso, sincronizando varios millones de objetos hacia almacenamiento remoto, el tiempo total se qued\u00f3 en menos de la mitad solo con ajustar el paralelismo. No porque el algoritmo sea \u201cmejor\u201d en teor\u00eda, sino porque aprovecha mucho mejor la CPU, los discos y la red disponibles hoy en d\u00eda.<\/p>\n\n\n\n
        Comparativa r\u00e1pida y sin fanatismos<\/h2>\n\n\n\n
        Aspecto<\/th>rsync<\/th>rclone<\/th><\/tr><\/thead>
        Transferencia diferencial (solo deltas)<\/td>S\u00ed<\/td>No (copia archivo completo)<\/td><\/tr>
        Paralelismo nativo<\/td>No (secuencial por defecto)<\/td>S\u00ed (configurable)<\/td><\/tr>
        Preservaci\u00f3n completa POSIX (ACLs, xattrs, hardlinks)<\/td>Excelente<\/td>Limitada \/ parcial<\/td><\/tr>
        Integraci\u00f3n nativa con proveedores cloud<\/td>B\u00e1sica (v\u00eda fuse o s3fs)<\/td>Excelente (muchos backends)<\/td><\/tr>
        Escala bien con millones de archivos peque\u00f1os<\/td>Regular \/ sufre<\/td>Muy bien<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
        Esto deja claro lo principal: no son herramientas que hagan exactamente lo mismo. Son complementarias m\u00e1s que enemigas.<\/p>\n\n\n\n
        Escenarios donde rsync sigue siendo mi primera opci\u00f3n<\/h2>\n\n\n\n
        Hay casos en los que no se me ocurrir\u00eda cambiar:<\/p>\n\n\n\n
          \n
        • Backups bare-metal o clonado fiel de servidores enteros.<\/li>\n\n\n\n
        • Necesidad estricta de preservar ACLs, atributos extendidos, hardlinks\u2026<\/li>\n\n\n\n
        • Sincronizaciones donde solo cambian partes peque\u00f1as de archivos grandes (logs rotados, bases de datos con appends, etc.).<\/li>\n<\/ul>\n\n\n\n
          Aqu\u00ed el algoritmo delta de rsync <\/strong>sigue siendo imbatible en consumo de ancho de banda y tiempo real.<\/p>\n\n\n\n
          D\u00f3nde rclone me ha hecho ganar mucho tiempo<\/h2>\n\n\n\n
          Lo elijo sin pensarlo dos veces cuando:<\/p>\n\n\n\n
            \n
          • El destino es un bucket S3, GCS, Azure Blob, B2\u2026<\/li>\n\n\n\n
          • Tengo millones (o cientos de miles) de objetos\/archivos peque\u00f1os.<\/li>\n\n\n\n
          • La ventana de backup o migraci\u00f3n es cr\u00edtica.<\/li>\n\n\n\n
          • Quiero saturar de verdad un enlace de 10 Gbps o superior.<\/li>\n<\/ul>\n\n\n\n
            Tambi\u00e9n es la opci\u00f3n l\u00f3gica cuando el cuello de botella real no es la red, sino el procesamiento secuencial de la herramienta que est\u00e1s usando.<\/p>\n\n\n\n
            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\u00fameros razonables seg\u00fan el hardware (8\u201316\u201332 suele ser un buen rango de prueba).<\/p>\n\n\n\n
            Lo que me llevo despu\u00e9s de usar ambos a diario<\/h2>\n\n\n\n
            La conclusi\u00f3n m\u00e1s honesta que saqu\u00e9 es que no se trata de moderno vs cl\u00e1sico. Se trata de arquitectura y tipo de workload.<\/p>\n\n\n\n
            rsync <\/strong>sigue siendo una herramienta brutalmente buena dentro de su nicho. rclone <\/strong>simplemente encaja mejor en infraestructuras cloud-native y en datasets masivos con mucha concurrencia.<\/p>\n\n\n\n
            En mi d\u00eda a d\u00eda ya no uso rsync para todo. Sigo tirando de \u00e9l para tareas donde la fidelidad POSIX absoluta es imprescindible (clonados de servidores, copias locales cr\u00edticas, etc.). Pero para sincronizaciones grandes hacia la nube o buckets remotos, rclone <\/strong>se ha convertido en mi opci\u00f3n por defecto.<\/p>\n\n\n\n
            Si est\u00e1s empezando a lidiar con vol\u00famenes grandes o con almacenamiento cloud, te recomiendo hacer la prueba t\u00fa mismo:<\/p>\n\n\n\n
              \n
            1. Elige un dataset representativo de tu entorno.<\/li>\n\n\n\n
            2. Mide rsync con las opciones que m\u00e1s sueles usar (-aHAX –info=progress2 por ejemplo).<\/li>\n\n\n\n
            3. Prueba rclone con –transfers 8..32, –checkers 16..64 y –fast-list si el backend lo soporta.<\/li>\n\n\n\n
            4. Compara tiempos reales y saturaci\u00f3n de red\/CPU\/disco.<\/li>\n<\/ol>\n\n\n\n
              Muchas veces la respuesta no es \u201cuna herramienta gana siempre\u201d, sino \u201cesta me ahorra 3\u20134 horas cada noche\u2026 pues ya se que voy a usar\u201d.<\/p>\n\n\n\n
              \u00a1Gracias por llegar hasta aqu\u00ed! Sigamos administrando.<\/p>\n","protected":false},"excerpt":{"rendered":"
              Durante muchos a\u00f1os rsync ha sido mi herramienta por defecto en Linux para casi todo: backups, despliegues, sincronizaciones entre servidores, migraciones\u2026 Es s\u00f3lida, predecible y muy dif\u00edcil de romper. La mayor\u00eda de sysadmins la tenemos la primera opci\u00f3n para utilizar. Pero en los \u00faltimos tiempos, trabajando con vol\u00famenes cada vez m\u00e1s grandes \u2014sobre todo cuando […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[5],"tags":[24],"class_list":["post-163","post","type-post","status-publish","format-standard","hentry","category-nota","tag-linux"],"_links":{"self":[{"href":"https:\/\/juredev.com\/blog\/wp-json\/wp\/v2\/posts\/163","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/juredev.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/juredev.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/juredev.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/juredev.com\/blog\/wp-json\/wp\/v2\/comments?post=163"}],"version-history":[{"count":0,"href":"https:\/\/juredev.com\/blog\/wp-json\/wp\/v2\/posts\/163\/revisions"}],"wp:attachment":[{"href":"https:\/\/juredev.com\/blog\/wp-json\/wp\/v2\/media?parent=163"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/juredev.com\/blog\/wp-json\/wp\/v2\/categories?post=163"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/juredev.com\/blog\/wp-json\/wp\/v2\/tags?post=163"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}