¡Bulma ha tenido su primera hecatombe nuclear!. Si os fijáis, ahora mismo Bulma ha vuelto al 4 de Febrero del 2000, sigue leyendo para saber cómo lo hemos conseguido lo que Einstein sólo pudo imaginar ;D.
Los preliminares
Hoy de mañanita, los administradores de Bulma nos hemos encontrado con que el acceso a la base de datos PostgreSQL estaba caído, como amablemente nos avisó Sebastià por la bulmailing.
El fallo en sí es algo que ya habíamos detectado en esta versión del PostgreSQL (el .rpm de la RedHat 6.1): se cae por corrupción de memoria compartida cuando se inserta un artículo que supera el tamaño máximo de registro de Postgres (8KB por defecto).
Este problema incluso lo solucionamos las veces anteriores que pasó, ya que basta con matar los procesos del postgres y rearrancarlo.
La hecatombe
Zebub, con la mejor de sus intenciones y el peor de sus nerviosismos ha estado hoy intentando arreglarlo sin recordar que ya nos habíamos encontrado con ese problema y su sencilla solución, con tal mala suerte que acabó llevándose por delante en el intento los datos de la base de datos.
Para más inri, el proceso de backup que teníamos preparado, no funcionaba y nosotros sin saberlo (creaba archivos de backup de 0KB, muy decorativos pero totalmente inútiles), con lo que el último archivo de backup válido que teníamos era del 4 de Febrero, he ahí la explicación a tan flamante viaje en el tiempo 😉
La recuperación
La mayoría de la BD se ha recuperado mediante ese archivo de backup, únicamente quedaban 16 artículos sin recuperar, lo cual no dejaba de fastidiarnos bastante.
Afortunadamente, en este sentido la suerte se ha aliado con nosotros, ya que al fallar el PostgreSQL, ha generado un fabuloso /var/lib/pgsql/core de 3MB, en el que se encuentra el estado del postmaster anterior a la defunción.
Gracias a un detenido análisis de ese archivo y a herramientas revolucionarias de análisis post-mortem (less core ;D), en la sección de datos de ese archivo, hemos encontrado ¡la totalidad del texto de los artículos perdidos! :”))))
A los autores afectados se les enviará un mail con el texto de sus artículos para que los inserten de nuevo o, de ser posible, nosotros mismos se los insertaremos a su nombre.
Conclusiones
Ante cualquier hecatombe, lo primero que hay que hacer es no ponerse nervioso ni buscar culpables, a una situación así se llega debido a múltiples causas.
Bloquear los accesos externos para evitar que modifiquen nuevamente nuestra información.
Ponerse en contacto con el resto de gente que también administra esa máquina, siguiendo la filosofía dos ojos ven más que uno (aplicar inducción sobre ese razonamiento para llegar a la filosofía OpenSource), y decidir el plan de actuación a realizar.
Guardar todos los ficheros que reflejan la situación actual, nunca se sabe de dónde podrás sacar la información para restaurar la antigua.
Una vez decidido un plan de actuación, realizarlo y tomar las medidas oportunas para que las distintas causas que han provocado la hecatombe, no se repitan o, de repetirse no provoquen otra hecatombe :).
Este post ha sido traido de forma automatica desde https://web.archive.org/web/20140625063149/http:/bulma.net/body.phtml?nIdNoticia=230 por un robot nigromante, si crees que puede mejorarse, por favor, contactanos.