miércoles, 26 de noviembre de 2014

El Backup ... y la madre que lo parió.

Por lo general a la hora de diseñar (o improvisar) un sistema informático se suelen dedicar bastantes horas a pensar (¡ejem!) aspectos tales como para qué sirve, cómo se va a implementar, las interfaces con el usuario, la seguridad .... se dice que incluso se llega a pensar en los requisitos del usuario, pero claro, ese último aspecto suele estar por demostrar.

Ummmm ¿Ya está aquí el brasas este de nuevo?
Seguro que hay gato encerrado.
Al final a alguien se le ocurre decir "Oye ¿y qué pasa si se cae el servidor/se corrompe el sistema/si hay un virus/vamos, que se joda esto?" a lo que muy ufano el responsable/jefe de proyecto/analista/arquitecto/entero/cuñao dice todo ufano "Tranquilo, que hacemos un backup y todo controlado"

Lo más jodido de todo es que lo normal, es que le hagan caso y la gente se quede tan tranquila. La mayor parte de los usuarios piensan que backup es un ser mágico venido de Oriente que es capaz de solucionar todos sus problemas con aquella copia en discos de 5"1/4 que se hizo al principio de la explotación del sistema. Es como ese ser proceso mágico que pasaba la ropa sucia del suelo al cajón de armario toda limpia y planchada que nos pasaba a la mayoría cuando éramos adolescentes y que desapareció también mágicamente cuando nos íbamos de casa de los padres.

Pues resulta que no. El backup es un proceso complejo, costos y sobre todo NECESARIO ¿cual es la importancia de las copias de seguridad? Pues no es ni más ni menos que la importancia que le des a tu negocio/información/fotos de la comunión. Dependiendo de tu negocio un backup puede ser incluso un requisito legal aunque la ley no lo diga así. Por ejemplo, a una operadora de telecomunicaciones se le puede pedir un listado de los accesos de determinada persona hasta cierto tiempo (un par de años me parece) Claro que toda esa información se puede guardar en los sistemas transaccionales, pero el coste y ocupación es brutal (una operadora de telecomunicaciones genera millones de registros de llamadas CADA DÍA)
No solo pongo fotos de gatos. También chistes malos.

A la hora de diseñar el proceso de backup es conveniente pensar en algunas cosas:

- Qué información estoy dispuesto a perder. A lo mejor Facebook si pierde las últimas fotos que le han subido los usuarios no es muy grave, pero si un banco pierde los movimientos de los últimos cinco minutos puede que salga en el telediario. Obviamente, lo que se copia es lo que no se quiere perder que seguro que alguno ya está pensando lo contrario.
- Cuánto tiempo puede estar el negocio sin funcionar. En el ejemplo de antes, si se cae Facebook no pasa nada salvo algún ataque de histeria y/o suicidio a lo bonzo. Si se cae el banco unas horas posiblemente lo que menos pase es que el jefe de informática actualice su CV en LinkedIn y pase a "En búsqueda activa de empleo" La recuperación del servicio puede no ser sólo cosa del backup ... pero eso ya lo contaré cuando tenga ganas de escribir; llevo desde junio sin publicar nada ¿te piensas que el próximo va a ser inminente?
- Hasta cuando quieres guardar la información. Por lo general y salvo imperativo legal, la mayor parte de copias con retenciones altas solo sirven para ocupar espacio y recursos.
- Cada cuánto tiempo he de hacer el backup. Un periodo de tiempo demasiado largo puede hacer que el backup no sea muy operativo. Un periodo de tiempo muy corto puede machacar al sistema e incluso, hacer perder copias útiles con datos degenerados (degenerados por estropeados, no por eso que estás pensando)
- En cuántos sitios debo tener las copias. Esto ya va en función de la paranioa de cada uno. Yo personalmente considero que los datos delicados deben estar al menos almacenados tres veces: la original y dos copias separadas ¿esto te parece excesivo? Pues no te cuento el sudor frío que te entra cuando se degrada el original y sólo tienes una copia ¿funcionará? ¿no funcionará? Se puede hacer una copia a disco y otra a cinta. Personalmente, creo que las copias a cinta cada vez irán más en desuso. Los discos cada vez son mayores (10 Tb ahora mismo) y con técnicas como deduplicación y compresión la capacidad aumenta mucho y las cintas son más lentas, evolucionan más despacio y tienen la mala costumbre de fastidiar las unidades de lectura y escritura con el tiempo (no demasiado tiempo por cierto)

Una vez tenidos más o menos claros lo puntos anteriores viene la parte de rascarse el bolsillo ya que:
- El backup no se hace solo, hace falta un SW adecuado (hay soluciones OpenSource como Bacula) Ten en cuenta que una de las cosas más peliagudas del sistema de backup es saber lo que tienes dentro de los TB de información que has copiado y la gestión de ese catálogo es bastante pesada. Por otro lado, este SW suele permitir una cosa interesante: la recuperación granular, es decir, si has perdido un fichero a lo mejor prefieres recuperar ese fichero en lugar de pasarte varias horas recuperando todo el filesystem de una cinta. 
- El backup hay que dejarlo en algún sitio. Cintas, VTL, cabinas de discos. Salvo que sea de manera temporal, el dejar el backup en el mismo disco/servidor/cabina donde están los originales no una buena idea. Es equivalente a dedicarte a la escalada y atar la cuerda de seguridad que te sujeta por un arnés a tu propio tobillo. Mientras no te caigas no pasa nada pero como te caigas ...
- Hay que saber qué copiar. Si quieres copiar los datos de una BD seguramente el copiar el directorio /etc no sea una buena idea. También hay que saber cómo se pueden copiar las cosas.El copiar los ficheros de una BD en funcionamiento NO es una buena idea. Es posible que recuperar algo que no sirva para nada, al menos si no has puesto la BD en modo backup claro. 
- Hay que programar ventanas para hacerlo. Si tienes datos que se actualizan cada pocos segundos a lo mejor hacer una copia al mes no es lo más adecuado. También pasa lo contrario, no por hacer una copia cada cinco minutos (existe el caso, no me lo he inventado) vas a estar más protegido.

Por último, es recomendable si no es necesario recurrir al backup hacer pruebas periódicas de recuperación, al menos para asegurarse de que las cosas funcionan, el equipo humano sabe recuperarlo, etc.

No hay comentarios: