Hace pocos días me han nombrado un nuevo jefe en el área de Operaciones. Quizás en una inocentada personal o falta de organización de tiempo, no había desarrollado el DRP (Data Recovery Plan o Plan de Recuperación de Datos), cuestión que es básica y esencial a la hora de mantener operativo el negocio tras un desastre, sea cual sea la magnitud y origen del problema. Claro, uno piensa solamente en que un servidor deja de prestar servicios, pero también hay otro tipo de desastres no tan obvios.

Un ejemplo de esto último fue escrito por Mario Tello, quien narró su historia de terror en el Datacenter, la cual principalmente narra que se le indundó el Datacenter con agua desde un retrete que estaba en el piso superior a la planta de servidores. También recuerdo la historia de las empresas que tenían sus datacenter en subterráneos y el Huracán Katrina dejó nadando los discos en agua.


La imagen del terror en persona: hardware acuático

Quizás ambos desastres no son evidentes a primera vista, pero a la larga son desastres: ¿qué ocurre en caso que se queme las instalaciones?, ¿qué ocurre si se corrompe una unidad de red en un servidor que está fuera del anillo del datacenter?. Ambas preguntas deben ser respondidas en el DRP.

El DRP como carta de navegación

El DRP no es la última piedra angular de la recuperación del negocio, pero sí permite identificar procedimientos, tareas y responsables de realizar acciones para que la continuidad del negocio no se vea afectada por la contingencia que gatilla la recuperación.

Lo más importante de este DRP es que debe ser realista en tareas, tiempos y procedimientos, ya que las acciones antes (backups o respaldos), durante (habilitación de servidores de urgencia) y después (proceso post-mortem o documentación), permite madurar un proceso de recuperación más o menos estándar dentro de la organización.

Por ejemplo, una base básica dentro del proceso de creación el DRP es documentar pasos y procesos para levantar un servicio desde una consola; montar una máquina virtual en VMware dentro del mismo servidor (sin storage en la nube) o simplemente cómo chequear si un servidor está operativo o no.

Respalda, respalda, respalda…

Y sigue respaldando. El día de mañana el disco duro morirá… es un hecho, todo tiene un tiempo de vida limitado (o más bien llamado MTBF), el cual dicta que tarde o temprano fallará un sistema y deberemos reemplazar.

La organización debe definir sus propias políticas de respaldos, las cuales debes seguir bien detalladamente, ya que un error o cambio dentro del proceso puede provocar que el DRP quede inválido, y ante una emergencia real, se pierda tiempo valioso en adaptar un proceso no escrito a la nueva forma de almacenar.

Como sugerencia: un respaldo en un medio WORM (Write Once Read Many) ayuda a la hora de restaurar un backup que no dependa de un medio magnético de lectura (por lo cual entiendo que es un DVD, HD-DVD o similar).

Aparte de respaldar, prueba tus respaldos: deja un día al mes o semana (dependiendo de lo crítico de los datos) para chequear el archivo que contiene el respaldo (por ejemplo: zip, rar, tar, etc.), ya que no es ninguna gracia que a la hora de acceder al archivo se encuentre corrupto o no puedas usar la herramienta de compresión que usaste originalmente por que tienes una versión más antigua a mano.

Ensaya

Más allá de hacer respaldos a lo loco, otra sugerencia práctica es que ensayes los desastres: pon un escenario y toma tus manuales, archivos y el DRP, y colocate a restaurar archivos y aplicaciones en ambientes de desarrollo o testing, con el fin que puedas determinar si el plan está completo, faltan pasos o hay que adecuarlo para incluir más recursos y tiempo.

Sin ese ensayo, a la hora de recuperar la información, no habrá estimación de tiempo ni mecanismos para asegurarnos que estamos haciendo lo correcto.