Windows – Luchando contra los elementos


Buenas tecno-blogeros!! No, no quiero decir que seais adictos al techno, que si bien es un estilo de música que me encanta, no tiene que ver con este tipo de post :-D

La semana pasada hablábamos de cómo recuperar un controlador de dominio (DC). Tras la resaca del puente hoy continuamos con el tema de la recuperación, vamos a hablar de cómo recuperar un Windows (2003, 2008) en caso de desastre. Un viernes cualquiera, 17h, la mayoria de los administradores están ya pensando en el fin de semana, de repente una llamada… el servidor no da servicio… tu cara refleja lo que se te viene encima… salir pronto hoy se convierte en tu prioridad pero antes deberás obrar el milagro.. o a lo mejor tienes suerte y no es tan grave.. nunca se sabe, pero como decía Indiana Jones.. solo hay un modo de averiguarlo.

Antes de ponernos manos a la obra conviene y recomiendo dedicar unos minutos a averiguar si el servidor ha sufrido algún cambio que haya causado el problema, me explico, si no tenemos un control de cambios sobre esa máquina, merece la pena hablar con alguien cuya aplicación resida en ese servidor, ya que es posible que hayan actualizado un driver o un parche sin previo aviso. ¿Por qué dedicar esos minutos en cabrearte un poquito si la respuesta a tus preguntas son afirmativas? porque la mayoría de las veces, si esto ha ocurrido, con la opción “Última configuración buena conocida” (Last known good configuration en los sistemas en inglés) desde el menú avanzado de Windows, podremos solucionar el problema, ya que el sistema por defecto guarda la información del registro de la última vez que accedimos al sistema sin problemas, es decir, pudimos hacer logon y entrar al servidor como cada día.

Si la opción anterior no funcionó, la cosa empieza a complicarse. Si no conseguimos estabilizar el servidor la siguiente opción será entrar en modo a prueba de errores, de nuevo a través del menú avanzado de Windows. Podremos acceder con o sin acceso a red. En este modo se cargan los controladores necesarios para arrancar el sistema permitiéndonos, por ejemplo, acceder al visor de eventos y ver que alertas se han producido antes y durante el inicio del sistema, dejar habilitados solo los servicios de Microsoft y descartar así problemas de terceros – a través del comando Msconfig -, sacar información del servidor y averiguar si tenemos conflictos en algunos dispositivos a través del comando Msinfo32, etc…

Recomiendo que os familiaricéis con esos comandos porque podréis controlar a nivel de configuración y arranque del sistema un montón de detalles que son fundamentales. Si aún así no conseguimos levantar el sistema, es posible que se haya generado un archivo llamado Memory.dmp (Memory dump) que contiene el volcado de la memoria que el sistema tenía en el momento de producirse el fallo en el servidor. Este archivo es configurable desde las propiedades del sistema, opciones avanzadas, Inicio y configuración. Podremos establecer diferentes tipos de Memory dump en cuanto a tamaño del fichero, desde un volcado pequeño, pasando por el volcado del Kernel hasta un volcado completo de la memoria que ocupará el tamaño en gigas que tengamos instalada en el servidor.

Tan solo tener en cuenta que si el fichero de paginación está configurado en otra unidad que no sea C:\, no dispondremos de este volcado, de hecho si el fichero de paginación lo tenemos partido y distribuido en varias unidades, será el tamaño del configurado en la unidad C:\ el que dictaminará el tamaño del memory dump.

Y eso es todo groso modo, la semana que viene continuaremos hablando del fichero memory.dmp y profundizaremos más en su análisis. Hasta la semana que viene!

Artículos relacionados

Acerca del autor

2 Comentarios

  1. Ikeisenhower
    13 octubre, 2010
  2. De Cabo
    14 octubre, 2010

Deja tu comentario

Mostrar
Ocultar