Recuperación de datos en ZFS: el sistema de archivos más robusto y sus fallos

ZFS (Zettabyte File System) nació en Sun Microsystems en 2001 con un objetivo ambicioso: eliminar la pérdida de datos silenciosa. Checksums SHA-256 por cada bloque, redundancia RAIDZ, snapshots atómicos, compresión transparente y auto-reparación lo convierten en el sistema de archivos de referencia para NAS empresariales. TrueNAS (antes FreeNAS) y los appliances de NetApp, Oracle y Delphix lo usan masivamente. Sin embargo, cuando ZFS falla — y falla — la recuperación puede ser extraordinariamente compleja. Este artículo analiza los escenarios de fallo más frecuentes y las opciones de recuperación disponibles.

Arquitectura ZFS: conceptos clave para entender los fallos

ZFS organiza el almacenamiento en pools (zpools). Cada pool contiene uno o más vdevs (virtual devices). Un vdev puede ser un disco individual, un mirror, un RAIDZ o incluso un archivo. El pool combina los vdevs sumando su capacidad y distribuyendo los datos.

• Dataset: unidad lógica dentro de un pool, equivalente a un sistema de archivos montable.
• Snapshot: imagen de solo lectura de un dataset en un momento concreto.
• ZIL (ZFS Intent Log): log de escrituras síncronas. Puede residir en el propio pool (en disco) o en un dispositivo separado (SLOG).
• L2ARC: caché de lectura de segundo nivel, habitualmente en SSD. No contiene datos únicos; si falla, solo se pierde rendimiento.
• vdev mirror: equivalente a RAID1. ZFS prefiere mirrors sobre RAIDZ para menor latencia de reconstrucción.

RAIDZ, RAIDZ2 y RAIDZ3: redundancia y límites

Una limitación poco conocida de RAIDZ: no soporta expansión del número de discos. Si el pool se queda sin espacio, no se puede añadir un disco al vdev RAIDZ existente (solo en ZFS clásico; OpenZFS 2.2+ añade RAIDZ expansion experimental). Esto obliga a crear un nuevo vdev o migrar datos.

Fallos de pool import: el error más frecuente

Cuando ZFS no puede importar un pool, el error típico es cannot import: one or more devices is currently unavailable. Las causas más frecuentes:

• Disco desconectado o fallo físico: si el vdev es RAIDZ1 y un disco falla, el pool queda degradado pero importable. Si falla un segundo disco antes de completar el resilver, el pool queda FAULTED.
• Disco reemplazado sin procedimiento correcto: conectar el disco de reemplazo sin ejecutar zpool replace puede confundir al pool sobre qué disco es el sustituto.
• Cambio de identidad de dispositivo: en Linux, los discos pueden cambiar de /dev/sda a /dev/sdb entre reinicios. ZFS usa GUIDs internos para identificar discos, pero errores en la capa de hardware pueden confundirlo.
• Pool creado en versión superior de ZFS: un pool de TrueNAS SCALE (OpenZFS) importado en FreeNAS antiguo puede no ser compatible.

Procedimiento de importación forzada

zpool import -f nombre_pool fuerza la importación ignorando que el pool fue exportado en otro sistema. zpool import -d /dev/disk/by-id/ especifica el directorio donde buscar los dispositivos. zpool import -F nombre_pool activa el modo de recuperación que puede revertir transacciones incompletas — usar con precaución.

Resilver fallido y reconstrucción de RAIDZ

El resilver es el proceso de reconstrucción de un vdev degradado cuando se inserta un disco de reemplazo. Es la operación más vulnerable de ZFS: durante el resilver, el array tolera un disco menos del límite máximo. Si durante el resilver de un RAIDZ2 falla un tercer disco, el pool queda irrecuperable.

Un resilver que se interrumpe por apagado brusco no pierde progreso en ZFS moderno — se reanuda desde el punto de interrupción. Sin embargo, un resilver que encuentra errores de lectura en los discos supervivientes puede completarse con bloques corruptos, lo que requiere verificación con scrub posterior.

Scrub y errores incorregibles

zpool scrub nombre_pool lee todos los bloques del pool verificando checksums. Si encuentra un checksum inválido y hay copia redundante, auto-corrige. Si no hay redundancia o los errores superan la capacidad de corrección, reporta uncorrectable errors. Estos errores aparecen en zpool status bajo la columna CKSUM y en zpool events con detalle de dispositivo y offset.

Errores incorregibles en datos indican corrupción permanente de esos bloques. La única recuperación posible es restaurar esos ficheros desde un snapshot o backup. Por eso los scrubs periódicos son fundamentales: permiten detectar y corregir corrupción antes de que los checkpoints expiren.

zpool history: forensia de operaciones

zpool history nombre_pool muestra todas las operaciones realizadas sobre el pool con marca de tiempo: creación, imports, exports, cambios de configuración, snapshots. Es invaluable en recuperación para entender qué ocurrió antes del fallo. Puede revelar si alguien ejecutó zpool destroy por error o si el pool fue importado en modo de recuperación previamente.

Escenarios específicos en TrueNAS y FreeNAS

Actualización de FreeNAS a TrueNAS CORE que falla a mitad

Si la actualización del sistema operativo falla y el boot environment queda corrupto, los pools de datos generalmente sobreviven intactos. TrueNAS usa boot environments de ZFS para el propio SO, separados de los pools de datos. En caso de fallo, se puede arrancar desde USB con la imagen antigua e importar el pool manualmente.

Pool con todos los discos offline tras reinicio

Frecuente tras fallos de alimentación o migraciones. Ejecutar zpool import -a intenta importar todos los pools detectables. Si los discos tienen nombres cambiados, zpool import -d /dev/ escanea todos los dispositivos en busca de vdevs ZFS.

Dataset cifrado con clave perdida

ZFS soporta cifrado nativo desde OpenZFS 0.8. Si la clave de cifrado (passphrase o keyfile) se pierde y no hay backup de la clave, los datos son irrecuperables — ni un laboratorio puede ayudar. La clave debe almacenarse en lugar separado al pool que cifra.

ZIL/SLOG: qué pasa si el dispositivo falla

El ZIL (ZFS Intent Log) registra escrituras síncronas pendientes de confirmar. Si reside en el pool principal (ZIL embebido), un fallo de disco que afecte al ZIL puede causar corrupción de las últimas escrituras síncronas. Si el ZIL está en un SLOG (dispositivo separado) y ese dispositivo falla de forma abrupta, las escrituras síncronas pendientes se pierden pero el pool sigue siendo consistente gracias al mecanismo CoW de ZFS. El SLOG no necesita ser redundante para seguridad de datos, aunque sí para rendimiento continuo.

L2ARC: recuperación y rendimiento

El L2ARC es puramente caché de lectura. Si el dispositivo L2ARC falla, ZFS elimina la caché y sirve los datos desde el pool principal con mayor latencia. No hay pérdida de datos. La recuperación de un L2ARC no requiere ninguna acción especial: se elimina el dispositivo del pool con zpool remove y el sistema continúa operando.

Precios de recuperación ZFS

Qué hacer ante un pool ZFS degradado o FAULTED

1. No ejecutar zpool scrub en un pool FAULTED con discos físicamente dañados. El scrub fuerza lectura intensiva y puede precipitar el fallo definitivo de discos debilitados.
2. Exportar el pool en cuanto se detecta degradación si no se tiene disco de reemplazo inmediato: zpool export nombre_pool. El pool exportado está en estado consistente.
3. Capturar zpool status y zpool events antes de cualquier intervención: zpool status -v nombre_pool > status.txt y zpool events -v > events.txt.
4. Imagen de discos individuales con ddrescue antes de cualquier intento de resilver o reconstrucción. Un resilver sobre un disco físicamente dañado puede agravar el daño.

Si el pool está en estado FAULTED o los intentos de importación fallan con errores de checksum, la intervención de un especialista es necesaria. En RecuperaTusDatos analizamos el estado del pool sin coste inicial. Solicitar diagnóstico gratuito para conocer las opciones antes de tomar decisiones irreversibles.

Te puede interesar

• › Recuperar Datos NAS Synology DiskStation [2026]
• › Recuperar Datos NAS QNAP [2026]
• › Recuperar Datos Netgear ReadyNAS [2026]
• › Recuperar Datos Buffalo LinkStation [2026]