Recuperación de Datos de Sistemas Btrfs Dañados
Btrfs es el sistema de archivos de nueva generación de Linux, ampliamente adoptado por Synology, openSUSE y Fedora por sus capacidades de instantáneas y RAID integrado. Sin embargo, su arquitectura Copy-on-Write y su implementación de RAID 5/6 aún inmadura presentan modos de fallo únicos que requieren técnicas de recuperación especializadas muy diferentes a las de ext4 o XFS.
Arquitectura Copy-on-Write de Btrfs: ventajas y riesgos
La característica definitoria de Btrfs es su naturaleza Copy-on-Write (CoW). A diferencia de sistemas de archivos tradicionales que modifican los datos en su lugar, Btrfs escribe los datos modificados en nuevas ubicaciones del disco y solo actualiza los punteros del árbol de metadatos cuando la escritura es consistente. El bloque antiguo permanece hasta que el nuevo está confirmado.
Esta arquitectura proporciona consistencia garantizada: el sistema de archivos nunca queda en estado inconsistente tras un apagado brusco, porque las transacciones son atómicas. No hay necesidad de fsck tras un fallo de energía. También permite instantáneas (snapshots) atómicas e instantáneas: una snapshot de Btrfs es simplemente un subvolumen que apunta a los mismos árboles de datos que el volumen origen. No requiere copiar ningún dato en el momento de crearla. Además, cada bloque de datos y cada nodo de metadato lleva un checksum CRC32C (o SHA256/xxHash en versiones recientes), permitiendo detectar silenciosamente la corrupción y, en configuraciones RAID 1, auto-recuperar el bloque correcto desde la réplica.
Sin embargo, CoW tiene un coste: la fragmentación. En volúmenes con muchas escrituras pequeñas o muchas snapshots activas, los datos pueden quedar fragmentados en miles de extents pequeños. Cuando un árbol de Btrfs se corrompe, puede haber referencias circulares o punteros a bloques inexistentes que hacen que las herramientas de reparación entren en bucles.
Subvolumenes y snapshots: estructura interna
Btrfs organiza los datos en subvolumenes, cada uno con su propio árbol de ficheros (file tree). El superbloque de Btrfs apunta al árbol raíz (root tree), que contiene referencias a todos los subvolumenes y snapshots del sistema de archivos. Por encima existe el chunk tree, que mapea las direcciones lógicas del sistema de archivos a las direcciones físicas en disco.
La jerarquía de árboles críticos en Btrfs es la siguiente. El superbloque está localizado en offsets fijos (64 KB, 256 MB, 1 GB, etc.) en cada dispositivo y contiene la clave raíz del chunk tree. Btrfs mantiene múltiples copias del superbloque como protección. El chunk tree mapea direcciones lógicas a físicas; si este árbol se corrompe, el sistema de archivos completo se vuelve inaccesible. El root tree lista todos los subvolumenes y sus raíces de árbol; su corrupción hace inaccesibles todos o algunos subvolumenes. El extent tree rastrea qué bloques están en uso y puede causar que Btrfs libere espacio que aún contiene datos válidos si se corrompe. Los file trees, uno por subvolumen o snapshot, contienen el directorio y los inodes de los ficheros.
Perfiles RAID en Btrfs: RAID 0, 1, 5, 6 y 10
Btrfs implementa su propio RAID por software, independiente de mdadm. Los perfiles de RAID se aplican separadamente a datos y metadatos:
| Perfil | Redundancia | Discos mínimos | Estado de madurez |
|---|---|---|---|
| RAID 0 | Ninguna | 2 | Estable |
| RAID 1 | 1 copia extra | 2 | Estable |
| RAID 1C3 | 2 copias extra | 3 | Estable (kernel 5.5+) |
| RAID 10 | Mirror + stripe | 4 | Estable |
| RAID 5 | 1 disco de paridad | 3 | Inestable: bug write hole |
| RAID 6 | 2 discos de paridad | 4 | Inestable: bug write hole |
El bug write hole de Btrfs RAID 5/6: un riesgo real y documentado
El write hole (agujero de escritura) es un bug conocido y documentado en la implementación de RAID 5/6 de Btrfs, presente en el kernel de Linux desde su introducción y aún no completamente resuelto.
El problema ocurre así: cuando Btrfs escribe un stripe (franja) en un RAID 5/6, debe escribir los bloques de datos y el bloque de paridad en una operación atómica. Si el sistema se interrumpe (corte de luz, kernel panic, fallo de hardware) en mitad de esta escritura, algunos discos del stripe tendrán los datos nuevos y otros los datos viejos, pero la paridad ya no será coherente con ninguno de los dos estados. Al reiniciar, Btrfs no puede determinar qué bloques son correctos y cuáles no, lo que puede derivar en corrupción silenciosa de datos: los ficheros se leen sin error pero con contenido incorrecto.
La implicación práctica es clara: Btrfs RAID 5/6 no debe usarse como único nivel de protección de datos en producción. La propia documentación oficial del kernel Linux advierte sobre este problema. A pesar de ello, muchos NAS con Btrfs, incluidos algunos modelos de Synology y QNAP, ofrecen RAID 5/6 con Btrfs y los usuarios lo configuran sin conocer el riesgo.
Corrupción del chunk tree y del root tree
Los dos tipos de corrupción más devastadores en Btrfs son los que afectan al chunk tree o al root tree.
Cuando el chunk tree está dañado, el sistema no puede resolver ninguna dirección lógica a física. El volumen no puede montarse y la herramienta btrfs check reportará errores como failed to read chunk tree o bad chunk. La recuperación implica reconstruir el chunk tree escaneando el disco en busca de bloques Btrfs válidos y reconstruyendo el mapa lógico-físico manualmente. Es un proceso largo y especializado.
La corrupción del root tree puede causar que uno o varios subvolumenes sean inaccesibles mientras otros funcionan con normalidad. Es posible que los datos estén físicamente intactos pero que no haya ninguna ruta de árbol válida para llegar a ellos. La recuperación implica localizar los file trees huérfanos y extraer su contenido directamente sin pasar por el root tree dañado.
btrfs check --repair: cuándo ayuda y cuándo destruye
btrfs check --repair es la herramienta de reparación integrada, equivalente a fsck en otros sistemas de archivos. Sin embargo, la documentación oficial advierte explícitamente: no use --repair a menos que se lo indique un desarrollador o especialista. Las razones son sólidas.
En versiones del kernel y btrfs-progs anteriores a 5.x, --repair podía agravar la corrupción en lugar de repararla. La opción --init-extent-tree reconstruye el extent tree desde cero, pero en el proceso puede marcar como libres bloques que aún contienen datos válidos, causando sobreescritura en próximas operaciones de escritura. --clear-space-cache puede causar incoherencias si se usa en el estado equivocado del volumen.
La regla de oro es: antes de ejecutar cualquier operación de reparación, hay que hacer una imagen completa del disco. Trabajar siempre sobre la imagen, nunca sobre el original. Si btrfs check sin --repair reporta errores graves, el siguiente paso correcto es un laboratorio especializado, no intentar repararlo a ciegas.
Btrfs en Synology SHR y DSM
Synology adoptó Btrfs como sistema de archivos predeterminado a partir de DSM 6.0 en 2016. Sus NAS de gama media-alta (DS918+, DS1522+, RS1619xs+, etc.) usan Btrfs sobre su sistema de protección SHR (Synology Hybrid RAID), una implementación personalizada de mdadm con niveles RAID dinámicos que permiten discos de diferentes tamaños.
La arquitectura Synology SHR + Btrfs añade capas adicionales. SHR-1 y SHR-2 son gestionados por mdadm con superbloque v1.0, y Btrfs se monta sobre el dispositivo mdadm virtual. La recuperación requiere primero reconstruir el array mdadm correctamente, y luego abordar el volumen Btrfs.
Las snapshots de DSM (@GMT snapshots) son automáticamente creadas por Synology con programación configurable. Si el volumen está dañado pero las snapshots antiguas están intactas, es posible recuperar versiones previas de los datos a partir de ellas, incluso si el subvolumen activo está irrecuperable. Este es uno de los argumentos más sólidos para activar las snapshots automáticas en DSM.
Si el administrador activó el cifrado de volumen en DSM, el dispositivo Btrfs está cifrado con LUKS/dm-crypt. La clave de cifrado se almacena cifrada con la contraseña del volumen. Sin esta contraseña, la recuperación de datos es imposible incluso con los discos perfectamente íntegros.
Cuándo Btrfs puede recuperarse y cuándo no
Las posibilidades de recuperación en Btrfs dependen del tipo y alcance de la corrupción:
| Escenario | Posibilidad de recuperación |
|---|---|
| Volumen no montable por superbloque dañado, discos sanos | Alta. btrfs rescue superblock con copias de superbloque. |
| Subvolumen inaccesible, otros subvolúmenes OK | Media-alta. Extracción directa de file tree huérfano. |
| Chunk tree corrompido | Media. Reconstrucción manual compleja pero posible. |
| RAID 5/6 con write hole y fallo de disco | Media-baja. Riesgo de corrupción silenciosa en datos recuperados. |
| Synology DSM con snapshots previas activas | Alta. Recuperación desde snapshot anterior al fallo. |
| Volumen cifrado LUKS sin clave conocida | Nula. El cifrado es efectivo por diseño. |
| Formateado completo con nuevo sistema de archivos | Nula o muy baja. CoW reduce el espacio de búsqueda carving. |
La complejidad de Btrfs hace que sea uno de los sistemas de archivos donde más importa acudir a un laboratorio especializado en lugar de intentar la reparación por cuenta propia. Los errores de reparación en Btrfs pueden destruir definitivamente datos que de otro modo serían recuperables.
WhatsApp