restic con rclone: usar cualquier nube como destino, y si hace falta cifrar dos veces

2026-10-18

restic habla de forma nativa con unos pocos destinos (carpeta local, SFTP, S3, Backblaze B2 y pocos más). Para el resto (Google Drive, OneDrive, pCloud y decenas de proveedores) usa rclone como puente: el repositorio se indica como rclone:nombre-remoto:ruta. La pregunta práctica es si hay que añadir rclone crypt por encima, dado que restic ya cifra. Esta es la prueba.

Condiciones: restic 0.16.4 y rclone 1.60.1 (el de Ubuntu 24.04), contraseñas desechables y una carpeta local como "nube", sin cuenta de ningún proveedor. Datos: 10 ficheros aleatorios de 1 MiB y un documento de texto. Script: tools/test-restic-rclone-backend.sh. No se probó la autorización de ningún proveedor real (el paso del navegador en rclone config) ni la velocidad con una conexión real.

A) restic sobre rclone

restic init -r rclone:nube:/ruta/nube/repoA
restic -r rclone:nube:/ruta/nube/repoA backup ~/datos
restic -r rclone:nube:/ruta/nube/repoA check

Todo funcionó a la primera: created restic repository, copia sin errores y no errors were found. Lo que ve el proveedor son los directorios del formato de restic (config, data, index, keys, locks, snapshots) y ficheros con nombres tipo hash. El contenido está cifrado por restic; quien tenga acceso a la nube ve que hay un repositorio restic, cuántos ficheros tiene y su tamaño aproximado.

B) restic sobre rclone crypt

rclone config create cifrado crypt remote /ruta/nube/cifrado password "$(rclone obscure 'clave-larga')"
restic init -r rclone:cifrado:repoB

También funcionó. Ahora el proveedor ve un único nombre de directorio opaco (4ep1vfpmrb65jq60dhv9odmvbg), sin el esquema config/data/index, así que ni siquiera se nota que es restic. Coste: la carpeta pasó de 10 296 KiB a 10 304 KiB (+8 KiB, menos del 0,1 % en este caso). La restauración desde B (restore latest) recuperó los 14 ficheros y directorios, y el sha256 del documento coincidió con el original.

¿Merece la pena el doble cifrado?

El contenido ya queda protegido con restic solo. crypt añade ocultar la estructura del repositorio y los nombres de directorio, a cambio de una segunda clave que perder: si pierdes la contraseña de crypt, el repositorio entero es irrecuperable aunque recuerdes la de restic. Y la clave de rclone queda ofuscada, no cifrada, en rclone.conf (ver rclone con cifrado). Mi criterio, sin haberlo medido más allá de esta prueba: con restic basta con una buena contraseña y una copia de ella en el gestor de contraseñas; crypt solo si quieres que el proveedor no sepa qué tipo de datos guardas.

Antes de usarlo con una nube de verdad

• Comprueba con una restauración real que lo que subes se recupera.
• Planifica verificaciones por tandas con check: en la nube cada lectura puede costar descarga (precios por TB).
• Elige el proveedor sabiendo que los límites de llamadas de la API de algunos servicios (Google Drive, por ejemplo) pueden ralentizar restic; no se midió aquí.

Este artículo no contiene enlaces de afiliado.