Fallos en RAID: síntomas, causas y cómo evitar perder tus datos

Informatec Digital » Recursos » Fallos en RAID: síntomas, causas y cómo evitar perder tus datos

Los sistemas RAID se han convertido en el pan de cada día en servidores, NAS y cabinas de almacenamiento porque prometen más rendimiento y tolerancia a fallos. Pero, aunque dan mucha tranquilidad, no son ningún escudo mágico: una avería mal gestionada puede acabar en desastre y dejarte sin datos en cuestión de minutos.

Cuando un RAID empieza a dar síntomas raros, la clave no es ser el más rápido en tocar cosas, sino el más prudente. Detectar las señales de fallo y saber qué NO hacer marca la diferencia entre un simple cambio de disco y una pérdida total e irrecuperable de la información, incluso para un laboratorio profesional.

Qué es un fallo en RAID y por qué no es lo mismo que un backup

Un RAID (Redundant Array of Independent Disks) agrupa varios discos para ofrecer mayor disponibilidad, rendimiento y/o redundancia, según el nivel que se utilice. Desde el clásico RAID 1 en espejo hasta configuraciones más complejas como RAID 5, RAID 6 o RAID 10, la idea es que el sistema siga funcionando aunque falle uno (o más) discos físicos.

El problema es que mucha gente asume que “tengo RAID, así que tengo copia de seguridad”, y eso es un error de base. RAID no sustituye a las copias de seguridad: protege frente a la caída de uno o varios discos (según el nivel), pero no evita la corrupción lógica, los errores humanos, el ransomware, las borradas accidentales, ni los fallos del controlador o del servidor completo.

Además, la forma en que el controlador —incluido el firmware del controlador— reparte los datos (orden de discos, tamaño de banda, algoritmos de paridad, metadatos, etc.) hace que cualquier manipulación incorrecta del array pueda romper la estructura y volver enormemente complicada la recuperación, incluso cuando los discos “parecen” estar bien.

Principales niveles RAID y su impacto en la recuperación

Cada nivel RAID tiene un comportamiento distinto ante los fallos y eso condiciona mucho las opciones de recuperación de datos. Entender estas diferencias ayuda a no tomar decisiones peligrosas cuando algo se rompe.

En un RAID 0 los datos se “rayan” (stripe) entre varios discos sin ninguna paridad ni espejo. No hay redundancia de ningún tipo: si un solo disco se muere o se degrada lo suficiente, la pérdida lógica es total, porque falta una parte imprescindible de cada fichero. Aquí hablar de “reconstrucción” tiene poco sentido; la prioridad es intentar extraer lo que se pueda de los discos físicamente dañados.

En un RAID 1 los discos son espejos: cada unidad contiene una copia completa de los datos. Es una configuración que suele ser bastante agradecida a la hora de recuperar, siempre que no se cometan errores de manipulación (por ejemplo, inicializar uno de los discos en un sistema distinto o mezclarlos en controladoras incompatibles).

Con RAID 5 se reparte la data en varias unidades y se calcula una paridad distribuida, lo que permite soportar el fallo de un disco. El problema viene cuando un segundo disco empieza a dar problemas durante la reconstrucción: la carga de trabajo se dispara, aparecen errores de lectura y el array puede venirse abajo sin previo aviso.

RAID 6 funciona de forma parecida a RAID 5 pero añade una segunda paridad, permitiendo tolerar la caída de hasta dos discos. A cambio, la estructura es más compleja, las reconstrucciones son más largas y cualquier error lógico o de configuración complica aún más las labores de recuperación.

En RAID 10 se combinan espejos y stripes: se “rayen” parejas de discos que están en espejo. A nivel de recuperación, el orden de los discos y la relación entre espejos y stripes es crítico; mezclar posiciones o reconstruir a ciegas puede desbaratar el conjunto incluso aunque todos los discos estén físicamente sanos.

Señales claras de que tu RAID está empezando a fallar

Antes de que el sistema se caiga del todo, suele dejar una serie de pistas. Aprender a reconocerlas te permite parar a tiempo y evitar que el daño vaya a más.

Una de las más evidentes son los ruidos extraños en los discos: clics repetitivos, crujidos, zumbidos intermitentes o sonidos metálicos que antes no estaban. Estos ruidos suelen indicar fallos mecánicos en los cabezales o en los platos, o problemas en el motor. Si los ignoras y sigues forzando lecturas, lo normal es que el estado de la unidad empeore muy rápido.

Otra señal típica son los avisos de “Degraded”, “Failed” o “Critical” en la consola de administración del NAS o del controlador RAID. Ese mensaje significa que uno o más discos han sido marcados como problemáticos y que el array está funcionando sin la redundancia prevista. En ese punto, sobre todo en RAID 5, un segundo fallo puede ser la puntilla.

También hay que prestar atención a los síntomas menos ruidosos pero igual de peligrosos, como un descenso brusco e inexplicable del rendimiento. Si los tiempos de lectura y escritura se disparan, especialmente al acceder a ciertos volúmenes o carpetas, puede que el controlador esté peleándose con sectores difíciles de leer o reintentos continuos que saturan el sistema.

En los logs del sistema o del propio controlador suelen aparecer errores de I/O, mensajes de paridad incorrecta, “Unrecoverable Read Error”, “Parity Check Failed” o “Bad Stripe Detected”. Un aumento sostenido de errores de lectura/escritura, incluso si el sistema aún funciona, es una luz roja que no conviene ignorar.

Otra pista peligrosa es que el volumen aparezca como degradado aunque aparentemente ningún disco haya caído del todo. Esto suele indicar corrupción lógica en los metadatos RAID o en los bloques distribuidos, y si se fuerza una reconstrucción automática en ese estado se puede propagar la corrupción a todo el array.

Síntomas de corrupción lógica y problemas silenciosos en RAID

No todos los fallos de RAID implican un disco “muerto” al instante. Muchas veces el problema es una corrupción progresiva de datos que se va colando de forma silenciosa hasta que la situación es ya muy complicada de revertir.

Un caso típico son los archivos que aparentemente están ahí, pesan lo que deben y tienen el nombre correcto, pero no se abren, dan errores de formato o aparecen truncados. Bases de datos que no montan, máquinas virtuales que no arrancan o imágenes que el visor rechaza suelen ser indicador de inconsistencias en los bloques repartidos entre discos.

También es habitual que el sistema operativo o las aplicaciones muestren una lentitud muy localizada en ciertos volúmenes RAID mientras la CPU y la RAM no parecen especialmente cargadas. Si la penalización se concentra en operaciones de lectura/escritura sobre el mismo volumen, tienes muchas papeletas de estar ante corrupción o sectores inestables.

Otro síntoma peligroso son las reconstrucciones que se inician tras cambiar un disco y se paran siempre en el mismo punto, lanzan errores extraños o directamente marcan el proceso como fallido. Esto suele indicar que los bloques de origen ya están corruptos y el controlador es incapaz de generar una copia coherente en el nuevo disco.

A veces solo uno de los discos muestra alertas SMART (sectores reasignados, tiempos de acceso elevados, etc.), pero el comportamiento raro se nota en todo el conjunto RAID. En esos casos, un solo disco con sectores problemáticos puede comprometer la consistencia de la matriz completa, sobre todo cuando se inicia una verificación de paridad o una reconstrucción.

Ignorar estas señales y seguir operando con normalidad, o peor aún, forzar tareas intensivas como verificaciones, copias masivas o reconstrucciones automáticas, puede propagar la corrupción e ir sobrescribiendo bloques válidos con datos dañados. A partir de ese punto, ni siquiera las herramientas profesionales podrán garantizar una recuperación completa.

Fallos típicos en controladores, servidores y placas base

No todo se reduce a los discos. El controlador RAID, la placa base o incluso el servidor completo pueden convertirse en el eslabón débil de la cadena y provocar fallos en la matriz aunque los discos estén sanos.

El controlador RAID, ya sea hardware dedicado o integrado en placa, es el encargado de decidir dónde se escribe cada bloque, cómo se calcula la paridad y cómo se ensamblan los volúmenes. Una avería, un firmware corrupto o un pico de tensión pueden dejarlo fuera de juego y provocar que el array desaparezca o se muestre como “Foreign”, “Offline” o similar.

En el caso de controladoras hardware dedicadas, hay un problema añadido: la falta casi total de compatibilidad entre modelos y fabricantes. Si se rompe una controladora Supermicro concreta, por ejemplo, no basta con poner “otra parecida”: muchas veces hace falta exactamente el mismo modelo, con una versión de firmware similar, para que lea bien los metadatos del RAID.

Con las soluciones integradas en placa (los llamados “fake RAID”), como algunos RAID por software de chipset AMD o Intel, el riesgo es que una sustitución de placa base, un reset de BIOS o la pérdida de configuración CMOS deje la matriz en el limbo. En muchos equipos de sobremesa y estaciones de trabajo, un fallo de placa o de la batería de CMOS puede llevarse por delante la configuración RAID y dejar los discos como unidades sueltas.

Además, el propio servidor (fuente de alimentación, memoria, placa, backplane, etc.) puede fallar por problemas eléctricos, sobrecalentamientos o defectos de hardware. En buena parte de estos casos, el resultado práctico es que el RAID se queda inaccesible, aunque en realidad los discos, conectados a otro sistema con la estrategia adecuada, podrían recuperar sus datos.

Por si fuera poco, en cada reinicio o arranque el sistema debe “reensamblar” el array RAID. Si durante ese proceso hay cortes de energía, picos de tensión o errores en los ficheros de configuración (como mdadm.conf en Linux), el sistema puede montar mal el conjunto, dejarlo a medias o directamente no reconocerlo, quedando el volumen fuera de servicio.

Causas frecuentes de pérdida de datos en matrices RAID

Si juntamos todo lo anterior, se ve que las matrices RAID, aunque muy útiles, siguen estando expuestas a bastantes riesgos. Las principales causas reales de pérdida de datos en estos entornos suelen ser una mezcla de factores físicos, lógicos y humanos.

La más evidente es el fallo de uno o varios discos por desgaste, defectos de fábrica, vibraciones, temperatura o golpes. Aunque RAID está pensado para soportar algunas de estas situaciones, no siempre lo consigue sin daños colaterales: un disco que empieza a devolver sectores corruptos puede arrastrar a su vecino, sobre todo durante procesos de verificación o reconstrucción.

Otro foco clásico de problemas es el error de ensamblaje o reconstrucción. Si el sistema monta el array con parámetros incorrectos, discos en orden erróneo, niveles RAID distintos a los originales o tras una migración fallida, es fácil que la información quede desalineada. A nivel práctico, el volumen puede aparecer como RAW, pedir formateo o mostrar estructuras de ficheros incoherentes.

Los fallos del servidor (placa base, firmware, backplane, controladora SAS/SATA, etc.) también tienen mucho peso. En un porcentaje muy alto de incidentes, cuando el servidor muere de forma brusca, la matriz RAID queda inaccesible y los datos no son visibles para el sistema, aunque sigan existiendo físicamente en los discos.

A todo esto hay que sumarle los factores humanos: cambios de configuración sin documentación, reordenar discos “para probar”, actualizaciones de BIOS sin copia previa de la configuración, borrar volúmenes por error, reinstalar el sistema operativo sobre discos que formaban parte del array, o restaurar copias de seguridad corruptas o incompletas en el mismo RAID dañado.

Finalmente, hay amenazas externas como el ransomware, que puede cifrar tanto los datos como las propias estructuras de los volúmenes alojados en arrays RAID. En esos escenarios, el trabajo de recuperación se complica doblemente: primero hay que lidiar con el cifrado y después con la posible corrupción interna del propio RAID.

Lo que NO debes hacer cuando tu RAID empieza a fallar

Cuando un servidor cae en fin de semana y todo el mundo está nervioso, lo más habitual es que alguien intente arreglarlo “sobre la marcha”. Es comprensible, pero muchas de estas reacciones bien intencionadas son justo lo que termina de rematar los datos.

La tentación más peligrosa es forzar una reconstrucción automática (rebuild) sin haber analizado antes el estado real de los discos. Si uno de los miembros tiene datos corruptos o sectores ilegibles, la reconstrucción irá copiando y mezclando basura con información buena, hasta que la estructura del volumen quede completamente destruida.

Otro clásico es sustituir discos al tuntún, sin tener claro cuál es el disco realmente dañado ni documentar la posición original de cada unidad. Mover discos de bahía, mezclarlos entre controladoras distintas o cambiar varios a la vez sin plan puede confundir al controlador y hacer que el RAID ya no sepa cómo estaba montado.

Ejecutar herramientas como CHKDSK en Windows o fsck en Linux directamente sobre un volumen RAID que muestra síntomas de corrupción es también muy arriesgado. Estas utilidades intentan “arreglar” la estructura de ficheros basándose en tablas que pueden estar dañadas, y sus correcciones suelen significar borrar entradas, reubicar bloques y reescribir metadatos. En un entorno ya tocado, eso puede suponer la pérdida lógica definitiva de miles de archivos.

Igual de mala idea es confiar en software genérico de recuperación RAID que promete “montar cualquier RAID en automático”. Muchas de estas herramientas trabajan de manera superficial, asumiendo patrones estándar de stripe, offsets y paridad que no siempre se cumplen. Un mal uso puede sobrescribir sectores clave o dejar los discos en un estado peor que el inicial.

Por último, reiniciar el servidor una y otra vez, apagar y encender el NAS o seguir trabajando con normalidad sobre un RAID degradado o con errores de paridad solo sirve para que los discos sufran más, se reasignen más sectores y la corrupción se extienda. Cuantas más escrituras se hagan después del primer problema serio, menos margen de maniobra quedará a los especialistas.

Pasos prudentes cuando detectas un posible fallo en el RAID

Ante cualquier síntoma serio (ruidos, estado degradado, errores de paridad, lentitud extrema, reconstrucciones que fallan, etc.), lo más sensato es bajar revoluciones y actuar con método. Lo que no escribas ni cambies ahora, tal vez pueda salvarse luego.

Lo primero es detener inmediatamente cualquier operación de escritura sobre el array: nada de copiar datos encima, nada de nuevas máquinas virtuales, nada de actualizaciones masivas. Si el volumen todavía es accesible, es mejor montarlo en solo lectura si el sistema lo permite.

A continuación conviene documentar con todo el detalle posible el estado actual: capturas de pantalla de la BIOS o de la interfaz del NAS, listado de discos con su posición física, número de serie, puertos a los que están conectados, mensajes exactos de error que aparecen en logs, etc. Esta información es oro para cualquier laboratorio de recuperación al reconstruir el escenario original.

En casos donde el RAID no se monta o el servidor no arranca, una opción técnica es extraer los discos y conectarlos a otro equipo para hacer copias forenses sector a sector de cada unidad. Estas copias, realizadas en modo lectura, permiten trabajar después sobre clones sin seguir castigando los discos originales.

Si se dispone de conocimientos avanzados, herramientas específicas y un entorno controlado, se puede intentar una reconstrucción lógica del array a partir de esos clones, deduciendo orden de discos, tamaño de stripe, patrones de paridad, offsets y metadatos. Sin embargo, es un trabajo de ingeniería inversa delicado: cualquier prueba “a ojo” cambiando parámetros al azar puede provocar que se interpreten mal los datos.

Para la mayoría de empresas y entornos críticos, lo más seguro es contactar cuanto antes con un servicio profesional de recuperación especializado en RAID y seguir sus instrucciones iniciales. La tasa de éxito suele estar muy ligada al número de experimentos fallidos que se han hecho antes de llegar al laboratorio.

Cómo trabajan los laboratorios profesionales de recuperación RAID

Los servicios profesionales de recuperación de datos que dominan entornos RAID combinan conocimiento profundo de hardware y sistemas de ficheros con herramientas propias y procedimientos estrictos. Esto es lo que suelen hacer, a grandes rasgos, cuando reciben un caso de RAID averiado.

El primer paso es realizar un diagnóstico individual de cada disco: se comprueba el estado mecánico, electrónico y lógico de las unidades, se identifican sectores defectuosos, se revisan las tablas SMART y se evalúa el riesgo de que fallen a corto plazo. Si hay discos con daños físicos, se prioriza su tratamiento en cámara limpia.

Después se crean clones forenses de todos los discos implicados. En lugar de trabajar sobre los originales, se hace una copia sector a sector, con herramientas que permiten saltar sectores muy dañados o reintentar con patrones seguros. El objetivo es preservar el estado original por si hay que volver atrás en el proceso.

Con los clones listos, se realiza una reconstrucción lógica manual del RAID: se identifica el nivel (0, 1, 5, 6, 10, etc.), el orden de los discos, el tamaño de banda (stripe size), los offsets, los algoritmos de paridad y cualquier particularidad del controlador original. Muchas veces se consigue reconstruir el volumen incluso sin disponer del mismo controlador o NAS que lo creó.

Una vez que el volumen virtual reconstruido parece coherente, se pasa a la reparación del sistema de archivos si es necesario: NTFS, ReFS, ext4, XFS, Btrfs, ZFS, VMFS y otros. Aquí el trabajo es similar al de un cirujano: se corrigen estructuras, se reconstruyen tablas de inodos, MFT, superblocks o journals, intentando siempre alterar lo mínimo imprescindible.

Por último, se extraen los datos y se validan de forma sistemática. Se revisa la consistencia de las principales bases de datos, máquinas virtuales o carpetas críticas, se comprueba que los ficheros abren correctamente y se entregan los datos en un soporte nuevo y aislado, como discos externos o un nuevo NAS, para que el cliente pueda revisar la recuperación antes de darla por buena.

En escenarios especialmente complejos, como RAIDs afectados por ransomware, reconstrucciones previas fallidas o volúmenes virtuales dentro de arrays ya dañados, se combinan técnicas de descifrado, análisis forense y reconstrucción de RAID, pero siempre bajo la misma regla: no tocar los originales más de lo estrictamente necesario.

Al final, los sistemas RAID son una herramienta potentísima para mejorar la disponibilidad de los datos, pero siguen siendo vulnerables a fallos físicos, lógicos y humanos. Conocer sus puntos débiles, identificar a tiempo los síntomas de que algo va mal y, sobre todo, evitar decisiones impulsivas cuando aparece un fallo es lo que realmente marca la diferencia entre un susto controlado y una catástrofe de datos.