¿Btrfs es adecuado como sistema de archivos de respaldo?

En este momento tengo una estructura de sistema de archivos de respaldo bastante tradicional además de ext4. Cada vez que se realiza una copia de seguridad, backup-DATEse crea una nueva carpeta en la que se rsync'archivos (con enlaces duros realizados utilizando la --link-destopción rsync ).

Como he leído sobre bitrot, me gustaría tener una suma de comprobación para todos los archivos, de forma transparente. Aparentemente, ext4 no puede hacer eso, pero btrfs ofrece soporte para sumas de verificación de datos (e incluso un modo RAID1 incorporado). Para empezar, me gustaría usarlo btrfscomo un sistema de archivos "tonto" que admite sumas de verificación de datos sin usar sus funciones avanzadas como RAID, instantáneas de subvolumen, envío / recepción, etc.

Sin embargo, su wiki realmente no inspira confianza en el sistema de archivos para fines de copias de seguridad:

"Si bien muchas personas lo usan de manera confiable, todavía se encuentran problemas. Debe mantener y probar las copias de seguridad de sus datos y estar preparado para usarlos". - Comenzando

"¿Es estable btrfs? Respuesta larga: [..] Hagas lo que hagas, te recomendamos mantener copias de seguridad buenas, probadas, fuera del sistema (y fuera del sitio)". - FAQ .

Mi caso de uso es tener una copia de seguridad fuera de línea. Por esa razón, el disco verá muy poco uso (como en horas) y se conectará / desconectará con frecuencia (eSATA o USB 3.0). Tener un sistema de archivos confiable es imprescindible. No debe ser peor que ext4 wrt. fallas de energía, paradas sucias, etc.

¿Se recomienda realmente usar btrfs como sistema de archivos para fines de copia de seguridad? ¿Hay otras propiedades de btrfs que puedan hacer que sea menos (o más) adecuado?

Solo daré una respuesta breve porque creo que esto se está pensando demasiado.

Si lee la wiki principal del núcleo sobre los comandos btrfs (sub-) , encontrará que hay dos comandos para:

1. haciendo una "copia de seguridad" :btrfs-send
2. y restaurar :btrfs-restore

Por si acaso, esto significa que no es (diseñado para ser) una copia de seguridad, sino un sistema de archivos de instantáneas, con la idea de retroceder si es necesario, no como una copia de seguridad sino como "flexible".

Por lo tanto, no, no lo use como copia de seguridad, úselo como un sistema de archivos versionado donde pueda probar cosas y volver. No confíes en eso.

Recientemente tuve problemas con un sistema de archivos btrfs en un kernel actualizado 4.10.0. El sistema de archivos se destruyó en una máquina virtual virtualbox porque TRIM no parece implementarse correctamente en alguna parte, y AFAIK tenía algo que ver con los números de índice de subvolúmenes. Después de cambiar a VMware, el sistema de archivos todavía estaba dañado y, sorprendentemente btrfs check, no pudo encontrar y corregir el error. Finalmente volví a ext4.

Lo bueno: no perdí datos. btrfs parece ser siempre consistente al menos para la lectura, pero me mostró que todavía está muy lejos de la preparación para la producción.

De todos modos, en un servidor todavía lo estoy usando como volumen de respaldo porque allí necesito la función de copia de vaca para la deduplicación (exactamente su caso de uso). Los datos son demasiado grandes para un sistema de archivos tradicional.

Actualizar

Todavía tengo el sistema de archivos en mi servidor (ver arriba), pero se rompió justo después de publicar esto aquí. Ahora, tengo un gran volumen de copia de seguridad de solo lectura de 700G que se expandiría a ~ 7TB en ext4 si trato de copiar todo usando tar|tar. Debido a la falta de tiempo, aún no he verificado si las versiones más recientes del kernel pueden manejarlo. El problema real es un "aborto de transacción" que ocurre ~ 2 segundos después del montaje de escritura y que vuelve a montar el volumen de solo lectura. La causa original es probablemente una versión rota de btrfs-convert, que utilicé hace años cuando creé este volumen, y todavía un conjunto limitado de características de la corriente btrfs checkque al menos debería ser capaz de encontrar todos los daños en un volumen que conducen a una transacción anulada o cualquier otro problema, en lugar de decir que mi sistema de archivos está en buen estado.