Insights / Artículos técnicos

Copias con restic en R2: de guardar datos a verificar su restauración

Supervise por separado la actualidad de las instantáneas, la integridad y la restauración, indicando qué recuperación de aplicaciones falta probar.

  • Cloudflare R2
  • restic
  • Backup
Copias con restic en R2: de guardar datos a verificar su restauración
Contenido
  1. Fijar el ID del snapshot y un objetivo de recuperación
  2. Definir origen y éxito
  3. Supervisar la actualidad
  4. Comprobar integridad y extracción
  5. Gestionar retención con restic
  6. Comprobaciones pendientes
  7. Actualización del 6 de octubre de 2026: bloqueos obsoletos y control de la concurrencia en las pruebas de restauración

Un trabajo terminado no demuestra que los datos necesarios puedan recuperarse. Este caso interno generalizado evalúa almacenamiento, integridad, restauración y recuperación del servicio por separado. No documenta una migración completada desde otro servicio.

Fijar el ID del snapshot y un objetivo de recuperación

Registre el ID y restaure los archivos necesarios en un destino vacío y aislado. Revise referencias y permisos de configuración, o cargue la base de datos en aislamiento. Anote el tiempo. Repita las mismas comprobaciones periódicamente para comparar actualidad y alcance recuperable.

restic:Restaurar en un destino aislado

Definir origen y éxito

El diseño usa cifrado y deduplicación de restic con la API compatible con S3 de R2. Revise las operaciones necesarias en la tabla de compatibilidad. Para bases de datos activas, diseñe una captura consistente mediante volcados o pausa de la aplicación cuando corresponda.

Supervisar la actualidad

Siga por separado la última instantánea correcta, retrasos, fallos y resultados de integridad/restauración. Iniciar un trabajo no es éxito; un aviso fallido tampoco es lo mismo que una copia fallida.

Comprobar integridad y extracción

restic check por defecto y las verificaciones que leen datos tienen alcances distintos. --read-data lee todos los datos; documente el alcance de pruebas parciales. Combine comprobaciones del repositorio, restauración en un lugar aislado y comparación de contenidos o hashes. Extraer archivos no verifica el arranque de aplicaciones.

Gestionar retención con restic

Seleccione instantáneas mediante su política y use forget, prune y check, revisando antes qué se conservará. Borrar objetos por antigüedad en R2 puede eliminar datos compartidos necesarios para instantáneas retenidas. Siga la documentación de retención; limpiar imágenes de distribución es otro caso.

Comprobaciones pendientes

Se realizaron operación periódica, supervisión/avisos, retención y extracción/integridad de datos seleccionados. Faltan validar de extremo a extremo el arranque de todas las aplicaciones, configuración y dependencias, y acceso a credenciales independientes. Tiempo de recuperación y pérdida aceptable requieren medición. No se afirma recuperación completa ni ahorro demostrado.

Verificar las pruebas por etapas, desde la actualidad del snapshot hasta la recuperación completa Recuperar datos no demuestra que también puedan recuperarse las aplicaciones o las credenciales.
  1. Snapshot correcto y actualidad Compruebe la hora del snapshot que terminó correctamente y su retraso respecto al calendario. Que el trabajo haya empezado no significa que haya tenido éxito.
  2. Integridad y restauración aislada Registre el alcance de la comprobación, ejecute restore --verify en otra ubicación y compare los archivos y hashes previstos antes de revisar la retención y prune.
  3. Recuperación completa El arranque de todas las aplicaciones, los datos dependientes y la recuperación de credenciales guardadas aparte siguen sin verificarse. El tiempo de recuperación y la pérdida de datos admisible no se han medido.

Actualización del 6 de octubre de 2026: bloqueos obsoletos y control de la concurrencia en las pruebas de restauración

En una mejora adicional, se comprueba la actividad de los procesos en el mismo host antes de ejecutar el desbloqueo normal de restic, que solo trata bloqueos obsoletos. No se usa la opción que elimina todos los bloqueos, incluidos los de operaciones activas. Para conflictos se emplean reintentos con un límite mediante –retry-lock; las pruebas de restauración y prune no reinician el proceso indefinidamente cuando fallan. Comprobar la actividad dentro de un host no demuestra que no exista una operación concurrente desde otro host.

Los datos se extraen con restore –verify a un directorio temporal aislado. Después de comprobar los archivos necesarios y su integridad, se registra la correspondencia entre la instantánea verificada y la configuración. Primero se confirma la restauración de los datos objetivo; después se revisa lo que debe conservarse antes de ejecutar prune. La vigencia de una copia se determina por una instantánea que realmente terminó con éxito, no por el inicio del proceso ni por sus reintentos.

La restauración comprobada de los datos objetivo sigue siendo distinta de la recuperación completa, que incluye iniciar todas las aplicaciones y recuperar sus credenciales. Para el tratamiento de las ventanas de mantenimiento y los fallos de recopilación, consulta también Supervisión e investigación de incidentes.