Recuperación de Datos de NAS Iomega StorCenter y LenovoEMC
Los dispositivos NAS Iomega StorCenter (ix2, ix4, ix12) y LenovoEMC px-series (px2, px4, px6, px12) siguen activos en miles de pequeñas empresas y hogares españoles. Cuando fallan —por corrupción de firmware, RAID degradado o discos defectuosos— la recuperación requiere conocer su arquitectura interna Linux/mdadm y sus particularidades de sistema de archivos ext3/ext4.
Historia y vigencia de los NAS Iomega y LenovoEMC
Iomega fue durante años sinónimo de almacenamiento extraíble: los discos Zip y los Jaz marcaron una época. Cuando la empresa amplió su catálogo hacia los NAS domésticos y PYME con la línea StorCenter, logró una cuota de mercado considerable en el segmento de entrada. En 2012, EMC adquirió Iomega y rebautizó los modelos más avanzados como LenovoEMC tras la asociación con Lenovo, manteniendo el firmware LifeLine OS en ambas familias.
Aunque la producción de estos dispositivos cesó hace años, la realidad en los talleres de recuperación de datos es que siguen apareciendo con frecuencia. La razón es simple: muchas pymes compraron un ix4 o un px4 en su momento, lo configuraron con RAID 1 o RAID 5 y lo olvidaron en un armario de comunicaciones. Cuando finalmente falla —porque un disco muere, porque el firmware se corrompe o porque el dispositivo simplemente no arranca tras un corte de luz— el cliente descubre que nadie recuerda la contraseña de administración y que los datos llevan años sin respaldo.
Modelos más frecuentes en recuperación
Los dispositivos que más vemos en nuestro laboratorio son:
- Iomega StorCenter ix2 — NAS de 2 bahías, muy extendido en hogares y microempresas. RAID 0, RAID 1 o JBOD. Usa un procesador ARM y un volumen Linux ext3 o ext4.
- Iomega StorCenter ix4-200d / ix4-300d — 4 bahías, orientado a PYME. Soporta RAID 0, 1, 5 y 10. El sistema operativo reside en una partición separada del disco de datos.
- Iomega StorCenter ix12-300r — Versión rackmount de 12 bahías. Más común en entornos de servidor. Configuraciones RAID 5 y RAID 6 habituales.
- LenovoEMC px2-300d — Equivalente al ix2 bajo la marca Lenovo. Mismo LifeLine OS, mismo esquema de particionado.
- LenovoEMC px4-300d / px4-400d — 4 bahías, versión actualizada del ix4 con mejor procesador y más RAM.
- LenovoEMC px6-300d — 6 bahías, para entornos que necesitan más capacidad sin llegar a los modelos de rack.
- LenovoEMC px12-400r — 12 bahías rackmount, sucesor del ix12.
Arquitectura interna: Linux, mdadm y LifeLine OS
Tanto los StorCenter como los LenovoEMC funcionan sobre un sistema operativo Linux embebido denominado LifeLine OS. El RAID se gestiona mediante mdadm, la herramienta estándar de Linux para software RAID. Esto tiene una implicación fundamental: los discos extraídos del NAS contienen información de RAID que un sistema Linux externo puede leer si se conoce la configuración correcta.
El esquema de particionado típico en un disco de StorCenter ix4 es:
- Partición 1 (~200 MB, ext3): sistema operativo LifeLine OS y firmware.
- Partición 2 (~200 MB, swap): área de intercambio.
- Partición 3 (~500 MB, ext3): configuración y base de datos del NAS.
- Partición 4 (resto del disco, ext4): datos de usuario, miembro del array mdadm.
El array mdadm se construye sobre las particiones 4 de todos los discos del NAS. Los metadatos mdadm (superbloque) almacenan información sobre el UUID del array, el nivel de RAID, el número de dispositivos y la posición de cada disco. Esta información es clave para reconstruir el array fuera del dispositivo.
Fallos más comunes y sus causas
El "sad face" — corrupción de firmware
El síntoma más característico de los StorCenter y LenovoEMC es la aparición de un icono de "cara triste" en la pantalla LCD frontal (en los modelos que la tienen) o el parpadeo continuado del LED de estado. Este error indica que el NAS no ha podido cargar correctamente el LifeLine OS desde la partición de sistema.
Las causas más habituales son:
- Actualización de firmware interrumpida (corte de luz durante el proceso).
- Corrupción del sistema de archivos ext3 en la partición de sistema.
- Fallo del disco que contiene la partición de sistema en configuraciones donde el OS reside solo en uno de los discos.
- Pérdida de configuración en la partición 3 (la base de datos del NAS).
Lo importante: el "sad face" no implica que los datos estén perdidos. En la mayoría de los casos, la partición de datos (partición 4) está intacta. El problema es que el dispositivo no arranca y no permite acceder a los archivos por ninguna interfaz.
Degradación del volumen RAID
Cuando uno o varios discos del NAS fallan, el array mdadm entra en estado degradado. En RAID 5 con un disco fallido o RAID 1 con uno de los dos discos muerto, los datos siguen siendo accesibles desde el NAS (si este sigue funcionando), pero cualquier fallo adicional antes de reemplazar el disco defectuoso puede provocar la pérdida total.
Vemos con frecuencia casos donde el usuario:
- Recibe el aviso de disco fallido, pero no actúa de inmediato.
- Semanas o meses después, un segundo disco falla.
- El array queda inaccesible y los datos son irrecuperables sin laboratorio.
Fallos de cabezal y sectores defectuosos
Los discos duros mecánicos dentro de un NAS sufren los mismos fallos físicos que cualquier disco: degradación de cabezales, sectores reasignados que se acumulan hasta bloquear la lectura, o fallo total del cabezal (click of death). En estos casos, la recuperación del NAS requiere primero recuperar los discos individuales mediante técnicas de laboratorio (sala limpia, trasplante de cabezales) antes de poder reconstruir el RAID.
Proceso de recuperación de datos en Iomega/LenovoEMC
El proceso que seguimos en nuestro laboratorio para estos dispositivos sigue estos pasos:
- Evaluación inicial: Inspección visual del dispositivo y los discos. Prueba de arranque controlado para determinar si el fallo es de firmware o de hardware.
- Imagen de discos: Creación de imágenes sector a sector de cada disco usando herramientas especializadas (ddrescue, PC-3000). Esto protege los originales de cualquier lectura adicional.
- Análisis del superbloque mdadm: Examen de los metadatos mdadm en cada imagen para determinar el UUID del array, el nivel de RAID y el orden de los discos.
- Reconstrucción del array: Ensamblado del array mdadm sobre las imágenes en un sistema Linux de recuperación. En RAID 5 con un disco faltante, es posible reconstruir con los discos restantes.
- Montaje del volumen ext4: Montaje de la partición de datos en modo solo lectura para verificar la integridad del sistema de archivos.
- Reparación del sistema de archivos si es necesario: Si el ext4 tiene el journal corrupto u otros problemas, se aplica fsck o técnicas manuales de reparación de superbloques.
- Extracción de datos: Copia de los archivos recuperados a un soporte limpio.
Compatibilidad de discos donante para reparación física
Cuando un disco del NAS necesita reparación física (trasplante de cabezales o PCB), encontrar el donante adecuado puede ser complicado. Los discos que Iomega y LenovoEMC usaban en sus dispositivos eran principalmente:
- Seagate Barracuda (series ST1000DL002, ST2000DL003) — los más comunes en modelos de 2 y 3 TB.
- Western Digital Green y Red (WD10EADS, WD20EARS, WD20EFRX) — habituales en los modelos de 1 y 2 TB.
- Hitachi Deskstar (HDS721010CLA332) — menos frecuentes pero presentes en algunas configuraciones.
Al ser discos de hace más de 10 años, el stock de donantes compatibles es limitado. Es imprescindible hacer coincidir familia, revisión de firmware, número de cabezas y número de sectores antes de intentar cualquier trasplante.
¿Qué pasa si el NAS no arranca pero los discos están bien?
Este es uno de los escenarios más frustrantes: el dispositivo da error, no es accesible por red, pero los discos están físicamente intactos. En este caso, la solución más directa es:
- Extraer los discos del NAS.
- Conectarlos a un sistema Linux mediante adaptadores SATA/USB o directamente por SATA.
- Usar
mdadm --examinepara leer los metadatos de cada disco. - Reconstruir el array en modo solo lectura con
mdadm --assemble --readonly. - Montar la partición ext4 y copiar los datos.
Sin embargo, este proceso requiere conocimientos avanzados de Linux y del esquema de particionado específico de estos dispositivos. Un error en el orden de los discos o en los parámetros del array puede hacer que el montaje falle o, en el peor caso, que se sobreescriban los metadatos mdadm. Nunca intente reconstruir el array con herramientas de escritura sin haber creado previamente imágenes de cada disco.
Tasas de éxito y plazos
En nuestra experiencia con los NAS Iomega StorCenter y LenovoEMC:
- Fallo de firmware sin daño físico en discos: tasa de éxito superior al 95%. Plazo habitual de 2-3 días laborables.
- RAID degradado (1 disco fallido en RAID 5): éxito dependiente del estado de los discos restantes. Si están en buen estado, superior al 90%. Plazo de 3-5 días.
- Dos discos fallidos simultáneamente (RAID 5): recuperación parcial posible mediante técnicas de reconstrucción de paridad. Tasa variable según el patrón de pérdida.
- Fallo físico de cabezal en disco: requiere sala limpia. Plazo de 4-12 días. Tasa de éxito del 70-85% según el modelo y el estado de las superficies magnéticas.
WhatsApp