No mas planes de respaldos y comencemos a planear estrategias de recuperacion a desastres

Imagen de kenneth

Votar: 

Average: 5 (7 votes)

Esta es sin lugar a dudas la peor forma de engañarnos nosotros mismos como responsables de entornos productivos. Muchos creen que porque se estan realizando los backups de la base de datos, todo va a estar bien. 

Y de hecho es parcialmente cierto, de ahi que sea el engañarnos a nosotros mismos, Porque una vez que tengo mi estrategia de recuperación de errors diseñana y constantemente practicada, el hecho de que mis respaldos se esten realizando es crucial para poder ejecutarla, el problema biene cuando los DBA's poco comprometidos, solo se preocupan porque los backups se realicen, sin saber si sirven, sin saber si la integridad de la información esta aceptable, sin saber tiempos estimados de recuperacion que puede tomas y aun mas importante, cuanto es mi Acuerdo de aceptación de perdida de datos con la parte de negocios de la compañia que la afectación de la operacion misma no se va a ver fuertemente afectada en caso de enfrentar un desastre en la base de datos.

¿Qué es lo que busca mostrar este post?

Para mí seria un gran logro si pudiera influenciar al menos una persona que cambie el modelo de generación de backups que ha venido haciendo por años a un esquema orientado a recuperación de desastres.

¿Cómo vamos a abordar el tema?

Pensar en recuperación de desastres en un solo post es algo complicado debido a lo denso del tema mismo, por lo que mi propuesta es dividirlo en varios subtemas, tal y como se muestra a continuación:

  • ¿Qué es una estrategia de recuperación de desastres?
  • Entendiendo mis necesidades de respaldos
  • Diseñando mi estrategia de recuperación de desastres.
  • Probando y mejorando mi estrategia de recuperación de desastres.

¿Qué es una estrategia de recuperación de desastres?

Una estrategia de recuperación de desastres desde mi punto de vista debe cumplir con los siguientes atestados:

  1. Debe de estar libre de puntos únicos de fallo (Single point of failure free)
  2. Cada uno de los componentes tiene que estarse verificando/monitorenado contantemente.
  3. La integridad de los datos tienen que garantizarse a la hora de la verificación(como mínimo).

Debe de estar libre de puntos únicos de fallo (Single point of failure free)

Este es el típico escenario en el que se realiza un full backup semanal, y para guardar el nuevo full elimino el anterior para "ahorar espacio". Si esto te es familiar, preguntese lo siguiente, ¿Qué pasa si ese respaldo falla a la hora de restaurarse?, ¿Cuál es el plan de contingencia? (Aparte de buscar otro trabajo). Si no tiene respuestas concisas en las cuáles esas preguntas ya le comenzaron a preocupar, en inclusive lo pusieron nervioso, entonces usted mi amig@ puede o que no entienda la estrategia de recuperacion de desastres de la empresa o simplemente esa no existe.

El fallo de restaurar un respaldo así sea el full, solo puede significar una cosa, un retraso en el tiempo de recuperación de la base de datos, mán nunca la imposibilidad de recuperar la base de datos, aunque infringa en una mayor perdida de datos de la estimada.

Cada uno de los componentes tiene que estarse verificando/monitorenado contantemente.

Si yo estoy realizando backups y no estoy constantemente verificando los mismos, ya sea restaurandolos en otro servidor o corriendo un restore verify, ¿qué me asegura a mi que ese backup se esta escribiendo bien?. Y esta leccion la aprendi (como decimos en Costa Rica) por cabeza agena. El DBA del momento relizaba los backups y directo en un software de tape. Un día el servidor principal fallo, y se recurrio a los famosisimos backups. pues cuando se fue a ver, estos no servian, la herramienta de tape habia escrito 0's. y tenia 300GB del tape llenos de puros 0's. Lo cual dejo a la compañia en una posición muy fragil.

Bueno este es otro punto unico de falla, sencillamente porque tenemos un software que hace los respaldos por nosotros, no significa que la responsabilidad es del software. Esta sigue siendo de nosotros. Verifiquemos que lo que estemos respaldando, sirva.

La integridad de los datos tienen que garantizarse a la hora de la verificación(como mínimo)

Colegas, hay algo que se llama checkDB, por favor ejecutenlo en la base de datos, si no tienen los ciclos para ejecutarlo en produccion antes de realizar el full, ejecutenlo en un servidor secuntario despues de restaurar al menos el full. Que situación mas comprometedora va a ser si despues de horas de estar recuperando un backup, nos damos cuenta que este tiene corrupción. Esto va a agrabamar muchisimo la situacion de desastre. y la siguiente pregunta que nos van a hacer, una vez que esto pasa es ¿Y cuánto va a durar checkDB corriendo?. 

Muchas veces estas estrategias fallan por falta de conocimiento o por falta de ganas de trabajar en los entornos de produccion.

Si usted cree que esta mas en la parte de falta de conocimiento. Le invito a que lea los proximos posts, en los cuales voy a entrar mas en detalle hacerca de backups. Mas por el contrario, su problemas es el "No tengo tiempo para planear desastres", pues permitale invitarle a que busque tiempo para planear cambio laboral por lo menos, ya que si un desastre se le presenta, las probabilidades de que tenga que buscar trabajo ... son altísimas.