Recuperación de datos de servidores en Panamá

¿Qué es la recuperación de datos de servidores?

Un servidor empresarial concentra lo que mantiene viva a una organización: el sistema ERP, las bases de datos, el correo, los archivos compartidos y, cada vez más, las máquinas virtuales donde corren todos esos servicios. La recuperación de datos de servidores es el conjunto de técnicas que devuelven esa información cuando el almacenamiento del servidor deja de ser accesible, ya sea por hardware, por software o por una intervención apresurada.

A diferencia de un disco suelto, un servidor apila capas: discos, una controladora RAID que los une en volúmenes lógicos, un sistema operativo o un hipervisor encima y, dentro, aplicaciones y bases de datos con sus propias reglas de consistencia. Recuperar un servidor es entender y reconstruir esa pila completa, capa por capa, sin alterar el original.

¿Por qué un servidor con RAID falla pese a la redundancia?

Porque la redundancia cubre un fallo, no una sucesión de ellos, y porque la propia controladora puede ser el punto de quiebre. El patrón más común que llega al laboratorio no es un disco que muere de golpe: es un arreglo que llevaba semanas degradado —un disco falló, la alerta llegó a un correo que nadie lee— y un segundo disco cae en plena jornada, dejando el RAID 5 fuera de línea. A partir de ahí, las causas se repiten:

• Fallo de la controladora. Cuando la controladora se avería, su firmware se corrompe o muere la batería de la caché protegida (FBWC), los volúmenes lógicos quedan fuera de línea y el servidor no arranca, aunque los discos estén sanos.
• Segundo disco en cascada. Discos del mismo lote envejecen juntos; el segundo fallo agota la tolerancia de un RAID 5 o un SHR.
• Configuración «foreign» o inactiva. Tras un fallo, la controladora marca el arreglo como Foreign o Inactive; el sistema pierde su disco y las máquinas virtuales se cuelgan.
• Actualización de firmware no advertida. Una actualización del Lifecycle Controller que incluye un cambio de firmware de la controladora puede dejar el arreglo ilegible sin que nadie lo decidiera conscientemente.
• Corte eléctrico a media escritura. Deja stripes inconsistentes y entradas de diario sin confirmar.

Conviene insistir en un detalle: muchos de estos fallos no son repentinos. El arreglo avisa —un disco en estado predictivo, una alerta de la caché, un evento en el registro del sistema—, pero el aviso se pierde si nadie monitorea el servidor. Cuando llega el segundo fallo, el margen ya se había agotado en silencio semanas atrás, y lo que parece una caída súbita era en realidad una cuenta regresiva que nadie estaba mirando.

¿Qué NO debes hacer cuando un servidor RAID cae?

La regla vale oro: no dejes que la controladora intente arreglarlo sola. Sus acciones automáticas son, precisamente, las que más casos convierten en pérdidas definitivas.

• No permitas la reconstrucción automática. Si un disco está marcado como fallido y entró un repuesto o un hot spare, la lectura forzada de los demás puede rematar a un segundo disco débil.
• No importes la «foreign config» ni fuerces el «online». Importar o forzar el arreglo escribe metadatos nuevos sobre los discos y puede sobrescribir la única copia buena de tus datos.
• No reinsertes los discos en otro orden ni los muevas a otra controladora «a ver si lee». El orden y la posición forman parte de la estructura.
• No reinicies el host de virtualización esperando que ESXi o Hyper-V «se recuperen»: el reinicio con auto-reconstrucción es una de las vías más directas a la pérdida total.
• Apaga a nivel de sistema, etiqueta por bahía y documenta. Anota el modelo del servidor, la controladora, el nivel de RAID, qué disco falló primero y qué se intentó. Imaginamos los discos en el orden de sus bahías.

Controladoras y plataformas que recuperamos

Cada fabricante guarda los metadatos del arreglo de una forma distinta, y conocer ese detalle es lo que separa una reconstrucción correcta de una que parece funcionar pero entrega datos corruptos:

Recuperamos servidores Dell PowerEdge, HPE ProLiant, Lenovo ThinkSystem, Supermicro e Intel, con Windows Server (NTFS, ReFS), Linux (ext4, XFS) y los hipervisores VMware ESXi y Microsoft Hyper-V.

RAID por hardware, por software y Storage Spaces

No todos los servidores arman su arreglo de la misma manera, y la diferencia cambia cómo se recupera. En el RAID por hardware, una controladora dedicada —PERC, Smart Array, MegaRAID— crea los volúmenes y guarda su configuración en los propios discos; ahí leemos esos metadatos del fabricante para reconstruir. En el RAID por software es el sistema operativo el que gestiona la redundancia: Linux con mdadm y LVM, o Windows con Storage Spaces y sus pools. Storage Spaces, en particular, reparte los datos en columnas y bloques con una lógica propia, distinta de un RAID clásico, así que su reconstrucción exige interpretar esas estructuras y no tratarlas como un arreglo tradicional. Identificar correctamente de qué tipo es el arreglo es el primer paso para no aplicar el método equivocado y entregar datos aparentemente buenos pero mal ensamblados. En el diagnóstico determinamos ese tipo antes de tocar nada, porque condiciona por completo el plan de reconstrucción y las herramientas que usaremos.

Por qué no necesitamos tu controladora ni tu servidor

Porque la geometría del arreglo vive en los discos, no en la tarjeta. Sobre las imágenes clonadas, leemos los metadatos del fabricante —los bloques DDF de Dell, la Partición 9 de HP, los superbloques de mdadm— y de ahí deducimos el tamaño de bloque, la dirección de rotación, la distribución de paridad y el orden de los miembros. Con esos parámetros reconstruimos el arreglo por software, sin la controladora física y sin encender el servidor averiado.

Ese detalle importa más de lo que parece. El stripe por defecto de HP (256KB) es cuatro veces el de Dell (64KB); reconstruir con el valor equivocado, o con la rotación de paridad incorrecta, produce un resultado que supera las comprobaciones superficiales del sistema de archivos pero contiene errores a nivel de byte dentro de los archivos. Por eso leemos los metadatos reales en lugar de adivinar.

Trabajar sin la tarjeta tiene otra ventaja: evita el riesgo de montar una controladora de repuesto de modelo o firmware distinto que, al inicializarse, podría reescribir la configuración del arreglo y cerrar la vía de recuperación. Como partimos de una copia inmutable de cada disco, probamos cuantas hipótesis de geometría hagan falta sin coste alguno para los datos originales.

¿Se puede recuperar un servidor virtualizado (ESXi o Hyper-V)?

Sí, y es de lo más frecuente, porque hoy el servidor suele ser un host que aloja varias máquinas virtuales. Cuando ESXi sufre una pantalla púrpura de la muerte (PSOD), el kernel entra en pánico, las máquinas quedan inaccesibles y el diario de VMFS se queda sin confirmar. La tentación de reiniciar y dejar que el arreglo se reconstruya es, otra vez, la causa más común de pérdida total. Nosotros trabajamos por debajo del hipervisor: reconstruimos el RAID en frío, interpretamos las estructuras de VMFS-5 o VMFS-6, localizamos cada disco virtual (VMDK o VHDX) con sus instantáneas y validamos el sistema de archivos del sistema invitado montándolo en modo solo lectura.

Cuando el arreglo está sano pero una máquina concreta se corrompió —tras una consolidación de snapshot fallida o un apagado sucio—, la recuperación ocurre a nivel del disco virtual, no del arreglo: montamos el VMDK o el VHDX como imagen forense y recuperamos el sistema de archivos interno. Para fallos de vSAN trabajamos el clúster completo, porque los conjuntos parciales reducen mucho lo recuperable. Aplicamos el mismo método que en la recuperación de RAID y la recuperación de NAS.

Bases de datos y correo en el servidor

Recuperar los archivos es la mitad del trabajo cuando el servidor aloja una base de datos. Un SQL Server con sus ficheros de datos y de registro, o un Exchange con su base, exige que la información recuperada sea consistente, no solo presente. Tras reconstruir el volumen, verificamos la integridad de las bases de datos y, cuando hace falta, reparamos las estructuras para que la aplicación vuelva a montarlas. Ese paso adicional es el que devuelve la operación, no solo los datos.

El detalle está en los ficheros y su diario: en SQL Server, el archivo de datos y el de registro deben quedar coherentes entre sí; en Exchange, la base y sus registros de transacciones. Si el servidor cayó a media operación, recuperar los ficheros no basta: hay que dejar la base en un estado consistente para que el motor la monte. Cuando la corrupción es profunda, extraemos los datos a nivel de tabla para que tu equipo pueda reimportarlos, y documentamos qué quedó íntegro y qué se reconstruyó, de modo que la vuelta a producción se decida con información clara.

Nuestro proceso de recuperación de servidores

El principio no cambia: el original no se toca. Cada hipótesis sobre el arreglo se prueba sobre imágenes, de modo que un intento fallido nunca empeora el caso.

1. Recepción y diagnóstico

Documentamos el servidor, la controladora, el nivel de RAID y el estado de cada disco. En 6 horas emitimos el diagnóstico con el alcance real y qué discos requieren intervención física.

2. Clonado por bahía con bloqueo de escritura

Clonamos cada disco preservando su posición de bahía, a través de un bloqueador de escritura. Los discos con daño físico pasan antes por reparación en sala limpia con piezas donantes.

3. Lectura de metadatos de controladora

Sobre las imágenes leemos los metadatos del fabricante (DDF de Dell, Partición 9 de HP, superbloques mdadm) para obtener stripe, paridad y orden de miembros.

4. Reconstrucción de arreglo, volumen y sistema de archivos

Ensamblamos el arreglo virtual, montamos el volumen y el sistema de archivos (NTFS, ReFS, XFS, VMFS) y, cuando hay bases de datos, verificamos su consistencia.

5. Verificación y entrega

Comprobamos la integridad contra tu lista de prioridades y entregamos los datos en un dispositivo nuevo, con un informe del trabajo realizado.

# Estado de la controladora antes de tocar nada
$ storcli /c0 /vall show
VD  Type   State    Size
 0  RAID5  Offln    7.275 TB     # volumen lógico fuera de línea

$ storcli /c0 /eall /sall show
Drive   State
:1      Onln
:2      Failed            # falló hace semanas
:3      Onln
:4      UGood (Foreign)   # reemplazo sin importar
# No se importa la foreign config ni se fuerza online: se clona y se reconstruye en frío.

Aquí la tentación es importar la configuración «foreign» o forzar el volumen a «online». Cualquiera de las dos escribe sobre los discos y puede cerrar la única vía de recuperación. Por eso clonamos primero y reconstruimos sobre las imágenes.

¿Recuperan si la controladora está muerta?

Sí. Como la geometría del arreglo está en los discos y no en la tarjeta, no necesitamos que la controladora funcione ni que el servidor encienda. Tampoco hace falta una controladora idéntica de repuesto: reconstruimos el arreglo por software a partir de los metadatos que leemos en las imágenes. Eso evita, además, el riesgo de meter una tarjeta distinta que reescriba la configuración y empeore el caso.

Casos frecuentes en empresas panameñas

Atendemos servidores caídos en empresas que dependen de su ERP y su base de datos para facturar, en despachos contables y de auditoría, en clínicas con sistemas de gestión de pacientes, en distribuidoras y operadores de la Zona Libre, y en cualquier organización donde un host de virtualización concentra varios servicios a la vez. El costo casi nunca es el hardware: es la interrupción del negocio mientras el sistema está caído. Coordinamos la recepción en toda la república, priorizamos el volumen o la máquina virtual que detiene la operación y dejamos una recomendación honesta de respaldo, porque un arreglo redundante protege de un disco averiado pero no sustituye a una copia de seguridad fuera del servidor. Antes de iniciar definimos contigo qué servicio debe volver primero —la base de datos que factura, el controlador de dominio que autentica, la máquina virtual que sostiene la aplicación principal— y trabajamos en ese orden para acortar el tiempo de inactividad. Esa priorización, acordada por escrito, pesa tanto como la recuperación misma cuando cada hora detenida tiene un costo medible.

Preguntas frecuentes