Hay muchas cosas que preocupan a un administrador de sistemas, caídas de los sistemas, servidores averiados, problemas en la red, vulnerabilidades de seguridad… Pero lo peor que puede pasar es perder los datos del almacenamiento, pero si además ese almacenamiento es el tu sistema de virtualización, donde están todos tus servidores web y servicios y la mayoría de aplicaciones de sistema, eso es la peor pesadilla de un administrador de sistemas. Y eso es lo que pasó. Después de un corte eléctrico, uno de los volúmenes de almacenamiento del servidor de virtualización se corrompió. El sistema de virtualización no lo había hecho yo, estaba EOL (sin soporte y descatalogado) y la empresa que lo instaló no daba soporte ni pagando. En este sistema el almacenamiento estaba replicado pero no había suficiente espacio en la reserva para los snapshots. Eso provocó que fallara la replicación. Llamé a un compañero de otro instituto y decidió poner el almacenamiento secundario como principal, y al hacerlo vimos como se reducía el espacio ocupado en el volumen, como si estuviera casi vacío. En definitiva, no sólo perdimos los datos del almacenamiento principal sino también del de respaldo. Todos los datos de ese volumen perdidos sin posibilidad de recuperación.

A punto de hacerme seppuku recordé que si rehacía el volumen y las máquinas virtuales podría usar mi servidor de backup y disaster recovery para recuperar las máquinas virtuales. Desgraciadamente ese servidor estaba virtualizado en el volumen que desapareció, así que no tenía servidor para recuperar las máquinas, aunque los archivos de backup estaban en un servidor de almacenamiento distinto al almacenamiento de virtualización. Pero en previsión de esto yo había hecho una ISO de recuperación con backup en tar manual del servidor de virtualización y lo guardé en ese servidor de almacenamiento externo. Esto me permitió recuperar el servidor de backup pero era una copia antigua y la base de datos no estaba actualizada. Para ello tuve que utilizar las herramientas de recuperación de desastres del backup que permiten leer los archivos de backup. Estos archivos tienen un tamaño de 50 GB y los backups pueden empezar en un archivo y terminar en otro y empezar el siguiente backup en el mismo archivo. Sin la base de datos no se puede saber donde empiezan y terminan los backups. Con las herramientas de recuperación se explora el archivo hasta recuperar los metadatos que haya en el archivo, pero tarda horas en examinarlo. Viendo el archivo modificado de backups enteros (donde están los backups de la base de datos) más reciente sólo tardé un día en recuperar la base de datos y tras importarla pude recuperar el resto de los servidores y recuperar todos los servicios. Y me encargué de hacer espacio para que no hubiera problemas con los snapshots y se replicaran los volúmenes de virtualización sin problemas. Y todos se regocijaron. Al menos hasta el siguiente fallo catastrófico del servidor de virtualización. Pero eso es otra historia.

La moraleja de esta historia es que no importa cuan seguro creas que es tu sistema, todo puede fallar, así que cuanto más redundancia poseas menos posibilidades habrá de fallar. Y por ello mi próximo servidor de virtualización se redundará con el VDC del CSIC, o al menos ese es mi plan.