Recuperación de datos RAID en Panamá

¿Qué es y cuándo necesitas recuperación de RAID?

Un RAID combina varios discos para que el sistema operativo los vea como un solo volumen, ganando velocidad, capacidad o tolerancia a fallos según el nivel configurado. Esa misma unión es su punto débil: el arreglo es un sistema lógico único, con metadatos, orden de discos y parámetros de paridad que deben estar intactos para que los datos sean legibles. Cuando esa estructura se rompe, los discos pueden estar físicamente sanos y aun así la información queda inaccesible.

Necesitas recuperación profesional cuando el arreglo ya no monta y ninguna acción de la interfaz lo devuelve a línea: cuando la controladora marca dos o más discos como fallidos, cuando una reconstrucción se detuvo a mitad de camino, cuando el NAS muestra el volumen como «crashed» o «inactive», o cuando alguien cambió el orden de los discos o inició una reconfiguración por error. En todos estos casos, seguir operando sobre el arreglo original reduce las probabilidades con cada intento.

¿Por qué falla un RAID si se supone que es redundante?

La redundancia tolera un número limitado de fallos simultáneos, no cualquier fallo. Un RAID 5 soporta la pérdida de un disco; un RAID 6, de dos. En cuanto se supera ese margen —o cuando el problema está en la controladora, en los metadatos o en una decisión humana— el arreglo entero deja de servir datos. Estas son las causas que vemos con más frecuencia en el laboratorio:

• Fallo de varios discos en cascada. Los discos de un arreglo suelen ser del mismo lote y la misma edad, así que cuando uno falla, los demás están a punto de hacerlo. Un segundo disco cae días después del primero y el margen de tolerancia se agota.
• Error de lectura irreparable (URE) durante la reconstrucción. Para rehacer un disco, la controladora debe leer cada sector de todos los discos supervivientes. Si uno de ellos devuelve un error de lectura en un solo sector, la reconstrucción se aborta y el arreglo pasa de «degradado» a «fallido».
• Fallo o sustitución de la controladora. Cambiar una controladora por un modelo incompatible, o que la propia controladora corrompa los metadatos, deja los discos sanos pero el volumen ilegible.
• Reconstrucción mal ejecutada. Reconstruir con el orden de discos equivocado o con parámetros incorrectos escribe datos erróneos sobre la paridad y complica —a veces impide— la recuperación posterior.
• Corte eléctrico durante una escritura (write hole). En arreglos con paridad, una interrupción de corriente a media escritura deja stripes inconsistentes. En zonas con red eléctrica inestable, este es un disparador habitual.
• Error humano. Inicializar el arreglo, reasignar discos a un grupo nuevo o ejecutar una comprobación de disco sobre un volumen ya dañado son acciones que destruyen información rápidamente.

La verdad incómoda: el RAID no es una copia de seguridad

El error de fondo de muchas empresas es tratar el arreglo como si fuera su respaldo —un mito que desmontamos en RAID no es un respaldo—. No lo es. El riesgo del error de lectura irreparable lo deja claro: los discos SATA de consumo se especifican alrededor de un error por cada 10^14 bits leídos, lo que equivale aproximadamente a 12,5 TB. En un RAID 5 con varios discos grandes, la reconstrucción obliga a leer un volumen de datos cercano o superior a esa cifra, de modo que la probabilidad de tropezar con un error que detenga el proceso se acerca peligrosamente al 100 %. Los discos SAS empresariales, especificados en torno a un error por cada 10^15 bits, mejoran las probabilidades unas diez veces, pero no eliminan el problema.

Por eso los ingenieros de almacenamiento consideran el RAID 5 inadecuado para discos de más de 2 TB, y por eso la regla 3-2-1 sigue vigente: tres copias de los datos, en dos tipos de soporte distintos y con una copia fuera de la sede. El arreglo te protege de un fallo de hardware puntual; no te protege de un borrado, un cifrado por ransomware ni de un segundo fallo durante la reconstrucción.

¿Qué NO debes hacer cuando tu RAID falla?

La regla más importante es la más sencilla: deja de escribir sobre el arreglo. Cada operación posterior al fallo puede sobrescribir justo los datos que queremos rescatar. En orden de prioridad:

• No reconstruyas el arreglo ni dejes que un disco de repuesto («hot spare») arranque una reconstrucción automática. Si ya hay un disco fallido, la lectura forzada de los demás puede rematar a un segundo disco débil.
• No cambies el orden de los discos ni los muevas a otra controladora «a ver si así lee». El orden y la posición forman parte de la estructura del arreglo.
• No inicialices, no formatees ni recrees el volumen. Crear un arreglo nuevo sobre los mismos discos reescribe los metadatos que necesitamos para reconstruir el original.
• No ejecutes chkdsk, fsck ni reparaciones del sistema de archivos sobre un volumen dañado: pueden mover y borrar estructuras de forma irreversible.
• Apaga el equipo y documenta. Anota el modelo de la cabina o controladora, el nivel de RAID, el número de discos, cuál falló primero y qué se intentó después. Esa información acelera el diagnóstico.

Si tu caso se puede resolver sin laboratorio, te lo diremos. Hay situaciones de daño puramente lógico que un equipo de IT competente puede manejar con las herramientas y el respaldo adecuados; cuando ese es el panorama, lo honesto es decirlo. La recomendación la marca tu situación, no nuestro catálogo.

Niveles y sistemas que recuperamos

Trabajamos el espectro completo de configuraciones, desde el arreglo de dos discos de una pequeña oficina hasta cabinas multidisco de entornos corporativos:

Cubrimos tanto RAID por hardware (controladoras dedicadas) como por software (mdadm de Linux, Storage Spaces de Windows), y los sistemas de archivos que suelen ir encima: NTFS, ReFS, ext4, XFS, Btrfs, ZFS y VMFS.

Nuestro proceso de reconstrucción, paso a paso

El principio que guía todo el procedimiento es el trabajo sobre copias: el arreglo original no se modifica en ningún momento. Cada decisión se prueba sobre imágenes clonadas, de modo que un intento fallido nunca empeora el caso.

1. Recepción y diagnóstico

Identificamos el nivel de RAID, el número de discos y el estado de salud de cada miembro mediante lectura SMART y una inspección controlada. En 6 horas emitimos un diagnóstico con el alcance real de la avería y qué discos requieren intervención física.

2. Clonado con bloqueo de escritura

Hacemos una imagen sector a sector de cada disco a través de un bloqueador de escritura, de modo que el contenido original permanece intacto. Si un miembro tiene daño físico —cabezales, motor o electrónica—, lo intervenimos en sala limpia antes de clonarlo.

3. Análisis de parámetros

Sobre las imágenes, determinamos el tamaño de bloque (stripe), el orden de los discos, la rotación de paridad y los desplazamientos. Estos parámetros son los que permiten reconstruir el arreglo de forma virtual sin tocar el hardware.

4. Reconstrucción en frío

Ensamblamos el arreglo virtual a partir de los clones y montamos el sistema de archivos (NTFS, ReFS, ext4, XFS, Btrfs, ZFS o VMFS). Cuando hay máquinas virtuales encima, atravesamos las capas hasta llegar a los datos del sistema invitado.

5. Verificación y entrega

Comprobamos la integridad de lo recuperado, te entregamos el listado de archivos recuperables y devolvemos la información en un dispositivo nuevo. Si lo solicitas, aplicamos borrado seguro certificado al medio original.

# Inspección de los metadatos de cada miembro (solo lectura)
$ sudo mdadm --examine /dev/sd[b-e]1

/dev/sdb1:   Raid Level : raid5   Raid Devices : 4
             Array State : AAAA ('A' == active)   Events : 184219
/dev/sdc1:   Array State : AAAA   Events : 184219
/dev/sdd1:   Array State : .A.A   Events : 181004   # quedó atrás
/dev/sde1:   Array State : .A.A   Events : 180997   # segundo fallo

# El arreglo no monta: dos miembros desincronizados
$ cat /proc/mdstat
md0 : inactive sdb1[0](S) sdc1[1](S) sde1[3](S)
      No se fuerza el ensamblado. Se clona cada disco y se reconstruye en frío.

La diferencia en el contador de eventos entre discos (184219 frente a 181004) revela qué miembro se desconectó primero. Forzar el ensamblado aquí, una tentación frecuente, suele empeorar el caso. Por eso trabajamos siempre sobre clones.

¿Se puede recuperar un RAID con máquinas virtuales encima?

Sí, y es uno de los escenarios corporativos más habituales. Cuando un host VMware ESXi o Hyper-V guarda sus máquinas sobre un arreglo que falla, la recuperación tiene capas anidadas: primero reconstruimos el RAID físico, después interpretamos el volumen VMFS o el espacio del hipervisor, luego extraemos cada disco virtual (VMDK o VHDX) y, por último, el sistema de archivos del sistema invitado dentro de cada uno. El software de recuperación de consumo no atraviesa esta cadena; requiere herramientas y procedimiento de laboratorio.

Lo mismo ocurre con los NAS que exponen volúmenes iSCSI a un hipervisor: el LUN no aparece como una carpeta compartida, sino como un bloque dentro del sistema de archivos del NAS que primero hay que reconstruir, igual que en la recuperación de datos en SAN. Documentamos cada capa de la cadena para que tu equipo de IT pueda volver a poner las máquinas en marcha sobre un entorno sano, sin arrastrar el problema original.

¿Cuánto tarda y cuánto cuesta recuperar un RAID?

El plazo y el precio dependen del nivel de RAID, del número de discos, de si hay daño físico y de la urgencia. Por eso el primer paso siempre es el diagnóstico: hasta no evaluar el estado real de cada miembro, cualquier cifra sería una adivinanza. Una vez diagnosticado, te confirmamos por escrito el alcance y el coste antes de iniciar cualquier trabajo, sin sorpresas.

El servicio estándar resuelve la mayoría de los casos en pocos días laborables. Para paradas críticas de negocio existe la línea de emergencia 24/7, que trabaja de inmediato en turnos nocturnos y fines de semana y conlleva un recargo sobre la tarifa habitual. Esto no es asesoría financiera; es la mecánica de un servicio de alto valor donde cada hora de laboratorio cuenta.

Casos frecuentes en empresas panameñas

Atendemos arreglos caídos en contadurías y firmas de auditoría con cierres en curso, bufetes con expedientes activos, clínicas con historiales de pacientes, operadores logísticos de la Zona Libre, plantas de manufactura con sistemas de producción y entidades del sector público. En todos comparten un patrón: la información del arreglo sostiene la operación diaria y cada hora de parada tiene un costo. Por eso priorizamos el diagnóstico rápido y la confidencialidad estricta. Coordinamos la recepción del equipo en toda la república y, cuando el caso lo justifica, trabajamos contra reloj para que el negocio vuelva a operar. Antes de iniciar definimos qué datos son prioritarios —la base de datos contable, los expedientes en curso o las máquinas virtuales de producción— para recuperarlos primero y reducir el tiempo de inactividad real.

Preguntas frecuentes