¿Cómo podemos estar seguros de que una instantánea de solo lectura no está dañada debido a una falla del disco?
¿La única forma es calcular las sumas de verificación una sobre otra y almacenarlas para un examen más detenido, o BTRFS se encarga de eso por sí solo?
Razón fundamental
Hago copias de seguridad de mis instantáneas con regularidad como prevención ante una posible falla del disco. Hace días no pude tomar btrfs send | btrfs receiveuna instantánea específica. Cuando lo eliminé, el resto de las operaciones transcurrieron con normalidad. Además, btrfs scrubdice que hay algunos errores que no se pueden corregir. Eso me hizo pensar que mis instantáneas en el disco principal podrían estar dañadas antes de hacer una copia de seguridad de ellas en el disco externo y, si no soy consciente de esto, terminaría con copias de seguridad ya dañadas en el disco externo.
Eso es lo que busco evitar que suceda. Quiero estar seguro de que si puedo hacer una copia de seguridad de una instantánea, no esté dañada.
Respuesta1
Hay dos respuestas posibles dependiendo de lo que quiera decir con "dañado por una falla del disco".
Si te refieres a una simple corrupción de datos en reposo
BTRFS maneja esto por sí mismo, de forma transparente para el usuario. Realiza sumas de verificación internamente, incluidos los datos de las instantáneas, y luego verifica las sumas de verificación a medida que lee cada bloque. Sin embargo, hay un par de excepciones a esto:
- Si el volumen está montado con las opciones
nodatasumonodatacow, no tendrá suma de verificación de bloques de datos. En la mayoría de los casos, no debería montar con estas opciones, por lo que esto no debería ser un problema. - Los archivos para los cuales
NOCOWse establece el atributo (Cen la salida dellsattrcomando) tampoco se verifican. No es probable que tenga ningún archivo realmente importante con este conjunto de atributos (los archivos de diario de systemd lo tienen configurado, pero eso es todo a menos que lo configure manualmente).
Si te refieres a la destrucción no trivial de datos en el volumen debido a la pérdida de demasiados dispositivos
No puede protegerse contra esto excepto teniendo otra copia de los datos en algún lugar. Básicamente, si ha perdido más dispositivos de los que pueden tolerar los perfiles de almacenamiento del volumen, sus datos desaparecerán y nada los recuperará excepto restaurarlos desde una copia de seguridad.
Respecto a tu caso específico
Los problemas de los que habla con el envío/recepción son probablemente un efecto secundario de esos errores incorregibles informados por Scrub. Cuando BTRFS no puede corregir un error de forma transparente (normalmente porque el bloque se almacena utilizando un perfil que no puede realizar la recuperación, como single o raid0), devuelve un error de E/S, lo que provocará que falle la operación de envío. Por lo tanto, no terminará con copias de seguridad ya corruptas si usa enviar/recibir (y, de hecho, tampoco lo hará con la mayoría de las otras herramientas; cualquier buen software de copia de seguridad arrojará un error si no puede leer un archivo). ).
En este caso, parece que los errores incorregibles están enteramente en datos exclusivos de las instantáneas o que no se están fotografiando. Puedes descubrir fácilmente (aunque no muy rápidamente) qué archivos tienen problemas montando el volumen de origen en algún lugar por sí solo y ejecutando el siguiente comando desde donde está montado:
find . -exec cat '{}' \; > /dev/null
Eso intentará leer todos los archivos del volumen y verá los errores de lectura en la consola, con el nombre del archivo en el mensaje de error. Esto es potencialmente muy lento, por lo que es posible que desees paralelizarlo si tienes un gran volumen.
Una vez que haya encontrado y tratado esos archivos, no debería tener más problemas. Si ve que estos problemas vuelven a ocurrir en un futuro próximo después de solucionarlos, debería considerar verificar su hardware, ya quealgoestá corrompiendo datos silenciosamente.