Rclone en respaldos S3: filtros, hash y restauración
Guía para mover respaldos con rclone hacia S3 compatible: filtros, verificación por hash, costo mensual y prueba de restauración antes de confiar.
Un comando rclone check no copia datos: compara origen y destino para decir qué falta. Esa diferencia importa cuando una pyme manda respaldos a S3 compatible y cree que el trabajo terminó al ver una carpeta remota. Rclone v1.74.4, publicado el 8 de julio de 2026, permite copiar, sincronizar, filtrar y verificar archivos. Esta guía explica qué dato viaja, quién lo puede borrar y cómo probar una restauración.
Dónde aparece el backup que nadie probó
La documentación de rclone lo define como una herramienta de línea de comandos para administrar archivos en almacenamiento remoto. La página de descargas muestra la versión v1.74.4 como release actual. La cifra que corrige la conversación aparece en costos: Backblaze B2 publica almacenamiento desde USD 6,95 por TB mensual en su página de precios. Un terabyte no obliga a pagar una licencia por usuario; obliga a escribir reglas de copia, retención y prueba. En una cooperativa eléctrica con enlaces rurales, el antagonista suele ser el script nocturno que dice "OK" aunque nadie abrió el archivo recuperado. El dato global marca escala: GitHub Octoverse 2025 registró más de 230 repositorios nuevos por minuto y 43,2 millones de pull requests fusionados por mes. Esa velocidad produce más archivos, builds, logs y bases que necesitan copia con dueño. Rclone no decide qué es importante. Toma una ruta local o remota, aplica reglas y mueve objetos hacia otro destino. Si el filtro está mal, copia basura. Si el permiso está abierto, alguien borra el respaldo. Si la verificación se salta, el error duerme hasta el incidente.
Cómo funciona por dentro
El flujo arranca con una carpeta de origen: dumps de PostgreSQL, exportaciones de ERP, archivos de configuración o snapshots. Rclone lee esa ruta, aplica filtros por nombre, edad, tamaño o extensión desde filtering, y ejecuta copy o sync hacia un bucket S3. En S3, cada objeto conserva clave, tamaño, fecha y metadatos. La guía S3 de rclone aclara que algunas comparaciones pueden requerir HEAD para leer modificación y metadatos. El segundo paso es la verificación. Rclone check compara origen y destino; si el backend tiene hash compatible, usa esa información. Si no, compara tamaño y fecha o descarga según configuración. El tercer paso es el permiso: la cuenta de escritura sube objetos, otra cuenta de lectura prueba restauración, y ninguna cuenta usada por una app diaria puede borrar versiones antiguas. PostgreSQL guarda el inventario de corridas: fecha, origen, destino, cantidad de archivos, bytes, resultado, hash cuando existe y responsable. Un tablero muestra fallas por carpeta. El backup del propio inventario se guarda fuera del servidor que ejecuta rclone. La prueba mínima restaura una carpeta en otra máquina, abre tres archivos y verifica que el servicio que los usa arranque.
Qué se instala o configura primero
La pila concreta: rclone v1.74.4, bucket S3 compatible, credenciales con permisos separados, archivo de filtros versionado, cron o systemd timer, log persistente y una tarea de restauración mensual. El primer entregable verificable es una corrida que copia 20 GB, excluye temporales, deja reporte y recupera una muestra en un directorio limpio. Con Backblaze B2 a USD 6,95 por TB mensual, un bucket de 1 TB cuesta cerca de $ 10.390 al dólar oficial vendedor de $ 1495. Si se suma un servidor chico para ejecutar tareas, monitoreo y alertas, la operación puede quedar entre USD 18 y USD 35 mensuales. Esa cuenta cubre infraestructura; ordenar carpetas, escribir filtros y documentar restauración requiere horas de trabajo. UMSA puede armar una prueba de dos semanas: inventario inicial, filtros, credenciales, carga al bucket, rclone check y restauración firmada por el área usuaria. La condición de salida es concreta: la cooperativa debe recuperar un archivo elegido por gerencia sin pedir acceso al técnico que configuró la tarea.
Dónde se rompe y cómo probarlo Primer riesgo: sync borra en destino lo que alguien borró por error en origen.
La señal aparece cuando baja la cantidad de archivos sin ticket asociado. La prueba ejecuta dry-run, guarda reporte y exige aprobación antes del primer sync destructivo. Segundo riesgo: el filtro deja afuera archivos necesarios. La señal aparece cuando una restauración trae datos, pero falta configuración, certificados o adjuntos. La prueba toma una aplicación real y la levanta desde la copia, no desde una lista de nombres. Tercer riesgo: credenciales con permiso de borrado amplio. La señal aparece cuando la misma llave copia, lista y elimina versiones. La prueba crea una cuenta de restauración sin permiso de escritura y una cuenta de carga sin permiso para borrar retención. Cuarto riesgo: confiar en el costo sin medir egreso. La señal aparece cuando la prueba de restauración descarga más datos de los previstos. La prueba registra bytes subidos, bytes bajados y tiempo de recuperación por carpeta. Un respaldo que no vuelve es un archivo remoto caro. La acción útil es elegir una carpeta, copiarla, verificarla y restaurarla antes de sumar todo el servidor.
Para seguir leyendo
Para avanzar
Ver también
Continuá hacia capacidades técnicas, sectores o notas relacionadas.