- La reconstrucción de RAID 5 y RAID 10 es delicada porque estresa al máximo los discos supervivientes y cualquier error de lectura crítico puede hacer fracasar el proceso.
- Antes de reconstruir, es vital diagnosticar el estado SMART de las unidades, hacer copias de seguridad y evitar herramientas que modifiquen el sistema de archivos o los metadatos del RAID.
- El software de recuperación RAID y los servicios profesionales permiten reconstruir matrices de forma virtual y reversible en casos de fallos múltiples o corrupción grave.
- Elegir discos adecuados, monitorizar el array y mantener copias de seguridad externas reduce drásticamente el riesgo de pérdida de datos en futuras incidencias.
Cuando un disco de tu RAID 5 o RAID 10 se muere y empiezan los pitidos, luces en rojo y mensajes de volumen degradado o sistema iniciando, por favor espere, es fácil entrar en pánico. El problema se agrava si el NAS no arranca, Windows muestra pantallazos azules o el servidor hace ruidos mecánicos sospechosos. Y para rematar, muchas veces no hay copia de seguridad reciente. Aun así, no todo está perdido: con el enfoque adecuado, es posible reconstruir el RAID y recuperar los datos sin agravar el desastre.
En esta guía vamos a ver, paso a paso, cómo actuar ante el fallo de uno o varios discos en RAID 5 y RAID 10: qué hacer y qué no hacer, qué riesgos conlleva la reconstrucción, cómo minimizar la pérdida de datos, cuándo usar software de recuperación y en qué momento hay que levantar el teléfono y llamar a un servicio profesional. La idea es que tengas un procedimiento claro y realista, tanto si gestionas un NAS doméstico como un servidor de empresa.
Qué es RAID 5 y RAID 10 y por qué no sustituyen a una copia de seguridad
Antes de hablar de reconstrucción hay que tener claro qué hace exactamente cada nivel. Un RAID (Redundant Array of Independent Disks) combina varias unidades para mejorar capacidad, rendimiento y tolerancia a fallos. Eso no es lo mismo que una copia de seguridad: el RAID intenta seguir funcionando pese a ciertos fallos, pero no protege frente a borrados, ransomware, errores humanos o desastres físicos.
En un RAID 5, los datos y la paridad se distribuyen por bloques entre todos los discos del conjunto. Con N unidades, la capacidad útil es equivalente a N-1 discos: el espacio de uno se “sacrifica” para almacenar información de paridad, que permite recomponer los datos de un disco si este falla. Esa paridad no se guarda en un disco separado, sino repartida en franjas (stripes) a lo largo de todo el array, lo que ofrece buena eficiencia de espacio y un rendimiento muy decente, sobre todo en lectura.
En RAID 10 (también conocido como 1+0) se mezclan espejo (RAID 1) y striping (RAID 0). Primero se crean pares de discos en espejo, y luego se hace striping entre esos pares. El resultado es una combinación de alta velocidad e índice de fallos más tolerante: pueden caerse varios discos siempre que no sean los dos de la misma pareja, lo que lo hace muy atractivo para servidores que priorizan rendimiento y fiabilidad por encima de la capacidad útil.
La ventaja obvia es que, en teoría, RAID 5 tolera el fallo de un disco y RAID 10 puede aguantar fallos múltiples controlados. El problema aparece cuando el fallo real no se ajusta al escenario “limpio” de laboratorio: discos viejos, sectores defectuosos, controladoras que se lían con la configuración o usuarios que fuerzan reconstrucciones con parámetros equivocados.
Por qué la reconstrucción de RAID 5 o 10 es tan delicada
Cuando un disco cae en una matriz RAID 5 o 10, el sistema entra en modo degradado. Eso significa que aún puede servir datos, pero sin redundancia: cualquier fallo adicional o error de lectura crítico durante la reconstrucción puede dejarte sin acceso a la información. Y la ventana de riesgo no es pequeña: puede durar muchas horas e incluso días, según la capacidad del array y la carga del sistema.
En un RAID 5, la reconstrucción implica leer absolutamente todos los bloques de los discos sanos para recalcular los del disco nuevo. Hablamos de un proceso intensivo de E/S (entrada/salida) que somete a los discos supervivientes a la mayor carga continua de lectura de toda su vida útil. Si esos discos ya tienen sectores inestables o reasignados, la probabilidad de que aparezca un error de lectura no corregible (URE) durante el rebuild es nada despreciable, especialmente con unidades de gran capacidad.
Los discos de consumo suelen tener una tasa de URE de 1 error por cada 10^14 bits leídos. En un RAID 5 de 3 discos de 4 TB, durante una reconstrucción es fácil que se lean alrededor de 8 TB de datos en total. La probabilidad de que aparezca un URE durante ese proceso puede rondar varios puntos porcentuales. Con discos aún más grandes y según las tecnologías de almacenamiento, el riesgo se dispara y un único URE en el momento equivocado basta para que la reconstrucción falle y el array quede inutilizable sin técnicas avanzadas de recuperación.
En RAID 10, el proceso es algo más benigno: al estar basado en espejos, reconstruir un disco es “clonar” su pareja. Sin embargo, si los dos discos de un mismo espejo muestran fallos severos (ruidos mecánicos, sectores ilegibles, caídas intermitentes), puedes terminar en una situación similar a un doble fallo en RAID 5, con pérdida lógica completa del volumen.
A esto se suman errores lógicos y de configuración: reconstrucciones mal lanzadas, tamaños de bloque equivocados, orden incorrecto de discos, reinicialización del RAID por error, cambios de controlador o de firmware que interpretan mal los metadatos, etc. Todo ello puede convertir un problema recuperable en un auténtico quebradero de cabeza.
Errores habituales que arruinan una recuperación de RAID
La mayoría de casos en los que la pérdida de datos pasa de “grave” a “catastrófica” tienen algo en común: alguien intenta “arreglar” el RAID a ciegas. Hay unos cuantos errores típicos que conviene evitar a toda costa si quieres conservar alguna opción de reconstrucción limpia.
Uno de los fallos más peligrosos es inicializar de nuevo el NAS o la controladora creyendo que se respetará el RAID. Por ejemplo, retirar todos los discos de un NAS que no arranca, aceptar el asistente de “inicio desde cero”, volver a insertar las unidades y confiar en que el sistema “detecte” la matriz original. Lo más probable es que el equipo cree volúmenes nuevos, interprete algunos discos como RAID 1 independientes o incluso sobrescriba metadatos, complicando enormemente la posterior reconstrucción.
También es muy dañino ejecutar herramientas de reparación de sistema de archivos como CHKDSK o FSCK de forma impulsiva sobre un volumen RAID que ha sufrido corrupción lógica o se ha desmontado de forma anómala. Estas utilidades pueden ser útiles en discos sencillos, pero en entornos RAID con paridad y volúmenes dañados pueden terminar borrando estructuras lógicas clave y reescribiendo zonas que un laboratorio podría haber aprovechado para recuperar información, por ejemplo usando programas para recuperar particiones.
Otro clásico es crear nuevos archivos, mover grandes volúmenes de datos o instalar aplicaciones en el volumen afectado mientras intentas restaurar. Cada escritura puede sobrescribir restos de datos recuperables, sobre todo si el sistema de archivos está en estado inconsistente. Lo mismo ocurre si decides formatear o cambiar el tipo de partición “para empezar de cero” mientras aún albergas esperanzas de recuperar algo.
Por último, está el tema del orden de los discos y las reconstrucciones forzadas. Cambiar las unidades de bahía, mezclar cables, forzar un rebuild sin saber exactamente el tamaño de franja o el tipo de paridad (left/right, synchronous/asynchronous), o mezclar discos de distintas configuraciones, como mezclar unidades HDD y SSD, puede derivar en una matriz desordenada: la controladora interpreta un disco de datos como paridad o viceversa, reescribe franjas encima de información válida y corrompe sin remedio el volumen lógico.
Diagnóstico inicial: qué comprobar antes de tocar nada
Lo primero tras detectar un fallo en un RAID 5 o 10 es parar y dedicar unos minutos a recoger información. Ese diagnóstico inicial es clave para decidir si puedes afrontar la reconstrucción por tu cuenta o si es mejor delegar en profesionales desde el principio. Un error impulsivo en esta fase puede marcar la diferencia entre recuperación parcial o pérdida casi total.
Empieza por averiguar el estado real del array: ¿se monta el volumen en modo degradado?, ¿el sistema operativo o el NAS siguen arrancando?, ¿hay mensajes claros de “RAID degradado”, “RAID fallido” o “disco ausente”? En algunos NAS, como los de Asustor, Synology o QNAP, la interfaz web y la pantalla LCD pueden mostrar mensajes como “iniciando el sistema, por favor espere” o solicitar contraseñas y datos de serie de un disco, lo que ya apunta a problemas con el almacenamiento.
Si el sistema sigue accesible, lo más prudente es comprobar inmediatamente el estado SMART de cada disco. En Linux puedes usar smartmontools, en Windows herramientas como CrystalDiskInfo, y muchos NAS ofrecen la lectura SMART directamente desde su panel de administración. Presta especial atención a atributos como sectores pendientes (C5), sectores irrecuperables (C6) y sectores reasignados (05). Cualquier valor distinto de cero en C5 o C6 es una bandera roja de cara a una reconstrucción segura.
Al mismo tiempo, escucha y observa físicamente los discos: ruidos mecánicos repetitivos, clics, chirridos o arranques y paradas constantes son signos de fallo físico inminente. Ejecutar un rebuild intensivo en un disco que ya hace ruidos raros es la receta perfecta para que se venga abajo a mitad de proceso.
En caso de que el sistema no arranque (pantallazos azules en Windows, kernel panic en Linux, NAS bloqueado), evita insistir una y otra vez en el arranque. Cada intento puede forzar lecturas innecesarias sobre discos dañados. Es mejor apagar, etiquetar los discos por orden de bahía y planificar la siguiente fase con calma.
Medidas previas imprescindibles antes de reconstruir un RAID 5 o 10
Si tras el diagnóstico se confirma que el RAID aún responde (aunque esté degradado) y los discos supervivientes no muestran errores SMART críticos, antes de pulsar ningún botón de reconstrucción hay una serie de pasos que aumentan drásticamente tus posibilidades de éxito. Saltarse estas precauciones puede costarte muy caro.
El primer paso es hacer copia de seguridad de todo lo accesible. Mientras el volumen degradado siga montando, tu prioridad absoluta debe ser copiar los datos a otro soporte: otro NAS, discos externos USB, almacenamiento en la nube, lo que tengas a mano. No te obsesiones todavía con optimizar el rendimiento o la organización; la misión es sacar los datos tal cual, incluyendo máquinas virtuales, bases de datos y compartidos críticos.
A la vez, conviene planificar un entorno de trabajo controlado: asegúrate de que el servidor o NAS está en un lugar con temperatura y ventilación adecuadas, evita golpes, vibraciones y cortes de energía (un SAI es muy recomendable) y documenta toda la configuración actual antes de cambiar nada: orden de los discos, modelo de la controladora, versión de firmware, tipo de RAID, tamaño de bloque, etc.
Otra práctica clave es clonar los discos antes de hacer operaciones agresivas. Crear imágenes sector por sector de las unidades (especialmente las que muestran signos de fallo) en otros discos saludables permite trabajar sobre las copias en caso de que algo salga mal durante la reconstrucción. Si no tienes hardware dedicado, puedes usar herramientas de imagen de bajo nivel desde otro equipo, pero evitando montar los volúmenes de forma normal.
Durante todo este proceso, no elimines archivos ni limpies espacio “para que quepa el rebuild”. Tampoco ejecutes utilidades de reparación de sistema de archivos ni formatees nada. El volumen, por muy caótico que parezca, sigue siendo tu fuente primaria de datos y cualquier modificación puede comprometer lo que todavía se podría recuperar mediante software especializado o laboratorio.
Paso a paso: cómo reconstruir un RAID 5 sin perder datos
Una vez que tienes copia de seguridad, los discos supervisados y cierta tranquilidad, puedes plantearte iniciar la reconstrucción del RAID 5. El procedimiento concreto varía según el entorno (NAS, servidor con controlador hardware, RAID por software en Linux o Windows), pero la lógica general es parecida y conviene seguirla con disciplina.
En primer lugar, confirma que solo hay un disco oficialmente fallido. En el gestor de almacenamiento (DSM, QTS, interfaz de Asustor, herramientas de la controladora, mdadm, etc.) deberías ver el array en estado “degradado” con una única unidad marcada como “failed”, “crashed” o similar. Si aparecen dos discos como defectuosos, no fuerces la reconstrucción estándar: las probabilidades de corromper el volumen son muy altas y en esa situación es mejor consultar a especialistas.
A continuación, reemplaza el disco caído por una unidad nueva o completamente verificada. Lo ideal es usar un disco de la misma capacidad (o superior) y características similares (RPM, caché, gama NAS o enterprise). Inserta la unidad en la ranura que ocupaba el disco fallido, con el sistema apagado si la plataforma no soporta hot-swap de forma segura.
Una vez insertado el disco nuevo, accede al gestor del RAID y añade la unidad al array. En NAS modernos, el asistente suele detectar el nuevo disco y ofrecer directamente la opción de “reparar” o “rebuild”. En controladoras hardware, la reconstrucción puede arrancar de forma automática al detectar la unidad. En RAID por software con mdadm, se hace algo como añadir el nuevo dispositivo al array y dejar que el kernel inicie la resync; si necesitas más ayuda para estos casos, revisa guías sobre recuperación del sistema Linux para emergencias.
Durante la reconstrucción es fundamental monitorizar el proceso: porcentaje completado, tiempo estimado, registros de errores y, muy importante, temperatura y estado SMART de los discos supervivientes. Si ves que otro disco empieza a arrojar sectores pendientes, tiempos de lectura disparados o ruidos poco sanos, plantéate detener el rebuild y buscar ayuda, porque un segundo fallo completo en mitad de la reconstrucción te dejará sin redundancia ni volumen funcional.
Particularidades y buenas prácticas en la reconstrucción de RAID 10
En RAID 10 el comportamiento ante un fallo de disco es distinto al de RAID 5, aunque también requiere cabeza fría. Cuando una unidad muere, su espejo sigue conteniendo una copia idéntica de los datos. La reconstrucción consiste básicamente en clonar el contenido del disco sano al nuevo, lo que suele ser más rápido y menos estresante para el conjunto que recalcular paridad en RAID 5.
La gran ventaja práctica de RAID 10 es que puede tolerar múltiples fallos siempre que no se pierdan simultáneamente los dos discos de un mismo par. Por ejemplo, con cuatro discos (dos espejos en striping), podrían fallar los dos discos “izquierdos” o los dos “derechos” y el array seguiría siendo recuperable. Sin embargo, si se estropean a la vez ambas unidades de una pareja espejo, la parte de datos que se aloja en ese par se pierde por completo, igual que si murieran dos discos en un RAID 1 puro.
En la práctica, esto significa que ante un primer fallo en RAID 10 hay que actuar con rapidez pero sin pánico, sustituyendo el disco dañado lo antes posible y supervisando el estado del compañero de espejo. Si ambos discos de la pareja muestran sectores defectuosos o síntomas mecánicos, forzar un mirrored rebuild puede terminar clonando errores o incluso provocar una caída completa del par.
La metodología previa (backup, comprobación SMART, clonación cuando hay dudas) es exactamente igual de recomendable que en RAID 5. La diferencia es que la ventana de vulnerabilidad suele ser algo menor y, en general, RAID 10 ofrece mejor resiliencia durante los procesos de reconstrucción, lo que lo convierte en una buena elección para entornos donde la disponibilidad y la velocidad de restauración son críticas.
Igual que en otros niveles, no hay que confiarse: RAID 10 tampoco reemplaza a una copia de seguridad externa. Un error de usuario, un ataque de ransomware, un fallo del sistema de archivos o un problema de la controladora pueden destrozar la estructura lógica y dejar el volumen inaccesible aunque todos los discos estén físicamente sanos.
Cuándo recurrir a software de recuperación RAID y cómo usarlo con cabeza
Si el RAID no se monta, la controladora marca múltiples discos como fallidos o el sistema operativo ni siquiera arranca, todavía puedes tener opciones de recuperar el volumen usando software especializado de reconstrucción RAID como TestDisk y PhotoRec. Estas herramientas permiten reconstruir virtualmente la matriz a partir de los discos (o sus imágenes) detectando el orden, el tamaño de bloque y el esquema de paridad.
Programas de este tipo pueden trabajar tanto con discos conectados físicamente al equipo como con imágenes previamente generadas. Es crucial entender que la idea es operar sobre copias de los discos, no sobre los originales, siempre que sea posible. De este modo, si algo sale mal en la reconstrucción virtual o se prueba una configuración incorrecta, se puede volver atrás sin empeorar el estado físico de las unidades.
Estas utilidades suelen ofrecer dos modos de trabajo: detección automática de la configuración RAID, que analiza las unidades en busca de patrones de paridad y estructuras de sistema de archivos, y modo manual, donde puedes introducir datos como número de discos, tipo de RAID (5, 10, 0+1, etc.), tamaño de franja, orden de las unidades, tipo de paridad, tamaño de sector, etc. Cuanta más información previa tengas documentada, menos combinaciones habrá que probar y más rápido será el proceso.
Una vez reconstruido virtualmente el array, el software permite examinar su contenido, lanzar un análisis rápido o completo sobre el sistema de archivos y, si todo cuadra, extraer los datos hacia otro destino seguro. La regla de oro es no guardar jamás nada en los discos origen: todo debe ir a volúmenes externos, nuevos discos o almacenamiento completamente fuera del RAID dañado.
Aun así, conviene ser realista: el software tiene sus límites. Si hay daños físicos severos en varios discos, zonas enteras ilegibles o la matriz ha sido reconfigurada varias veces con parámetros distintos, puede que ni siquiera las herramientas avanzadas sean capaces de reconstruir algo coherente. En esos casos, insistir por tu cuenta suele reducir las probabilidades de éxito de una futura intervención profesional.
Casos extremos: doble fallo en RAID 5 y escenarios “sin redundancia”
El peor escenario típico en RAID 5 es el que combina fallo físico de un disco y degradación subclínica de otro. El primer disco muere y el array entra en modo degradado. Mientras tanto, otro disco lleva tiempo acumulando sectores débiles o reasignados, pero la matriz sigue funcionando gracias a la paridad. En el momento de lanzar la reconstrucción, el estrés de lectura revela esos problemas ocultos y el segundo disco se cae o devuelve errores de lectura irrecuperables.
Desde el punto de vista de la controladora, eso se traduce en un doble fallo para un nivel que solo tolera uno. El RAID pasa a estar “offline” y el volumen desaparece. Aquí es donde muchos usuarios intentan forzar una reconstrucción manual: marcan uno de los discos como bueno “a la fuerza”, reinicializan el array o tratan de reconstruir desde cero con la esperanza de que la controladora se aclare. La realidad es que estas maniobras suelen sobrescribir paridad válida y mezclar franjas, reduciendo drásticamente las opciones de recuperación.
En un laboratorio especializado, el enfoque es completamente distinto. Primero se analizan individualmente todos los discos, identificando cuáles están físicamente muertos, cuáles son parcialmente legibles y cuáles están sanos. Después se crean imágenes de cada unidad con hardware específico capaz de lidiar con sectores defectuosos, limitando la cantidad de lecturas de alto riesgo. A partir de esas imágenes se intenta reconstruir virtualmente el layout del RAID (orden de discos, tamaño de bloque, distribución de paridad) y, sobre esa matriz virtual, se extraen los datos del sistema de archivos.
La clave en estos casos es que cualquier reconstrucción debe ser puramente lógica y reversible, sin escribir nada en las unidades originales. Esto choca frontalmente con los procedimientos habituales de muchos paneles de control y BIOS de controladoras, que asumen escenarios simples y no contemplan fallos múltiples ni corrupción previa.
Por eso, si sospechas que tu RAID 5 tiene dos discos con problemas (ruidos, SMART en rojo, pérdida súbita de rendimiento, errores de lectura), lo más sensato es apagar, etiquetar las unidades y pedir un diagnóstico profesional antes de que la tentación de “probar un rebuild más” termine de arrasar lo que queda.
Prevención: cómo reducir el riesgo en RAID 5 y 10 a largo plazo
Reconstruir un RAID tras un fallo es estresante, consume horas y recursos, y nunca está exento de riesgo. Por eso merece la pena invertir algo de tiempo en prevención para que la próxima vez, si llega, tengas el terreno mucho más controlado. No se trata solo de configurar bien el array el primer día, sino de mantenerlo y supervisarlo durante toda su vida útil.
Una de las decisiones más importantes es el tipo de disco. Para matrices RAID conviene usar siempre unidades diseñadas para NAS o uso empresarial (series NAS, Pro, etc.), que ofrecen mejores tasas de errores irrecuperables y están optimizadas para trabajar en conjunto. Usar discos de escritorio baratos en arrays grandes puede salir muy caro cuando llegue el momento del rebuild.
También es buena idea planificar renovaciones periódicas. Si todos los discos de un array se instalaron a la vez, todos envejecen a la vez. Muchos administradores optan por reemplazar proactivamente las unidades a partir de cierto número de horas de servicio o años de uso en lugar de esperar al fallo catastrófico, reduciendo así la probabilidad de dobles fallos durante una reconstrucción.
La monitorización continua es clave: configurar alertas de SMART, avisos por correo de estado del RAID, informes periódicos de errores de lectura/escritura y tests de paridad programados ayuda a detectar problemas cuando aún son manejables. Algunas plataformas permiten configurar discos “hot spare” listos para entrar en acción automáticamente en cuanto uno falla, acortando el tiempo en que el array está en modo degradado.
Y por supuesto, ningún despliegue RAID serio está completo sin una estrategia de copia de seguridad externa y probada. Eso implica copias periódicas en otros soportes, idealmente con rotación y al menos una copia offline o en otra ubicación física, y pruebas regulares de restauración para asegurarse de que las copias realmente sirven cuando hace falta.
En definitiva, reconstruir un RAID 5 o 10 tras el fallo de uno o varios discos es posible en muchos casos, pero requiere planificación, prudencia y respeto por los riesgos técnicos implicados. Tomarte el tiempo de diagnosticar bien, hacer copias, evitar herramientas destructivas y, llegado el caso, apoyarte en software o servicios profesionales marca una diferencia enorme entre poder volver a la normalidad con tus datos intactos o verte obligado a rehacer toda tu infraestructura desde cero con el bolsillo vacío y la paciencia al límite.
