¿Por qué un servidor no arranca? Las cuatro capas
La buena noticia, antes de cualquier diagnóstico, es que un servidor que no arranca rara vez significa que perdiste los datos: la información vive en los discos y casi siempre sigue ahí. Lo que falló está, normalmente, en una de cuatro capas, y conviene pensarlas de afuera hacia adentro. La primera es la alimentación y el hardware: si el servidor no enciende, no hace POST o no emite el pitido de arranque, el problema es físico —fuente, placa, memoria— y los discos no están en juego. La segunda es el controlador RAID: el servidor enciende, pero el arreglo no se detecta o la controladora muestra errores. La tercera es un disco averiado: uno o varios discos fallaron, a veces con ruidos. Y la cuarta es el arranque y el sistema operativo: el equipo hace POST, el RAID está sano, pero Windows o Linux no cargan por un cargador de arranque corrupto, una actualización fallida o un controlador dañado. Cada capa tiene un manejo distinto, y por eso el diagnóstico va antes que cualquier acción.
Lo primero: no reinstales ni reinicialices el RAID
Antes de hablar de soluciones, hay que blindar lo que no se debe hacer, porque el daño real casi nunca lo causa el fallo original: lo causa la reacción apresurada. Estos son los errores que vemos una y otra vez en empresas, y los que más datos destruyen: reinstalar el sistema operativo encima de los discos, forzar una reconstrucción automática del RAID, cambiar discos sin saber cuál falló, usar software gratuito de recuperación de RAID sobre el arreglo original, y apagar y encender el servidor una y otra vez. Una reconstrucción mal hecha puede sobrescribir datos válidos y destruir la estructura del RAID por completo. Por eso, ante un servidor que no arranca con datos importantes, la primera medida es la más simple: apágalo y no toques la configuración. Preservar el orden de los discos, evitar reinicializar el arreglo y minimizar las escrituras son las tres reglas que más probabilidades de recuperación conservan.
¿Cómo sé en qué capa está el fallo?
Un triaje rápido, sin tocar nada delicado, te dice por dónde va el problema. Empieza por lo más básico: ¿el servidor enciende y hace POST? Si no hay imagen ni pitido, es hardware o alimentación, y los discos están a salvo. Si arranca pero te dice «no boot device» o el arreglo no aparece, sospecha del controlador RAID o de los metadatos del arreglo. Si escuchas ruidos —clics, zumbidos— o un disco no se detecta, hay daño físico en una unidad. Y si todo el hardware responde y el RAID se ve sano pero el sistema operativo no carga, el fallo es lógico, en el arranque o el sistema. Mientras diagnosticas, ve reuniendo datos que serán oro para la recuperación: el modelo del controlador RAID, el número y modelo de cada disco, su orden físico en las bahías y qué pasó justo antes del fallo.
Separa recuperar los datos de hacerlo arrancar
Este es el principio que marca la diferencia entre un susto y una pérdida, y casi nadie lo aplica bajo presión. Recuperar la información y hacer que el servidor vuelva a arrancar son dos trabajos distintos, y el orden importa muchísimo. Cuando los datos son críticos, el camino seguro es: primero clonar los discos o el arreglo —sector a sector, sin escribir en ellos— y recuperar la información desde esas copias; y solo después, con los datos ya a salvo, reconstruir el RAID o reinstalar el sistema. Hacerlo al revés —empeñarse en «arreglar el arranque» sobre los discos originales— es justo lo que convierte un problema con solución en uno sin marcha atrás, porque cada intento de reparación escribe sobre la única copia que tienes. La regla mental es simple: rescata primero, repara después.
¿Cuándo es trabajo de laboratorio?
Hay casos en los que el triaje casero ya no debe avanzar más. Acude a un laboratorio si el RAID no se detecta o no conoces su configuración exacta, si algún disco hace ruidos o no aparece, si una reconstrucción ya falló, o si no hay respaldo y la información es crítica para la operación. En todos esos escenarios, un laboratorio actúa de una forma que el «hágalo usted mismo» no puede igualar: crea imágenes seguras de cada disco antes de cualquier reconstrucción y recrea el arreglo respetando su orden, su stripe size y su paridad, trabajando siempre sobre las copias. Es el mismo cuidado que aplicamos cuando un RAID está degradado o cuando un NAS aparece con el volumen degradado: ante la duda, preservar pesa más que intentar. Forzar el arreglo por cuenta propia, en cambio, suele cerrar la puerta a la recuperación.
El servidor calla, los datos esperan
Los datos casi siempre están ahí, esperando; lo que decide si los conservas no es la rapidez con que intentas «levantarlo», sino el cuidado con que diagnosticas y la disciplina de rescatar antes de reparar. En Data Recovery Panama clonamos, reconstruimos la geometría del RAID sobre las imágenes y devolvemos los datos sin arriesgar los originales. Porque el laboratorio que recupera también protege.
Preguntas frecuentes
Casi nunca. En la mayoría de los casos los datos siguen intactos en los discos; lo que falla es el arranque, el controlador RAID o el hardware, no la información. El riesgo real no es el fallo en sí, sino lo que se hace después: reinstalar el sistema o reinicializar el RAID «para que vuelva» es lo que de verdad puede borrar los datos.
El fallo suele estar en una de cuatro capas: la alimentación o el hardware, cuando no hace POST; el controlador RAID, cuando el arreglo no se detecta; un disco averiado; o el arranque y el sistema operativo, cuando el equipo enciende y el RAID está bien, pero el sistema no carga. Saber en qué capa está el problema define qué es seguro hacer.
Reinstalar el sistema operativo, forzar una reconstrucción automática del RAID, cambiar discos sin saber cuál falló, usar software gratuito de recuperación de RAID y apagar y encender el servidor una y otra vez. Una reconstrucción mal hecha puede sobrescribir datos válidos y destruir la estructura del RAID. Preserva el orden de los discos y minimiza las escrituras.
Si los datos son críticos, son dos trabajos distintos y el orden importa: primero clona los discos o el arreglo y recupera la información desde las copias, y solo después reconstruye o reinstala. Hacerlo al revés —intentar arreglar el arranque sobre los discos originales— es lo que más datos cuesta cuando algo sale mal.
Cuando el RAID no se detecta o no sabes su configuración, cuando algún disco hace ruidos o no aparece, cuando una reconstrucción ya falló, o cuando no hay respaldo y la información es crítica. En esos casos, apaga el servidor y no toques la configuración: un laboratorio clona los discos y recrea el arreglo respetando su orden, stripe size y paridad.