Recuperación de storage: SAN, NAS y RAID

Enlaces relacionados

La recuperación de storage es el conjunto de procedimientos para restablecer el acceso a los datos cuando un pool ZFS, un volumen SAN/NAS o un arreglo RAID no monta, entra en estado degradado o presenta corrupción. En la práctica, comienza por detener la escritura en el equipo, preservar el estado actual y trabajar sobre copias — nunca sobre los discos originales.

Cuándo la recuperación es urgente

Algunas señales indican que el problema es de storage y no de la aplicación:

• el pool ZFS no importa o aparece como UNAVAIL/FAULTED;
• el volumen no monta tras un corte de energía, actualización o cambio de controladora;
• el RAID entra en DEGRADED y el cambio de disco no completa el rebuild;
• el sistema de archivos reporta corrupción, errores de E/S o pérdida de metadatos;
• el NAS responde en la red, pero los recursos compartidos desaparecen;
• se sospecha falla en más de un disco del mismo arreglo.

En cualquiera de estos casos, la primera medida es detener la operación y no reiniciar en modo de reparación automática. Rebuild, fsck y “reparar” sin diagnóstico pueden convertir un incidente recuperable en pérdida definitiva.

Qué hace Nyverra

El alcance es recuperar el acceso a los datos y devolver el entorno a un estado operativo documentado:

• Triaje remoto — logs, zpool status, smartctl, eventos de la controladora y topología del arreglo.
• Preservación — orientación para apagar el equipo y, cuando sea posible, clonar discos o el volumen antes de cualquier intervención.
• Análisis de la falla — separar falla lógica (metadatos, sistema de archivos, configuración) de falla física (disco, controladora, cableado, backplane).
• Reconstrucción controlada — importación del pool en solo lectura, montaje del volumen, reconstrucción de RAID o recuperación de archivos por prioridad.
• Validación — verificación de integridad, pruebas de lectura, copia a un destino íntegro y documentación de lo recuperado.

El trabajo se registra decisión por decisión y disco por disco. En entornos con datos sensibles (salud, financiero, jurídico), el manejo sigue el contrato y la LGPD.

Qué no está en el alcance

• La recuperación física de medios dañados (disco con ruido, plato rayado, PCB quemado) requiere sala limpia y laboratorio especializado. Nyverra hace el triaje y, cuando es necesario, deriva a un socio de recuperación física.
• Garantía de recuperación total. Ningún proveedor serio garantiza el 100% de los datos antes del diagnóstico. El compromiso es con el método, la preservación y la transparencia.
• Soporte de firmware propietario cerrado de storages antiguos sin documentación del fabricante. Estos casos se evalúan individualmente.

TrueNAS y ZFS: por qué el tratamiento es distinto

ZFS no es “un RAID con otro nombre”. El pool combina vdevs y la integridad depende de metadatos y checksums distribuidos. Un zpool import forzado, un cambio de versión o un zpool clear en el momento equivocado pueden agravar la falla.

• Los snapshots no son respaldo si están en el mismo pool: la falla del pool se los lleva.
• RAID-Z no sustituye al respaldo: protege contra falla de disco, no contra borrado, corrupción lógica o ransomware.
• La controladora importa: HBA en modo IT es el estándar para ZFS; el RAID de hardware oculta los discos y cambia la topología.
• Registrar el estado antes de actuar: zpool status -v, zdb, SMART y logs deben preservarse antes de cualquier intento.

SAN, NAS y DAS: diferencias que cambian el diagnóstico

RAID no es respaldo — y eso cambia la prioridad

Si el entorno aún no tiene una copia inmutable y probada, la recuperación resuelve el incidente actual, pero el próximo sigue expuesto.

Prevención: evitar el próximo incidente

• Monitorear SMART, zpool status, capacidad y latencia antes del límite.
• Probar la restauración periódicamente — un respaldo no probado es una hipótesis, no una garantía.
• Separar snapshot de respaldo y mantener al menos una copia inmutable/offline.
• Documentar topología, versiones y procedimiento de cambio de disco.
• Usar HBA en modo IT con ZFS y mantener firmware/homologación registrados.
• Definir RPO y RTO por sistema, no un número genérico para toda la empresa.