La Importancia de Hacer Respaldos Frecuentemente

Siempre escuchamos de Bases de Datos que hackean, bien sea por algún tipo de fanatismo o venganza. Sin embargo hay una causa muy común -y mucho más peligrosa- de la perdida de datos que normalmente ignoramos, y es el error humano.

¿Por qué es más peligroso el error humano que los ataques informáticos?

Sencillo, porque nunca pensamos que nos va a pasar a nosotros. Siempre que escuchamos casos de pérdida de datos accidental decimos cosas como: “¿En qué estaba pensando cuando ejecutó ese comando?” O la típica: “¿Por qué no hizo un respaldo antes de hacer eso?”. Pues la respuesta a ambas preguntas es bastante simple. En ese momento el desarrollador, administrador de base de datos o personal técnico, estaba cumpliendo horas extras, trabajando contra el reloj, con hambre y un sueño acumulado de más de una semana. No pensó claramente y ocurrió el accidente. La segunda  pregunta tiene una respuesta aún más simple. Cuando estamos realizando una operación rutinaria que hemos hecho cientos de veces tanto en los ambientes de desarrollo y pruebas como en el ambiente de producción, no nos imaginamos ni por un instante que algo va a salir mal.

Precisamente esto fue lo que ocurrió cuando un día antes del lanzamiento de un sitio web de noticias y opinión al desarrollador principal se le ocurrió crear la base de datos de desarrollo desde cero. Ya que estaba usando el framework Ruby on Rails, esto era una tarea tan sencilla cómo escribir en un terminal: rake db:drop; rake db:create; rake db:migrate y listo…

El trabajo de todo un mes de todo un equipo de periodistas, reporteros y redactores, desapareció en el instante que presioné “enter”.

Apenas piso la tecla, el terminal muestra un error, y es que no pudo ser creada la base de datos… Primer indicio de que hay algo malo y lo primero que pienso es: “Llevo días recreando la base de datos de esta forma, entonces ¿por qué acaba de fallar? Presto atención al típico mensaje de error de Rails que incluye una traza de mas de cien líneas y es cuando se me empieza a bajar la tensión… Si, me acabo de tirar la base de datos de producción… Puta madre, ¿ahora que hago? Les cuento lo que sucedió:

  1. 2:39 pm Llamé al líder de proyecto, me puteó.
  2. El líder de proyecto llamó al cliente, me puteó bastante.
  3. 2:58 pm Se me ocurre la genial idea de levantar un ticket en el área de soporte técnico del proveedor del hospedaje antes de ir a comer.
  4. 3:04 pm Me llama el líder de proyecto a notificarme el plan de acción.
  5. Al parecer muchos artículos los tenían guardados en otro lado, así que no se perdió todo. Encargate de restaurar el sistema y avisa para comenzar a cargar de nuevo. “Hoy no dormiremos, así que ve a almorzar primero”.
  6. Aunque no lo crean, fui a almorzar. Necesitaba despejar la mente para buscar una solución.
  7. 3:08 pm Responden mi solicitud de soporte técnico y me entregan una copia de la base de datos
  8. Reviso la fecha aproximada del respaldo. Era de un día antes… Bueno, mejor perder del trabajo de ayer y hoy, que perder todo el trabajo del mes completo.
  9. Volví a respirar, notifiqué al líder de proyecto, ya no me odia, notificó al cliente, aún me odia un poco.

Si hubiese tenido configurado respaldos diarios automáticos como hacemos todos los los buenos desarrolladores, nada de esto hubiese pasado. Bueno, probablemente se hubiese perdido medio día de trabajo. Pero eso es algo un poco más manejable.

¿Por qué no estaban configurados los respaldos automáticos?, ¿Por qué no había siquiera un respaldo manual? La respuesta es simple y -ahora que lo veo bien- estúpida. En ese momento mi pensamiento era que al no estar realmente en producción, el sistema no corría ningún peligro, “ni que yo mismo fuese a volar la base de datos”, apenas este terminado hago un respaldo inicial del sistema como se entregó al cliente en la fase final y configuro los respaldos automáticos de la base de datos.

Creo que no hay necesidad de decirlo, pero una vez restauré la base de datos, el segundo paso fue configurar respaldos automáticos.

Si se preguntan cual fue ese fantástico proveedor que tenía un respaldo automático de mi base de datos, el nombre es Webfaction y este es su sitio web: https://www.webfaction.com/

Anuncios
La Importancia de Hacer Respaldos Frecuentemente

Un comentario en “La Importancia de Hacer Respaldos Frecuentemente

Deja un comentario

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s