Recuperar Datos ZFS y RAIDZ [2026]
ZFS es el sistema de almacenamiento más avanzado que existe en entornos open source: gestiona integridad de datos mediante checksums por bloque, redundancia mediante vdevs RAIDZ y consistencia mediante copy-on-write atómico. TrueNAS, FreeNAS, Proxmox, OmniOS y servidores Solaris/illumos lo usan a diario para proteger terabytes críticos. Cuando un pool ZFS falla —ya sea por pérdida de demasiados discos en un vdev RAIDZ, por corrupción del MOS (Meta Object Set), por un zpool.cache obsoleto o por pérdida de la clave de cifrado ZFS nativo— los datos quedan completamente inaccesibles sin intervención especializada. En RecuperaTusDatos recuperamos pools ZFS y RAIDZ aunque el sistema no arranque, el pool no sea importable y los discos presenten sectores defectuosos.
Datos clave — Recuperación ZFS y RAIDZ
TrueNAS, FreeNAS, Proxmox, OmniOS, Solaris, illumos, ZFS on Linux
RAIDZ1 (1 paridad), RAIDZ2 (2 paridades), RAIDZ3 (3 paridades), mirrors ZFS
Desde 890€ (lógico); desde 1.200€ (mecánico + RAIDZ)
Gratuito y sin compromiso
5–20 días laborables
60–85 % según escenario
¿Qué es ZFS y por qué es diferente de cualquier otro sistema de archivos?
ZFS no es solo un sistema de archivos: es un gestor de volúmenes integrado, un sistema de archivos transaccional y un sistema de protección de integridad de datos, todo en uno. Fue creado por Sun Microsystems para Solaris 10 en 2005 y desde entonces se ha convertido en el estándar de facto para almacenamiento de alta integridad en entornos Unix y Linux. Sus tres pilares fundamentales lo distinguen de NTFS, EXT4 o Btrfs:
Copy-on-Write (CoW) transaccional
ZFS nunca sobrescribe datos en el lugar donde están. Cuando se modifica un bloque, ZFS escribe el nuevo contenido en un bloque libre, luego actualiza los punteros que apuntan a ese bloque y finalmente libera el bloque antiguo, todo dentro de una única transacción atómica. Esto significa que si el sistema se corta a mitad de una escritura, ZFS siempre puede revertir al último estado consistente conocido (el último uberblock válido), sin necesidad de herramientas de fsck. Esta propiedad también es la base de los snapshots de ZFS.
Checksums por cada bloque de datos
Cada bloque de datos y metadatos en ZFS lleva un checksum criptográfico (por defecto fletcher4 para datos y SHA-256 para metadatos). Cuando ZFS lee un bloque, verifica su checksum antes de devolverlo. Si el checksum no coincide —indicativo de corrupción silenciosa, un fenómeno muy común en discos con sectores que devuelven datos erróneos sin reportar error— ZFS lo detecta y, si hay redundancia disponible, recupera el bloque correcto desde la copia de paridad. Esta protección, llamada "silent data corruption detection", no existe en RAID hardware convencional, NTFS, EXT4 ni en la mayoría de sistemas de archivos.
Snapshots y clones atómicos
Un snapshot ZFS congela el estado del sistema de archivos en un instante determinado sin copiar ningún dato: simplemente preserva los punteros del árbol de bloques CoW actuales. Los snapshots son instantáneos (independientemente del volumen de datos), consumen espacio solo cuando los bloques originales se modifican, y pueden revertirse en segundos. En TrueNAS y FreeNAS, los snapshots automáticos periódicos son la primera línea de defensa ante pérdida de datos.
Arquitectura interna de un pool ZFS: zpools, vdevs y datasets
Entender la arquitectura de ZFS es imprescindible para comprender por qué su recuperación es diferente a la de cualquier otro RAID.
- zpool: El contenedor de más alto nivel. Un pool agrupa uno o varios vdevs y presenta un sistema de archivos montable al sistema operativo. El pool tiene su propio namespace de datasets.
- vdev (Virtual Device): La unidad de redundancia dentro del pool. Un vdev puede ser un disco único, un mirror (espejo de N discos) o un vdev RAIDZ. Los datos del pool se distribuyen (stripe) entre todos los vdevs disponibles.
- RAIDZ vdev: El equivalente ZFS al RAID 5/6/7. RAIDZ1 tolera un disco fallido, RAIDZ2 tolera dos y RAIDZ3 tolera tres. A diferencia del RAID 5 clásico, RAIDZ usa un stripe de anchura variable: el tamaño del stripe se adapta al tamaño de cada escritura, lo que elimina el problema del write-hole del RAID 5.
- MOS (Meta Object Set): El objeto raíz del pool, que contiene todos los metadatos del pool: la lista de vdevs, los datasets, las propiedades, el historial de transacciones y los uberblocks. Si el MOS se corrompe, el pool no es importable aunque todos los discos estén perfectos.
- Uberblock: El puntero raíz del árbol de transacciones ZFS. ZFS mantiene una lista circular de 128 uberblocks (uno por cada transacción exitosa). En caso de corrupción, se puede retroceder a un uberblock anterior para recuperar el estado del pool en un momento previo.
- zpool.cache: Un archivo en el sistema operativo host que guarda la configuración del pool (qué discos lo componen, sus identificadores). Si este archivo se pierde o queda obsoleto (p.ej. tras un cambio de hardware), el pool puede no importarse automáticamente, aunque siga siendo perfectamente válido en los discos.
RAIDZ1, RAIDZ2 y RAIDZ3: equivalentes a RAID 5, 6 y 7
RAIDZ1: un disco de paridad
RAIDZ1 es funcionalmente equivalente a RAID 5: distribuye datos y una paridad XOR entre todos los discos del vdev. Tolera el fallo de exactamente un disco. Necesita un mínimo de 3 discos (2 datos + 1 paridad). Si falla un segundo disco mientras el primero está fallido —ya sea durante la reconstrucción o antes de detectar el primer fallo— todos los datos del vdev quedan inaccesibles. Es el nivel de RAIDZ más común en TrueNAS doméstico y NAS de gama media.
RAIDZ2: dos discos de paridad
RAIDZ2 es el equivalente a RAID 6: utiliza dos paridades independientes (similar al esquema P+Q de Reed-Solomon del RAID 6, aunque con diferencias en la implementación de stripe variable). Tolera el fallo simultáneo de dos discos. Necesita un mínimo de 4 discos. Es el estándar para entornos empresariales con ZFS porque el RAIDZ1 en discos grandes tiene una ventana de vulnerabilidad durante la reconstrucción que puede superar las 24-48 horas.
RAIDZ3: tres discos de paridad
RAIDZ3 tolera el fallo de tres discos simultáneamente. Necesita un mínimo de 5 discos. Se usa en entornos donde la disponibilidad es crítica y donde los discos son muy grandes (20 TB o más), lo que hace que la ventana de reconstrucción sea tan larga que la probabilidad de un tercer fallo durante la reconstrucción sea estadísticamente significativa. Es el equivalente al mítico RAID 7, que no existe en la mayoría de implementaciones de RAID hardware.
ZFS en la práctica: TrueNAS, FreeNAS, Proxmox y Solaris
ZFS no es una tecnología de nicho. Está presente en algunos de los sistemas de almacenamiento más desplegados del mundo:
- TrueNAS CORE / TrueNAS SCALE: Los sucesores de FreeNAS. TrueNAS CORE está basado en FreeBSD y usa OpenZFS; TrueNAS SCALE está basado en Debian Linux. Son los NAS de software más populares para pymes y hogares avanzados, con millones de instalaciones.
- FreeNAS (versiones anteriores a TrueNAS 12): Aún en producción en miles de instalaciones. La recuperación de pools FreeNAS es idéntica a la de TrueNAS.
- Proxmox VE: El hipervisor de código abierto más popular para virtualización empresarial. Proxmox soporta ZFS como sistema de archivos del host y como almacenamiento de VMs y contenedores. Un pool ZFS que falla en un servidor Proxmox puede paralizar todas las VMs alojadas en él.
- Solaris / illumos / OmniOS: ZFS fue creado para Solaris y sigue siendo el sistema de archivos nativo de Oracle Solaris, illumos y OmniOS. Los servidores Sun/Oracle con ZFS son habituales en entornos bancarios y de telecomunicaciones.
- ZFS on Linux (OpenZFS): Disponible como módulo del kernel en cualquier distribución Linux. Usado frecuentemente en servidores de almacenamiento personalizado.
Escenarios de fallo en ZFS: los más frecuentes en laboratorio
1. Pool RAIDZ2 con tres discos fallidos simultáneamente
Este es el escenario más grave en RAIDZ2. Tres discos fallidos superan la capacidad de paridad del vdev (solo dos paridades) y el pool pasa a estado FAULTED. No es posible importarlo con zpool import. Sin embargo, no todos los bloques del pool están irrecuperables: los bloques cuyos stripes no incluyen ninguno de los tres discos fallidos siguen siendo accesibles. La recuperación consiste en reconstruir el array a nivel forense, identificar qué stripes son reconstruibles (aquellos que no involucran los tres discos fallidos simultáneamente) y extraer los datos que son accesibles. La tasa de éxito depende de la distribución estadística de los discos fallidos en los stripes y de si los discos tienen además sectores defectuosos.
2. Corrupción del MOS o del uberblock activo
El MOS (Meta Object Set) es el árbol de metadatos raíz del pool. Una corrupción de los bloques del MOS —por un fallo de firmware de disco, un corte de luz durante una escritura de metadatos o un error de hardware— puede dejar el pool en estado UNAVAIL aunque todos los discos físicos funcionen correctamente. La solución es localizar un uberblock anterior válido en la lista circular de 128 uberblocks que ZFS mantiene en cada disco del pool y usar esa instantánea de estado anterior para acceder al árbol de metadatos.
3. zpool.cache perdido o incorrecto
Cuando se reemplaza el sistema operativo host, se migra el servidor a otro hardware o se reinstala TrueNAS/Proxmox sin importar el pool, el archivo /etc/zfs/zpool.cache (Linux) o /boot/zfs/zpool.cache (FreeBSD) puede quedar obsoleto o desaparecer. El resultado es que el pool no se importa en el arranque y el sistema lo da por inexistente. En muchos casos, basta con buscar los discos manualmente con zpool import -d /dev/disk/by-id/ y el pool sigue intacto. En casos más complejos, cuando los identificadores de los discos han cambiado o la configuración del vdev está en el MOS degradado, la recuperación requiere análisis forense.
4. Disco extraído por error de un pool RAIDZ en modo degradado
Un RAIDZ1 en modo degradado (un disco fallido) opera al límite de su tolerancia de errores. Si en ese estado se extrae o se apaga incorrectamente un segundo disco —por confusión en el etiquetado de las bahías, o por mantenimiento de hardware mal planificado— el pool entra en estado FAULTED de inmediato. Esto es especialmente frecuente en TrueNAS cuando el administrador intenta "reemplazar" el disco fallido pero extrae el incorrecto. La recuperación requiere reconstruir la topología del vdev a partir del análisis de los tres discos disponibles.
5. Pool ZFS con cifrado nativo y clave perdida
ZFS 0.8+ (OpenZFS) y Solaris ZFS soportan cifrado nativo de datasets y pools. Si el administrador pierde la passphrase o el archivo de clave de cifrado y no existe una copia de seguridad de la clave, los datos son matemáticamente inaccesibles: el cifrado AES-256-GCM o AES-256-CCM utilizado no tiene vulnerabilidades conocidas explotables en tiempo razonable. En estos casos, la única vía es localizar la clave en backups del sistema, en gestores de contraseñas corporativos o en snapshots de máquinas virtuales que contengan la clave en la configuración del sistema operativo. Nunca intentes un ataque de fuerza bruta: es computacionalmente inviable con las claves que genera ZFS.
6. Fallo de vdev completo por discos con silent data corruption
ZFS detecta la corrupción silenciosa de datos (bits que cambian en el disco sin generar error de lectura SMART), pero cuando el nivel de corrupción supera la capacidad de corrección del vdev RAIDZ, el pool reporta errores de checksum masivos y puede marcar el vdev como DEGRADED o FAULTED. Un zpool scrub en un disco que ya está fallando mecánicamente puede empeorar la situación al forzar lecturas en sectores dañados. El proceso correcto es detener el scrub, clonar los discos con herramientas especializadas que gestionen errores de lectura (PC-3000, DeepSpar) y trabajar sobre las imágenes clonadas.
Lo que NO debes hacer cuando tu pool ZFS falla
La naturaleza técnica de ZFS lleva a muchos administradores a intentar soluciones que empeoran el problema. Estos son los errores más frecuentes y más costosos:
- No ejecutes
zpool scruben un pool con discos fallando mecánicamente. El scrub fuerza lecturas en todos los sectores del disco, acelerando la degradación de discos que ya están fallando. Primero clona el disco enfermo. - No exportes un pool degradado. Si el pool está en modo DEGRADED y el sistema lo tiene importado, mantenerlo importado en modo solo lectura es más seguro que exportarlo. Al exportar y volver a importar un pool degradado, ZFS puede rechazar la importación si detecta inconsistencias en el MOS.
- No intentes
zpool clearen un pool FAULTED con discos físicamente dañados. Este comando limpia los errores del pool y puede hacer que ZFS intente escribir en discos que no están en condiciones de recibir escrituras. - No reemplaces discos sin imagen forense previa. Al añadir un disco de reemplazo a un vdev degradado, ZFS inicia inmediatamente la resilvering (reconstrucción). Si el disco superviviente tiene sectores defectuosos que ZFS no puede leer, la resilvering falla y el pool queda FAULTED con el disco original ya retirado.
- No formatees ni reparticiones ningún disco del pool. Aunque el pool no sea importable, las estructuras de datos ZFS (labels del pool, uberblocks, MOS) siguen en los discos y son la base de la recuperación.
- No uses herramientas de recuperación genéricas (Recuva, PhotoRec, TestDisk). Estas herramientas no entienden la estructura de ZFS y no pueden reconstruir un pool a partir de sus bloques internos. Pueden además sobrescribir metadatos críticos si se les pide reparar el sistema de archivos.
Proceso de recuperación ZFS en RecuperaTusDatos
- Diagnóstico inicial sin cargo: Analizamos el estado del pool y los discos. Identificamos el tipo de vdev (RAIDZ1/2/3, mirror), el número de discos en fallo y la naturaleza del problema (lógico, físico, cifrado).
- Clonación forense de cada disco: Cada disco se clona sector a sector con PC-3000 o DeepSpar, gestionando automáticamente los sectores defectuosos y maximizando la lectura de datos. Nunca trabajamos sobre los discos originales.
- Análisis de labels ZFS y uberblocks: Localizamos los labels del pool (ZFS escribe 4 copias de los metadatos del pool distribuidas en los discos) y determinamos el último uberblock válido.
- Reconstrucción virtual del pool: Montamos el pool en un entorno de laboratorio usando las imágenes clonadas, sin los discos originales. Si el pool no importa directamente, construimos una imagen del pool recombinando los vdevs manualmente.
- Acceso al MOS y los datasets: Con el pool importado en modo solo lectura, accedemos al MOS para listar los datasets y verificar su integridad.
- Extracción y verificación de datos: Extraemos los archivos verificando checksum a checksum. Entregamos una lista de archivos recuperados antes del pago final.
Precios de recuperación de datos ZFS y RAIDZ
El coste de la recuperación depende fundamentalmente de dos factores: el tipo de fallo (lógico vs. físico) y el número de discos afectados.
- Fallo lógico puro (pool no importable, MOS corrompido, zpool.cache perdido, disco extraído por error): desde 600€ + IVA.
- RAIDZ con 1-2 discos con fallos físicos menores (sectores defectuosos, firmware): desde 1.200€ + IVA.
- RAIDZ2 con 3 discos fallidos o RAIDZ con fallos físicos graves (cabezales, motor): 2.000–5.000€ + IVA, con recuperación parcial.
- Pool cifrado con clave perdida: diagnóstico gratuito; precio según posibilidad de localizar la clave.
Diagnóstico siempre gratuito. Sin datos recuperados, sin coste. Presupuesto cerrado antes de comenzar el trabajo.
Preguntas frecuentes sobre recuperación de datos ZFS y RAIDZ
zpool import -d /dev/disk/by-id. Si el pool no aparece ni así, es posible que los labels del pool se hayan corrompido, lo cual sí requiere diagnóstico en laboratorio. En cualquier caso, no escribas nada en los discos del pool hasta haber contactado con nosotros.
WhatsApp