Muchos ríos de tinta se han escrito sobre los backups, los sistemas de recuperación de desastres y los de continuidad del negocios. Son todos relacionados, pero muy diferentes y en muchos casos interdependientes.

Hoy me enteré que JournalSpace.com había salido del negocio del “personal authoring” (proveedor de espacio para blogging). Al parecer la causa es un mal diseño de esas 3 cosas mencionadas.

Cuando se trata de evaluar cual es más importante que la otra, me animo a decir que el backup es superiormente más importante que las demás. Porque lo peor que puede sucederle a tu compañía, es lo que le sucedió a esta empresa, perder datos.

Sin embargo, cada opción debe ser evaluada de forma independiente y deben estar escritos y probados los 3 métodos.

Continuidad del negocio

Continuidad del negocio significa que el servicio que se brinda estará disponible durante todo el tiempo que se indique en la SLA (Service Level Agreement). Es importante que para cada servicio brindado, se establezca entre el centro de cómputos y el cliente, cual será la ventana de tiempo o el porcentaje de tiempo que se acordará.

Una mala decisión de tiempo es decir 24x7x365 porque generalmente eso no se puede cumplir. Sin embargo, si se puede cumplir con algo del estilo: 99% uptime de 7:00 a 20:00. 90% uptime de 20:00 a 7:00. Esto deja unos 8 minutos, tiempo suficuente para que un servicio se reinicie durante las horas de trabajo, para corregir un deadlock en la base de datos y deja una hora en la noche para bajar servicios y hacer backup.

Obviamente que en cada empresa y para cada servicio, estos tiempos tienen que ser ensayados.

¿Pero que pasa si se nos rompe algo físico o surge un clásico problema “de fuerza mayor”? La SLA debe especificar que eso es un caso de “Recuperación de desastres”.

Recuperación de desastres

Con la Virtualización de Servidores logramos una herramienta estupenda para implementar Recuperación de desastres. Con esto, recuperar un servidor es traer la última copia de la VM y levantarla, eliminando la dañada.

Claro que hay un tema vital a tener en cuenta. ¿Dónde se almacenan esas VM y cuánto tardarem0s en recuperarlas desde el repositorio de respaldo? Todo eso debe estar previsto, o nuestro fenomenal sistema de Recuperación de desastres no funcionará.

¿Pero si no tenemos nada virtualizado? ¿O lo que se rompe es un disco del servidor de VMs?

Los sistemas de RAID son la primer línea de ataque al problema, pero no lo son todo. Me han tocado casos de un servidor donde no se quiso invertir demasiado en hardware y se implementó RAID por software en discos ATA. A la semana de establecer el Espejo (RAID 1), la copia se desincronizaba y nadie se daba cuenta que el RAID no funcionaba.

En otros casos, se rompieron 2 discos a la misma vez de un servidor con una placa RAID y discos SCSI, resultando que se perdieron todos los datos. El servidor no tenía más de un mes de instalado y se había cancelado la compra de la unidad de cinta “porque costaba casi mil dólares”.

La gente de JournalSpace.com tenía un RAID 1 que funcionaba muy bien. No estaban preparados para el peor de los males: el sabotaje.

Respaldos de datos

Los respaldos a cintas o a unidades ópticas sin duda son lo más básico de implementar. Y por eso un sistema eficiente de respaldos puede salir tanto o más caro que el mismo servidor.

La desventaja que encuentra la gente que cree que un sistema RAID es una forma de ahorrarse el backup, es que los backup tardan mucho, ocupan mucho y cuestan mucho. Sin embargo, un sistema de recuperación de desastres no es un sistema de respaldos. El caro error de JornalSpace fue esto mismo, como dicen en su página actualmente: “As data is written (such as saving an item to the database), it’s automatically copied to both drives, as a backup mechanism” [en español: "cuando los datos se escriben (como cuando se guarda algo en la base de datos), se copian automáticamente al otro disco, como un método de respaldo"].

Sin embargo, si es cierto que si todo ha salido “no tan mal”, es más sencillo volver a estar en línea desde un sistema de recuperación de desastres que desde un backup.

Para implementar un sistema de respaldos se deben evaluar: todos los datos que usan las aplicaciones, la periodicidad de cambio, la ubicación donde se guardarán y las aplicaciones que los usarán.

En muchos casos se respaldan cosas que no son necesarias o se obvian cosas que deberían respaldarse. El caso de JournalSpace.com fue esto último. Respaldaban el sitio web con los archivos PHP, pero no respaldaba la base de datos!

Conclusión

Espero que en el futuro, todo gerente, director y dueño de pequeñas y medianas empresas esté más al tanto de los costos de las pérdidas de datos, de los métodos de respaldo y recuperación y de la importancia de invertir en ellos.

Los casos que he visto de pérdidas y recuperación de datos en Uruguay han sido porque los dueños de las empresas no han querido gastar en unidades de cintas o discos más grandes. Y cuando sobreviene el siniestro, la culpa la tienen los de IT.

Lamento informarles que no es así, sino que hay una relación muy directa entre la cantidad de recursos que se dedican a dichos sistemas y la efectividad que tienen. Tanto es así que considero que en cada empresa que tenga más de 1 servidor con correo electrónico o bases de datos, debería tenerse a una persona exclusiva para implementar estos tres puntos. Y que no debería además de estar programando, instalando PCs, ayudando a usuarios con Excel y llamando a proveedores para preguntar precios de centrales telefónicas.

¡Nos vemos en el próximo desastre!