Recuperación de Datos de Sistemas ZFS y TrueNAS
ZFS es uno de los sistemas de archivos más robustos del mundo, con autoprotección integrada mediante checksums, Copy-on-Write y redundancia avanzada. Sin embargo, cuando un pool ZFS falla —ya sea por pérdida de vdev, corrupción de metadatos o fallo de disco múltiple— la recuperación requiere conocimiento especializado que va mucho más allá del RAID convencional.
Qué hace especial a ZFS frente a otros sistemas de archivos
ZFS (Zettabyte File System) fue creado originalmente por Sun Microsystems para Solaris y hoy es el núcleo de sistemas NAS como TrueNAS Core (basado en FreeBSD) y TrueNAS Scale (basado en Debian Linux). A diferencia de ext4, NTFS o XFS, ZFS combina el volumen lógico, el sistema de archivos y la gestión de integridad en una sola capa.
Sus características diferenciales más relevantes para la recuperación de datos son:
- Copy-on-Write (CoW): ZFS nunca sobreescribe datos en su lugar. Cada escritura crea un nuevo bloque; el puntero del árbol de datos se actualiza atómicamente. Esto significa que en caso de corte de luz durante una escritura, el estado anterior permanece intacto.
- Checksums extremo a extremo: Cada bloque de datos y metadatos lleva un checksum (por defecto fletcher4 o sha256 para datos críticos). ZFS verifica la integridad en cada lectura y puede detectar bit rot silencioso.
- Snapshots eficientes: Los snapshots no copian datos; simplemente preservan los punteros CoW. Esto permite recuperar versiones anteriores de archivos sin coste de espacio inicial.
- Autorreparación (scrub): ZFS puede detectar y corregir errores automáticamente en configuraciones redundantes leyendo desde el vdev sano cuando detecta un checksum incorrecto.
Arquitectura de un pool ZFS: vdev, RAIDZ y mirrors
La unidad fundamental de almacenamiento en ZFS es el pool, que agrupa uno o más vdev (virtual devices). Entender la arquitectura de vdev es esencial para comprender qué ocurre cuando algo falla.
Tipos de vdev principales
- Stripe (sin redundancia): Un solo disco o varios en stripe. La pérdida de cualquier disco destruye el pool completo.
- Mirror vdev: Dos o más discos con copia exacta. Tolera la pérdida de todos los discos menos uno del vdev.
- RAIDZ1: Similar a RAID 5. Tolera 1 disco fallado por vdev. Requiere mínimo 3 discos.
- RAIDZ2: Similar a RAID 6. Tolera 2 discos fallados por vdev. Requiere mínimo 4 discos.
- RAIDZ3: Tolera 3 discos fallados por vdev. Requiere mínimo 5 discos.
- Special vdev / L2ARC / ZIL: Vdevs especiales para metadatos, caché y log de escritura. Si el ZIL (ZFS Intent Log) se pierde, pueden perderse escrituras recientes aunque los datos principales estén intactos.
Un pool puede combinar múltiples vdev. Por ejemplo, un TrueNAS con 12 discos puede configurarse como 2 x RAIDZ2 de 6 discos cada uno. En este caso, la pérdida de un vdev completo destruye el pool aunque el otro esté perfectamente sano, porque los datos están distribuidos (striped) entre ambos vdev.
Transacciones ZFS y el árbol Merkle de bloques
ZFS organiza los datos en un árbol de bloques tipo Merkle. En la raíz del árbol está el uberblock, que apunta a los metadatos del pool (MOS, Meta Object Set). Cada transacción incrementa el número de transacción (TXG, Transaction Group). El uberblock activo es el más reciente con checksum válido.
ZFS mantiene las últimas 128 copias del uberblock en un anillo circular dentro de cada vdev. Si el uberblock activo está corrupto, es posible retroceder a un TXG anterior leyendo el anillo, aunque esto supone pérdida de las escrituras más recientes.
Los metadatos del pool (DMU Object Set, DSL directory, ZAP objects) se replican automáticamente en todos los vdev para mayor resiliencia. Esta replicación es lo que hace que ZFS sea más resistente a la corrupción de metadatos que un sistema RAID clásico.
Cuándo falla ZFS: escenarios más frecuentes
A pesar de su robustez, ZFS no es inmune al fallo. Estos son los escenarios que encontramos con más frecuencia en recuperación:
1. Pool import failure: "cannot import pool"
El síntoma más común: tras reiniciar el NAS o reemplazar discos, ZFS no puede importar el pool. Los motivos más habituales:
- Pérdida de un vdev que supera la tolerancia de redundancia (p. ej., 3 discos fallados en RAIDZ2)
- Uberblock corrupto en todos los vdev simultáneamente (raro, pero ocurre en cortes de luz sin UPS)
- Cambio de controller SATA/SAS que altera el orden de discos y ZFS no encuentra la configuración
- Metadatos MOS dañados por escrituras parciales durante un fallo de alimentación
2. Missing vdev o disco degradado
Si un disco falla en un pool RAIDZ, el pool pasa a estado degraded. ZFS sigue funcionando pero sin margen de redundancia. Si falla un segundo disco antes de completar el resilver (reconstrucción), el pool puede pasar a faulted. Los resilver en pools grandes de RAIDZ2/RAIDZ3 pueden tardar días, aumentando el riesgo de un segundo fallo.
3. Corrupción de metadatos
Los metadatos ZFS (inodes, directorios ZAP, listas de bloques) pueden corromperse si el checksum falla y no hay copia de paridad suficiente. Esto puede provocar que ciertas rutas del sistema de archivos sean inaccesibles aunque los datos físicos estén intactos.
4. Eliminación accidental de datasets o snapshots
La destrucción de un dataset ZFS o de sus snapshots es permanente a nivel lógico. Sin embargo, a nivel físico los bloques no se sobrescriben inmediatamente. Con herramientas de análisis forense a nivel de bloques es posible recuperar parte del contenido si el pool no ha recibido muchas escrituras posteriores.
TrueNAS Core vs TrueNAS Scale: diferencias en recuperación
TrueNAS Core utiliza la implementación OpenZFS sobre FreeBSD. TrueNAS Scale utiliza OpenZFS sobre Debian Linux. Desde el punto de vista de recuperación, las diferencias más relevantes son:
| Aspecto | TrueNAS Core (FreeBSD) | TrueNAS Scale (Linux) |
|---|---|---|
| Versión OpenZFS | 2.x (desde CORE 13) | 2.x |
| Herramientas de rescate | FreeBSD live CD / FreeNAS rescue | Ubuntu live USB con zfsutils-linux |
| Import desde SO diferente | Posible desde Linux con precaución | Posible desde FreeBSD con precaución |
| ACLs | NFSv4 ACLs (diferente a POSIX) | POSIX o NFSv4 según configuración |
| Apps (containers) | Jails (iocage) | Kubernetes/Docker con datasets adicionales |
Un error habitual es intentar importar un pool TrueNAS Core en Linux sin tener en cuenta las diferencias de feature flags. Los pools con feature flags específicos de FreeBSD-OpenZFS pueden requerir herramientas especializadas para su importación en Linux.
ZFS send/receive para migración y recuperación
zfs send y zfs receive son las herramientas nativas para migrar o replicar datasets ZFS. En un escenario de recuperación, zfs send permite extraer el contenido de un pool degradado a un nuevo destino antes de que falle completamente, preservando snapshots y metadatos.
El proceso recomendado cuando el pool está en estado degraded:
- No realizar ningún scrub ni resilver adicional: puede aumentar la carga sobre discos ya comprometidos.
- Ejecutar
zfs send -R poolname/dataset@snapshot | zfs receivehacia almacenamiento temporal. - Priorizar los datasets más críticos (bases de datos, configuración) sobre archivos multimedia grandes.
- Verificar los checksums del destino antes de declarar la recuperación exitosa.
El proceso de recuperación profesional de datos en pools ZFS
Cuando el pool no puede importarse ni siquiera en modo degraded, la recuperación requiere análisis a nivel de bloques físicos. Nuestro proceso incluye:
- Clonado forense de todos los discos: Se crean imágenes sector a sector de cada disco antes de cualquier operación, preservando el estado original.
- Análisis del anillo de uberblocks: Se identifican los TXG válidos más recientes y se intenta importar el pool con el TXG más antiguo conocido bueno.
- Reconstrucción manual del MOS: En casos graves, se reconstruyen manualmente las estructuras de metadatos del pool para permitir el acceso al árbol de datos.
- Extracción directa de bloques: Si el pool no puede importarse, se localizan y extraen los bloques de datos directamente desde las imágenes de disco.
- Verificación de integridad: Todos los archivos recuperados se verifican contra los checksums originales almacenados por ZFS.
Por qué ZFS es autoprotector pero no invulnerable
ZFS protege contra bit rot, escrituras parciales y fallo de un número limitado de discos. Pero no protege contra:
- Ransomware: Si el sistema operativo tiene acceso al pool, el ransomware también lo tiene. Los snapshots ZFS pueden preservar versiones anteriores si el atacante no los elimina.
- Fallo simultáneo de más discos que la tolerancia del vdev: Un incendio, inundación o fallo del backplane puede destruir múltiples discos a la vez.
- Error humano:
zpool destroyozfs destroy -rejecutados por error son instantáneos e irreversibles a nivel lógico. - Fallo del ZIL SSD: Si el log de escritura (ZIL) está en un SSD separado que falla, las últimas escrituras no confirmadas se pierden.
- Corrupción del uberblock por firmware defectuoso: Ciertos modelos de disco SAS/SATA con firmware problemático pueden escribir datos incorrectos en sectores críticos del pool.
La mejor protección complementaria a ZFS es una política de backup 3-2-1 con al menos una copia offsite, independientemente de la redundancia del pool.
WhatsApp