restic check por tandas: cómo verificar una copia grande sin leerla entera

2026-10-18

En la prueba de restauración vimos que restic check a secas no detecta un fichero de datos dañado; solo --read-data lo hace, y lee la copia entera. En una nube eso significa descargar todo el repositorio. La alternativa es verificar una parte cada vez. Restic ofrece dos formas y se comportan de manera muy distinta. Esta es la prueba.

Condiciones: restic 0.16.4, repositorio local con 60 ficheros aleatorios de 2 MiB (120 MiB, 9 ficheros de datos o "packs"), contraseña desechable. Con tan poco volumen los tiempos (unos 0,7 a 1 s por ejecución) son casi todo arranque; no sirven para estimar cuánto tardará tu copia. Lo que sí vale es qué tanda detecta el daño. El script está en tools/test-restic-check-subset.sh.

Daño provocado

Con la copia sana, restic check y restic check --read-data terminaron con no errors were found. Después se alteró un byte de uno de los 9 packs, y se ejecutaron las dos variantes.

Tandas n/t: recorren todo, una vez

--read-data-subset=n/t divide los packs en t grupos fijos y lee el grupo n. Con t = 10 y 9 packs, los grupos 1 a 10 leyeron 0, 1, 1, 1, 1, 2, 0, 2, 1 y 0 packs: 9 en total, ninguno repetido. El daño apareció en la tanda 8/10 (Fatal: repository contains errors) y en ninguna otra. Si ejecutas una tanda distinta cada semana o cada mes, en t ejecuciones has leído todo el repositorio y el daño sale seguro.

Con repositorios pequeños algunos grupos quedan vacíos (0 packs), como pasó con 1/10, 7/10 y 10/10. No es un fallo; en un repositorio real con miles de packs los grupos salen parejos.

Porcentaje: al azar, sin memoria

--read-data-subset=10% elige un 10 % de packs al azar en cada ejecución. Se ejecutó tres veces sobre la copia dañada: leyó 1 de 9 packs cada vez y las tres dijeron no errors were found. El daño sigue ahí, simplemente no tocó ese pack. Cada ejecución tiene aproximadamente un 10 % de probabilidad de leer un pack concreto, así que repetirlo solo da una probabilidad de cubrirlo, no una garantía: un fichero dañado puede pasar muchos meses sin ser leído.

Qué hacer

• Calendario fijo con tandas: cada mes ejecuta la tanda n/12 con n igual al número del mes (--read-data-subset=10/12 en octubre). En un año has leído toda la copia. No se probó 12 como divisor; la prueba usó 10.
• Evita el porcentaje como única defensa si quieres garantía de cobertura.
• Un check que falla solo te avisa: para que el aviso sirva debes tener la copia 3-2-1 de la que hablamos en la regla 3-2-1 con restic y retención suficiente para volver a una versión anterior sana.
• Este artículo no probó cómo repara restic un pack dañado (restic repair packs), ni el coste real de descarga en cada proveedor: consulta qué cuesta cada nube por TB antes de planificar lecturas completas.

Este artículo no contiene enlaces de afiliado.