Historia de Backups II

Moraleja de backups

Hay un dicho popular que reza “Nadie sabe lo que tiene hasta que lo pierde” y suele aplicarse en asuntos de la vida amorosa. Yo pido que se aplique en el campo de la información.  De cuando en cuando veo a algunos de nuestros clientes perden días, meses o años de trabajo por no tener una estrategia adecuada de backup, por lo que quiero contar acá una historia de algo que me ocurrió antes de trabajar en ISA.

Hace años era director de informática de una empresa grande. Recién habíamos puesto en marcha un sistema de información que operaba totalmente en línea que descartaba uno anterior en el que los procesos se hacían por lote.

El mainframe era una computadora de marca de tres letras carísima con una unidad de backup de cinta DAT.

Adicto como soy a los backups, programamos con el personal el sistema para que sacara una copia de la base de datos a la cinta todos los días de semana a las 10 de la noche y los sábados a las 10 de la mañana.

Todas las mañanas a las 8:00 ejecutábamos un proceso de validación del backup. Nos obligábamos a hacer esto pues esas cintas o el dispositivo que las grababa ( no se cual de los dos) eran extremadamente delicados y fallaban a menudo. Si en validación nos dábamos cuenta que el backup no servía, a las 10 de la mañana comenzábamos otro backup manual como sustituto del día anterior.

Una copia del backup se guardaba en cajillas plásticas protectoras de polvo dentro del departamento. La copia del sábado se enviaba a la caja de seguridad de la empresa.  Una vez al mes se ponía una copia en la cajilla de seguridad de un banco, procedimiento que se interrumpió porque era muy incómodo y el banco no tenía parqueo adecuado. De cuando en cuando se le daba a uno de los gerentes/propietarios una copia para que la guardara en su casa.

Se me olvidaba comentar que el departamento de informática no trabajaba completamente los días sábados, y esto es necesario para comprender el resto de la historia:

Un viernes el encargado de backups puso la respectiva cinta en el dispositivo. Cerramos el departamento y nos fuimos a casa. El día sábado el encargado de backups no se presentó a trabajar. Nadie quitó la cinta del dispositivo. A las 10:00 de la mañana comenzó el proceso de backup automático (especial de sábados) por supuesto que lo estaba haciendo sobre la misma cinta en la que hasta unos segundos antes estaba el backup del viernes en la noche. Cerca de las 11:00 PM sonó el teléfono de informática, era gente del departamento de contabilidad que se quejaba de la lentitud del sistema.

El casi ingeniero que estaba a cargo pensó (correctamente) que la lentitud se debía a el programa de backup que se estaba ejecutando, por lo que decidió interrumpirlo, con un simple control-C (en Unix) Todo habría pasado desapercibido de no haber sido porque el lunes siguiente, el disco principal de la computadora falló dañando permanentemente la base de datos.

 

El Problema

Para solucionar el problema del disco duro, necesitabamos restaurar la información, pero:

1. No estaba bueno el backup del sábado porque lo interrumpieron.
2. No estaba bueno el backup del viernes porque el del sábado le había caído encima

Tuvimos que regresar al backup del jueves. Así perdimos el trabajo de viernes, sábado y casi todo el lunes.

Parece poco, pero en un sistema hecho para operar totalmente en línea, significa que había que rehacer todos esos días de trabajo. Como a nadie le gusta hacer dos veces lo mismo, fuimos la comidilla de todos los departamentos. Igual no nos querían por el reciente cambio de sistema que les asignaba más responsabilidad a los usuarios (En el sistema anterior solo pasaban un papel a un grupo de operadores/digitadores y ellos no hacían nada en computadora)

A pesar de las extremas medidas de seguridad que tomábamos, hubo una conjunción de factores: falla de hardware, falla humana que al final nos llevó a un problema serio.

Moraleja:  nunca está demás un procedimiento adicional de backup.