Sincronizar y cifrar copias en la nube con rclone

Portada » General » Sincronizar y cifrar copias en la nube con rclone

Tener copias de seguridad fiables, rápidas de restaurar y bien protegidas se ha vuelto casi obligatorio en cualquier entorno, ya sea un servidor en producción o tu propio portátil personal. Cada vez generamos más datos, los guardamos en más sitios y los riesgos (fallos de disco, ransomware, robos, errores humanos…) no paran de crecer.

Rclone se ha convertido en la navaja suiza del almacenamiento en la nube: un binario de línea de comandos capaz de hablar con decenas de servicios (Google Drive, S3, Backblaze B2, OneDrive, Dropbox, SFTP, WebDAV, etc.), sincronizar como rsync, cifrar en el lado del cliente y hasta montar esos remotos como si fueran una carpeta local. Combinado con buenas prácticas (3-2-1, multi-nube, automatización), permite montar un sistema de copias incremental, cifrado y externalizado muy sólido.

Qué es rclone y por qué es ideal para copias en la nube

Rclone es una herramienta CLI de código abierto escrita en Go que actúa como un “rsync para la nube”. Replica muchos comandos conocidos (cp, mv, sync, ls, tree, ncdu, mount…) pero operando sobre más de 70 backends distintos: desde servicios de consumo como Google Drive o Dropbox hasta almacenamiento de objetos S3, WebDAV, SFTP o soluciones autoalojadas.

Su principal ventaja respecto a rsync tradicional es que entiende las APIs de los proveedores: gestiona paginación, límites de peticiones, reintentos, cachés de directorios, subidas multipart, checksums, etc. Esto permite que las sincronizaciones con la nube sean eficientes y fiables, incluso con millones de ficheros o archivos muy grandes.

A nivel de arquitectura interna, rclone se organiza en capas: un núcleo que orquesta comandos y colas de trabajo, una abstracción de “backend” para unificar todos los proveedores y capas adicionales como VFS (para montajes y caché avanzada), Crypt (cifrado transparente) y Chunker (troceo de ficheros muy grandes). Esta modularidad es la que permite, por ejemplo, combinar cifrado sobre Google Drive montado vía FUSE sin que tú tengas que preocuparte de cómo se almacenan realmente los datos.

En la práctica, rclone encaja muy bien en la regla de backups 3-2-1: puedes mantener copias locales (rsync, snapshots), otra copia en un servidor propio vía SFTP y una tercera en la nube, todo orquestado por scripts y timers de systemd o cron, y con una única sintaxis para todos los destinos.

Instalación y requisitos para sacarle partido

Para la mayoría de usuarios, el método recomendado de instalación en Linux es el script oficial, que descarga la última versión estable, instala el binario y puede añadir páginas man y autocompletado:

En Linux (script oficial)

curl -fsSL https://rclone.org/install.sh | sudo bash
rclone version

Si prefieres más control, puedes instalar paquetes .deb o .rpm, o incluso compilar desde código con Go (>= 1.21). En Windows, la opción más sencilla es usar Winget o Chocolatey; en macOS, Homebrew o el zip oficial.

A nivel de requisitos mínimos, rclone se conforma con muy poco: 512 MB de RAM, un único vCPU y unos 100 MB de espacio. Para montajes intensivos con VFS y caché de lectura/escritura es razonable tener 2 GB de RAM o más, kernel moderno (FUSE3 en Linux) y algo de espacio rápido (SSD) para el directorio de caché.

No olvides las dependencias de FUSE si quieres montar remotos: en Ubuntu/Debian bastan paquetes como fuse3 y libfuse3-dev y activar user_allow_other en /etc/fuse.conf para que otros usuarios puedan acceder al punto de montaje.

Configurar remotos: de Google Drive y S3 a SFTP

El corazón de rclone son los “remotos”: cada remoto es una sección en ~/.config/rclone/rclone.conf que describe cómo conectar con un backend concreto (tipo, credenciales, región, opciones avanzadas, etc.). Una vez creado, podrás usar ese nombre como prefijo en todos los comandos (gdrive:backup/, s3-backup:my-bucket/, b2:archivos/, etc.).

La forma estándar de crear remotos es con el asistente interactivo, lanzando:

rclone config

El asistente permite añadir nuevos remotos (n), renombrarlos, duplicarlos, eliminar, o incluso cifrar el propio archivo de configuración con una contraseña maestra (s). Para cada remoto pedirán un nombre, seleccionar el tipo (drive, s3, b2, sftp, webdav, etc.) y luego las credenciales correspondientes.

Ejemplo rápido: remoto para Amazon S3

[s3-backup]
type = s3
provider = AWS
access_key_id = TU_ACCESS_KEY
secret_access_key = TU_SECRET_KEY
region = eu-west-1
storage_class = STANDARD_IA

Ejemplo rápido: remoto para Google Drive

[gdrive]
type = drive
scope = drive
client_id = TU_CLIENT_ID.apps.googleusercontent.com
client_secret = TU_CLIENT_SECRET
token = {"access_token":"...","refresh_token":"...","expiry":"..."}

En servidores sin navegador (VPS, máquinas headless), la autenticación OAuth de Drive/OneDrive se hace en dos pasos: en el servidor eliges «no» a la auto-config, copias el comando rclone authorize, lo ejecutas en tu PC con navegador, obtienes un token JSON y lo pegas en el asistente del servidor. Así puedes seguir usando rclone en entornos puramente de consola.

Si quieres evitar ficheros de configuración en disco (contenedores efímeros, servidores muy restringidos), es posible definir remotos vía variables de entorno como RCLONE_CONFIG_S3_TYPE, RCLONE_CONFIG_S3_ACCESS_KEY_ID, RCLONE_CONFIG_S3_SECRET_ACCESS_KEY, y usarlos directamente en los comandos.

Primeros pasos: listar, copiar, mover y sincronizar

La sintaxis base de rclone es muy sencilla:

rclone [opciones] subcomando origen destino

Para explorar lo que tienes en los remotos hay varios subcomandos útiles:

• rclone listremotes muestra todos los remotos configurados.
• rclone lsd remote: lista solo directorios en el remoto.
• rclone ls remote:carpeta/ muestra ficheros y tamaños.
• rclone tree remote:carpeta/ enseña un árbol de directorios.
• rclone size remote:carpeta/ cuenta ficheros y total de bytes.

Copiar datos es igual de directo: puedes ir de local a nube, de nube a local o entre nubes, con el mismo comando:

• rclone copy /datos/ gdrive:backups/datos/ -P
• rclone copy s3-backup:bucket/ /restauracion/ -P
• rclone copy gdrive:origen/ b2-secundario:destino/ -P (aprovecha copia lado servidor si el backend lo permite).

Para replicar directorios de forma “espejo” se usa sync: obliga a que el destino sea exactamente igual al origen, eliminando archivos sobrantes del destino. Es potentísimo pero hay que usarlo con cabeza.

rclone sync /srv/web/ s3-backup:prod-web/ -P --dry-run

El flag --dry-run es obligatorio moralmente la primera vez que sincronizas algo crítico: te enseña qué borraría, qué copiaría y qué mantendría sin tocar, sin hacer cambios reales. Una vez que el plan tiene sentido, puedes repetir el comando sin --dry-run.

Si quieres evitar que un backup mal planteado borre cosas por error, puedes recurrir a copy en lugar de sync, o combinar sync con estructuras de versionado usando --backup-dir, de manera que los ficheros eliminados se muevan a un directorio de versiones en lugar de desaparecer del todo.

Filtrado, limitación de ancho de banda y rendimiento

Para que las copias no sean un agujero negro de datos y tiempo, rclone ofrece un sistema de filtros muy flexible. Puedes excluir extensiones, carpetas enteras, archivos grandes, ficheros temporales o logs antiguos, usando --exclude, --include, --min-size, --max-age, etc.

rclone sync /datos/ gdrive:backup/ \
--exclude "*.tmp" \
--exclude "cache/**" \
--max-size 100M \
--min-age 1d

Si el ancho de banda es limitado (o compartes línea con más gente), --bwlimit permite fijar un máximo global o incluso un calendario horario:

rclone sync /datos/ remote:backup/ --bwlimit "08:00,512k 12:00,10M 18:00,off"

El rendimiento se ajusta fino con tres parámetros clave: --transfers (número de subidas/bajadas en paralelo), --checkers (hilos revisando qué hay que transferir) y --buffer-size (tamaño del buffer en memoria). Para enlaces potentes y proveedores como S3, Drive o B2, valores como 8-16 transfers, 16-32 checkers y buffers de 16-64 MB suelen dar muy buenos resultados.

rclone sync /datos/ s3-backup:empresa/ \
--transfers 8 \
--checkers 16 \
--buffer-size 32M \
-P

Cifrado en el lado del cliente con remotos crypt

Si subes información sensible a la nube, el cifrado cliente es obligatorio. Rclone resuelve esto con el backend crypt, que actúa como una “capa” sobre otro remoto: todo lo que copies a ese remoto virtual se cifrará antes de salir de tu máquina, incluyendo contenido y (si quieres) nombres de archivo y de directorio.

Crear un remoto cifrado se hace también con rclone config. Los pasos básicos son:

• Crear primero el remoto base (por ejemplo gdrive apuntando a tu Google Drive).
• Volver a ejecutar rclone config, elegir “nuevo remoto” y poner un nombre como gdrive-crypt.
• Seleccionar tipo de almacenamiento crypt.
• Cuando pregunte “remote to encrypt/decrypt”, indicar algo del estilo gdrive:BackupsCifrados o gdrive:encrypted/.
• Elegir el modo de cifrado de nombres: standard (cifrado completo), obfuscate (obfuscación ligera) u off (solo añade .bin).
• Decidir si también se cifran los nombres de directorio (true recomendado).
• Introducir una contraseña y, opcionalmente, una segunda contraseña de “sal” (muy recomendable para endurecer ataques de diccionario).

El resultado será una sección en el config como esta:

[gdrive-crypt]
type = crypt
remote = gdrive:BackupsCifrados
filename_encryption = standard
directory_name_encryption = true
password = * ENCRYPTED *
password2 = * ENCRYPTED *

A partir de aquí, todo lo que envíes a gdrive-crypt: irá cifrado. Si miras el contenido desde el remoto base (gdrive:BackupsCifrados) o la web de Google Drive, verás nombres de archivo ininteligibles y no podrás abrir nada. En cambio, si listas gdrive-crypt: con rclone, obtendrás nombres y contenidos en claro, de forma transparente.

rclone copy /var/backups/ gdrive-crypt:servidor1/ -P

Es fundamental que guardes la contraseña y el archivo de configuración en un gestor de contraseñas o lugar seguro. Si pierdes ambas cosas, los datos almacenados en el remoto crypt serán irrecuperables aunque tengas acceso a la cuenta de Google Drive o S3, porque el proveedor nunca ve las claves en claro.

Cifrar también el archivo de configuración de rclone

El fichero rclone.conf contiene tokens OAuth y contraseñas de crypt. Rclone las ofusca ligeramente, pero cualquiera con acceso al archivo podría usarlas. Por eso conviene activar la contraseña de configuración desde el propio asistente.

rclone config

En el menú principal, elige la opción s) Set configuration password. Rclone te preguntará si quieres añadir o cambiar la contraseña, y a partir de ese momento el archivo se almacenará cifrado. Para entornos automatizados puedes definir la clave en la variable de entorno RCLONE_CONFIG_PASS, de forma que scripts y servicios systemd puedan leerla sin pedir interacción.

Esta capa extra viene muy bien en máquinas compartidas, servidores donde otros usuarios tienen acceso al home o cuando copias el fichero de configuración entre distintos equipos para reutilizar remotos y claves crypt.

Montar almacenamiento en la nube como si fuera local

Además de copiar o sincronizar, rclone permite montar remotos como sistemas de archivos mediante FUSE. Esto te deja, por ejemplo, montar Google Drive en /mnt/gdrive o un remoto crypt como directorio para que tus aplicaciones vean todo como local.

mkdir -p /mnt/gdrive
rclone mount gdrive: /mnt/gdrive \
--daemon \
--allow-other \
--vfs-cache-mode full \
--vfs-cache-max-size 20G

El modo VFS controla cómo se cachean los ficheros:

• off: sin caché, solo lectura directa (apto para lecturas secuenciales, no para edición).
• minimal: caché mínima, adecuada para subidas sencillas.
• writes: cachea escrituras hasta que se suben (bueno para aplicaciones que guardan con frecuencia).
• full: caché completa de lectura/escritura, ideal para usar la nube casi como un disco local, a costa de usar más espacio en disco local para el cache-dir.

Para montajes persistentes en servidores, lo más limpio es crear un servicio systemd que arranque tras la red, ejecute rclone mount con todas las opciones necesarias y gestione logs y caché. Así podrás usar systemctl start/stop/status y dejarte de scripts en segundo plano.

Desmontar es tan simple como usar fusermount -u /mnt/gdrive o, si usas systemd, systemctl stop rclone-gdrive.service. En macOS la orden equivalente sería umount sobre el punto de montaje.

Automatizar copias: scripts, cron y systemd timers

Donde rclone brilla de verdad es combinado con automatización. Un backup que hay que lanzar a mano acaba no haciéndose; un script bien montado con logs, exclusiones y alertas de fallo puede ejecutarse a diario sin que te acuerdes.

Un patrón clásico en servidores Linux es crear un script tipo /usr/local/bin/rclone-backup.sh que:

• Agrupe directorios de interés (/var/www, /etc, /home…).
• Genere dumps de bases de datos (MySQL, PostgreSQL) en /var/backups/db-dumps.
• Use un remoto (idealmente crypt) para subir todo a la nube con rclone sync o rclone copy.
• Registre logs detallados en /var/log/rclone-backup.log.
• Aplique políticas de retención remota (--min-age 90d, --rmdirs).
• Notifique por correo o webhook (Slack, Discord) en caso de éxito o fallo.

Ese script puede dispararse con cron (por ejemplo, diario a las 3:00) o, de forma más robusta, con un timer de systemd que garantiza ejecuciones pendientes en caso de reinicio y da mejor visibilidad con systemctl list-timers.

Para multi-nube, la idea es duplicar la operación sobre varios remotos: un bucle sobre una lista de remotos (s3-backup, b2-backup, gdrive-backup, etc.) y sincronizar siempre la misma ruta local a cada destino. Así consigues redundancia entre proveedores por un coste adicional relativamente pequeño.

Casos prácticos: WordPress, grandes volúmenes y cifrado por capas

Un caso muy típico es el backup de un sitio WordPress a S3 o Drive: primero se hace un volcado de la base de datos (wp db export o mysqldump), luego se sincroniza el directorio del sitio excluyendo caches y logs, y por último se eliminan copias remotas anteriores a X días usando rclone delete --min-age 30d --rmdirs. Todo se puede encapsular en un pequeño script que se ejecute cada noche.

Otro patrón útil es combinar rsync local, EncFS/crypt y rclone: por ejemplo, crear copias incrementales locales con rsync usando --link-dest para ahorrar espacio, cifrar con EncFS o con un remoto crypt solo la carpeta de snapshots, y luego sincronizar esa estructura ya cifrada con rclone hacia la nube. De este modo tienes copias rápidas de restaurar en disco local y una réplica remota encriptada fuera de tu infraestructura.

Si gestionas volúmenes enormes con muchos ficheros pequeños (blogs con años de histórico, media servers, repositorios de código, etc.), conviene aprovechar filtros, paralelismo y, cuando sea posible, operaciones lado servidor (server-side copy) para minimizar tráfico. Rclone ofrece comandos como backend features y opciones específicas por backend (--drive-server-side-across-configs, parámetros --s3-*, --b2-*, etc.) que exprimen cada proveedor.

Para quien necesita máxima seguridad, es frecuente añadir varias capas: cifrado LUKS o similar en el disco local, remoto crypt en rclone, archivo de configuración cifrado y, si la política lo exige, cuentas de servicio dedicadas con permisos mínimos en cada proveedor de nube. Todo esto sigue siendo manejable porque, al final, el operador diario solo ve comandos sencillos como rclone sync o rclone mount.

Conociendo bien estas piezas —remotos, crypt, VFS, filtros, automatización y buenas prácticas de seguridad— es posible montar con rclone un sistema de copias en la nube que sea rápido, económico, resistente a desastres y, sobre todo, que no dependa de una única herramienta gráfica o del capricho de un único proveedor de almacenamiento.