Tecnología · GUÍA PRÁCTICA
¿Cómo verificar un remoto crypt de Rclone? Audita los hashes antes de confiar en --checksum
Que un comando termine bien no demuestra una verificación completa. Confirma la topología crypt y los hashes del backend, elige cryptcheck o comparación por descarga y registra todos los resultados. Los errores y objetos no compatibles quedan fuera del total verificado.
Una copia cifrada puede parecer sana mientras su comprobación se ha reducido a nombres, tamaños o solo parte de los objetos. El riesgo aumenta al tratar el origen en texto claro, la capa crypt y el almacenamiento subyacente como un único extremo, aunque exponen hashes distintos.
El comando dedicado cryptcheck lee el nonce del objeto de destino, cifra el archivo de origen con ese mismo nonce y compara el checksum del texto cifrado resultante con el que ofrece el backend subyacente. Cada objeto contado necesita un checksum realmente utilizable.
La comparación de integridad es de solo lectura: no sincroniza, copia, purga ni borra datos remotos. Una restauración de muestra es una operación separada y requiere una ruta aislada. Cada objeto incluido debe entrar una sola vez en una clase registrada; los errores de lectura o hash, checksums no compatibles, omisiones o diferencias de recuento sin explicar impiden afirmar una verificación completa.
1. Fija el alcance y dibuja las tres capas
Anota el origen en texto claro, el remoto crypt configurado y la ruta de almacenamiento que este envuelve. Registra la versión exacta de rclone, nombres de configuración, subrutas, filtros y si el origen es local u otro remoto. No reveles contraseñas, credenciales ofuscadas ni tokens.
Confirma la dirección antes de ejecutar. En `rclone cryptcheck source:path cryptedremote:path`, el segundo extremo debe ser el remoto crypt configurado, no su ruta de almacenamiento bruto subyacente. Comparar dos almacenes de texto cifrado bruto o dos vistas descifradas responde a otra pregunta y no puede sustituirse sin explicarlo.
Crea un inventario esperado desde el origen de referencia: cantidad de objetos, bytes totales, filtros y exclusiones conocidas. Ese denominador evita que un registro limpio oculte archivos que nunca entraron en la comprobación.
2. Demuestra que el backend cifrado ofrece el hash necesario
La referencia oficial de cryptcheck exige que el remoto subyacente del destino crypt admita algún checksum. Comprueba el backend y la clase de objeto; no supongas que tener una capa crypt implica disponer de un hash.
Usa inspección de capacidades y metadatos de solo lectura adecuada para la versión instalada y conserva la salida. Un checksum disponible en objetos pequeños no prueba la misma cobertura en cargas multiparte, fragmentadas u objetos especiales.
Si rclone informa que no pudo comprobar hashes, el backend no ofrece uno compatible o una clase carece de checksums, detén la declaración de aceptación cryptcheck para esos objetos. Registra el número exacto no compatible y elige otra vía.
3. Elige el método para la pregunta real
Usa cryptcheck si el origen de referencia es texto claro y el destino es un remoto crypt cuyo backend ofrece checksum. Con origen local, rclone puede cifrar y calcular el hash localmente tras leer el nonce de destino.
Si el origen es otro remoto, la referencia oficial advierte que puede ser necesario descargar todos los archivos de origen. Estima transferencia, costes de salida, tiempo y recursos locales antes de interpretar el comando como una comparación barata dentro del servidor.
El `rclone check` ordinario compara inventario y hashes comunes entre extremos normales sin modificar datos. `--download` compara los datos descargados cuando faltan hashes, entre otros casos, pero es otra vía que consume ancho de banda. Comparar solo tamaños aporta inventario, no prueba de integridad de bytes.
4. Ejecuta una muestra canary antes del alcance completo
Selecciona una muestra representativa con un archivo pequeño, uno grande, uno modificado sin cambiar de tamaño si puede prepararse fuera de producción y clases con posible comportamiento distinto de hash. Evita datos sensibles en archivos y rutas.
Ejecuta cryptcheck solo sobre ese conjunto fijo y guarda informes separados combined, match, differ, missing-on-source, missing-on-destination y error. Conserva también comando, horas de inicio y fin, versión y estado de salida.
Interpreta literalmente los símbolos combined: `=` es idéntico, `-` existe solo en destino, `+` solo en origen, `*` tiene contenido diferente y `!` indica error de lectura o hash. La exclamación no es una discrepancia de contenido y nunca cuenta como verificado.
5. Amplía el alcance sin debilitar la evidencia
Cuando la muestra confirme la vía de hash prevista, ejecuta el alcance completo con la misma dirección y los mismos filtros. Configura con prudencia la concurrencia de checkers para que límites, presión de memoria o restricciones del backend no oculten errores de cobertura.
Decide si `--one-way` corresponde a la pregunta de recuperación. Exige que los archivos de origen estén en destino y coincidan, pero omite deliberadamente los objetos adicionales solo en destino. Si importan datos cifrados antiguos o inesperados, no aceptes una comprobación unidireccional.
Conserva los informes como evidencia inmutable de la ejecución. Redirigir solo la salida estándar es insuficiente cuando advertencias y NOTICE contienen la prueba de hashes ausentes o de un método degradado.
6. Concilia el registro antes de decir «verificado»
Cuenta cada objeto de origen una sola vez: coincide, difiere, solo está en origen, está afectado por un error de lectura o hash, o queda sin verificar por hash no compatible o por haberse omitido. Explica las exclusiones documentadas. Los objetos solo en destino son otra rama; los informes solapados no deben duplicar un objeto.
Un resultado completo exige cero diferencias, cero ausencias inesperadas, cero errores de lectura o hash, cero objetos no compatibles y un denominador explicado. El estado de salida y el resumen son evidencia auxiliar; no sustituyen la clasificación de objetos.
Si las cantidades no concilian, identifica filtros, permisos fallidos, nombres inválidos, límites u objetos sin hash antes de reducir el alcance y repetir. Nunca pases un objeto no resuelto al total de coincidencias para mejorar el porcentaje.
Clase: coincide（`=`）. Significado: origen y destino cifrado verificados como idénticos. Tratamiento: cuenta como verificado.
Clase: diferente（`*`）. Significado: existe en ambos, pero el contenido verificado difiere. Tratamiento: fallo e investigación.
Clase: falta en destino（`+`）. Significado: existe en origen, sin objeto correspondiente en destino. Tratamiento: fallo de completitud del respaldo.
Clase: falta en origen（`-`）. Significado: objeto adicional en destino. Tratamiento: investigar salvo exclusión deliberada.
Clase: error de lectura/hash（`!`）. Significado: no se pudo leer o calcular el hash. Tratamiento: sin verificar; ejecución fallida.
Clase: checksum no compatible. Significado: el hash subyacente requerido no está disponible. Tratamiento: sin verificar; usar otro método.
7. Separa seguridad de transferencia y confianza en la restauración
El incidente comunitario de julio de 2026 muestra por qué deben conservarse pruebas separadas: un aviso de ausencia de hashes comunes hizo que una sincronización basada en checksum comparara solo tamaños. Una edición del mismo tamaño quedó obsoleta hasta que cryptcheck detectó la diferencia. Es una advertencia sobre esa topología, no una conclusión universal sobre todos los backends.
Cryptcheck demuestra equivalencia entre los bytes elegidos del origen y los objetos cifrados de destino en un momento. No demuestra que el origen sea la versión histórica deseada, que se recuperen las credenciales o que una restauración a nivel de aplicación funcione.
Como prueba separada, restaura una muestra en una ruta aislada, descífrala con la configuración prevista y valida los archivos visibles para la aplicación sin sobrescribir el origen. Registra por separado la cobertura cryptcheck y la evidencia de restauración.
8. Prepara un registro útil para soporte sin secretos
Conserva topología anonimizada, versión de rclone, tipos de backend, comando exacto de solo lectura, filtros, cantidades esperadas, cantidades por informe, objetos no compatibles, estado de salida y horas de ejecución. Indica si el origen era local o remoto y si se usó one-way.
Excluye contraseñas de configuración, tokens, identificadores de cuenta y nombres privados. Para compartir una reproducción, usa archivos de prueba generados y salida de configuración redactada.
Escala el problema cuando estén claras la dirección, capacidad de hash del backend, filtros, clases de objeto y denominador. Así los mantenedores pueden distinguir un defecto real, un checksum no disponible, un origen remoto costoso o un inventario incompleto.
Preguntas frecuentes
¿`rclone check` verifica hashes del texto claro de crypt? No por sí solo. La referencia oficial dirige a cryptcheck para comparar checksums de archivos cifrados. El check ordinario aporta señales de inventario y `--download` es otra comparación de contenido con coste de transferencia.
¿Cryptcheck descarga todos los archivos? Con origen local en texto claro puede leer y cifrar localmente tras obtener el nonce de destino. Otro remoto como origen puede requerir descargar todos sus archivos.
¿Qué significa `!` en combined? Un error al leer o calcular hashes de origen o destino. No es contenido diferente y queda sin verificar hasta resolver el error.
¿Basta `--one-way` para verificar un respaldo? Solo si la pregunta de aceptación excluye los objetos adicionales solo en destino. Exige que el origen exista y coincida allí, pero no informa de archivos extra de destino.
¿Un resumen exitoso demuestra la revisión de todos los bytes cifrados? Solo si el inventario esperado concilia con todas las clases y no hay checksums no compatibles, objetos omitidos ni errores de lectura o hash. Conserva un registro con denominador, no solo una línea de éxito.
