Archivo de la etiqueta: backups

Usando Amazon S3 como sistema de backup

Proyectos, Sistemas, Técnico, , ,

Estoy tratando de mejorar el sistema de backups que utilizo habitualmente usando Amazon S3 como plataforma de almacenamiento. S3 (así como otros servicios Cloud de Amazon) tienen dos ventajas importantes, por un lado la disponibilidad, del orden del 99,99% y por otro el precio, altamente competitivo, cobran por espacio utilizado y por peticiones realizadas pero aún así sale por un precio espectacular.

Nuestro backup es del orden de 40gb, y, si el sistema va bien, planeo utilizarlo también para backups personales (fotos sobre todo :P).

El requerimiento básico es que la sincronización se realizará de manera automatizada desde un servidor Linux con lo que el sistema debe permitir el envío desatentido.

Buscando por ahí como hacerlo encontré FuseOverAmazon, un sistema basado en Fuse que permite montar un “bucket” de S3 como si fuese una unidad local y sobre la que posteriormente podríamos utilizar rsync. ¿Qué más se puede pedir? Dicho y hecho, vamos a probarlo. En mi caso utilizo CentOS.

yum install fuse fuse-devel curl-devel libxml2-devel
wget http://s3fs.googlecode.com/files/s3fs-r191-source.tar.gz
tar xvfz s3fs-r191-source.tar.gz
cd s3fs
make
make install

Vamos a probarlo.

/usr/bin/s3fs nombrebucket -o accessKeyId=TUACCESSKEYID -o secretAccessKey=TUSECRETKEY /mnt/s3

Si todo ha ido bien tendrás montado en /mnt/s3 tu “nombrebucket” y podrás listar los archivos, copiar, eliminar, etc., como si fuese una unidad del equipo. Hasta aquí todo ha ido bien.  Sólo nos queda sincronizar nuestro backup:

/usr/bin/rsync -avz --delete /usr1 /mnt/s3

Y aquí es donde viene el problema. En mi caso han pasado 4 días y aún no ha pasado del 10% de la sincronización, funciona todo bien pero la sincronización es extremadamente lenta, no sé si estoy haciendo algo mal, si es normal, o no, pero es imposible de utilizar así.

Como la idea no ha sido del todo buena, tenemos un plan B. Se trata de utilizar s3sync, un script en Ruby que hace el proceso muy sencillo, sólamente hay que configurarlo indicando tus datos de acceso y a funcionar:

s3sync -r /mnt/backup nombrebucket:prefijo

Donde “prefijo” puede ser nulo.

Esto enviará a nombrebucket/prefijo/ tu backup.  De momento las pruebas son mucho más satisfactorias que con s3fs, la velocidad se puede considerar más que adecuada, sobre todo comparada con el anterior.

Como decía, de momento estoy probando el rendimiento y la velocidad, pero no estoy del todo convencido, así que estoy pensando en utilizar Amazon EC2 en vez de S3, de manera que lanzando una instancia de una máquina virtual pueda hacer un rsync clásico contra un sistema de ficheros de verdad. La ventaja es que la máquina virtual puedo lanzarla sólo cuando la necesite y pararla después, con lo que con una hora diaria podría ser suficiente, recordemos que Amazon EC2 cuesta, entre otras cosas, por cada hora que utilizas la instancia. Adicionalmente se podría hacer después un volcado del backup desde EC2 a S3, pero en nuestro caso los 40gb sería una limitación que encarecería el precio considerablemente aún en el caso de utilizar rotaciones semanales.

Ya os contaré :P.

Copias de seguridad de bases de datos

Bases de Datos, Sistemas, Técnico, , ,

A través de Pensamientos Ágiles llego a un artículo donde explican una interesante manera de hacer backups de bases de datos Mysql utilizando subversion. La idea es excelente, pero me plantea una serie de dudas si se trata de bases de datos de gran tamaño. Creo que es genial para mantener la estructura de la base de datos de un proyecto y tener controlados los cambios que se realizan sobre ella, pero mantener también los datos… no acabo de verlo.

En uno de mis proyectos tengo una base cuyo dump ocupa alrededor de 1Gb. Yo, sinceramente, no veo coherente mantener semejante archivo en svn. La idea es excelente y para bases de datos “pequeñas” creo que sí es útil, habría que decidir, en todo caso, qué entendemos por “pequeñas“. Pero insisto, no lo veo para archivos grandes, y 1Gb, tengamos el criterio de grande/pequeño que tengamos, es un archivo grande.

Normalmente lo que hago para hacer los backups es sacar un dump de cada base de datos, de manera que pueda recuperar cualquiera de ellas, y comprimir el resultado con bzip2. ¿Por qué bzip2 y no gzip? Simplemente por el nivel de compresión. En su día hicimos pruebas con ámbos sistemas y bzip2 salía mejor parado. Éstos son los resultados que obtendríamos hoy en día con la compresión estándar de ámbos sistemas:

-rw-r--r--   1 osus   users  1023246033 Feb  2 01:50 bbdd.sql
-rw-r--r--   1 osus   users   141481434 Feb  2 01:50 bbdd.sql.bz2
-rw-r--r--   1 osus   users   190733372 Feb  2 01:50 bbdd.sql.gz

Con bzip2 el backup pesa unos 50mb menos.

El script que utilizo para hacer backups de base de datos es más o menos lo que suele hacer la mayoría de la gente:

#!/bin/sh
dia=`date +%w`
for i in ` /usr/bin/mysql -N --execute='show databases;' `
do
echo "Haciendo backup de $i"
/usr/bin/mysqldump -C --opt $i > /backup/bbdd/$dia/$i.sql
bzip2 -fz /backup/bbdd/$dia/$i.sql
done

En otras palabras, mantengo las copias completas de los últimos siete días, semanalmente se se reemplazan por las del día en que nos encontramos. En la carpeta del día correspondiente genero los dumps comprimidos de todas las bases de datos.

El último paso es copiar los dumps del día a otra máquina. La tarea que se ejecuta diariamente lanza el proceso una vez termina de crear los backups. Esto lo hacemos a dos máquinas distintas. La primera es una máquina externa y se envían por ssh desatendido, utilizando claves públicas, de manera que la máquina remota no solicita la clave del usuario. La segunda es una máquina de nuestra oficina con la que tenemos una vpn que se levanta antes del backup, se copia con ssh destendido también y se cierra al terminar. En ésta máquina de la oficina hay otra tarea que diariamente restaura el backup de ciertas bases de datos en su Mysql local matando así dos pájaros de un tiro: por un lado tenemos la base de datos de desarrollo casi idéntica a la de producción, faltarían sólamente los últimos datos del día, y por otro lado nos aseguramosn de que los backups que se realizan son correctos ya que en caso contrario fallaría la restauración.

Hasta ahora nos ha funcionado bien el sistema. En alguna ocasión hemos tenido que recuperar alguna tabla de ciertas bases de datos y no hemos tenido excesivos problemas, todo ha funcionado a la perfección.

Vuelvo a repetir que esto no es una crítica al sistema del subversion, todo lo contrario, la idea me parece cojonuda, pero creo que habría que puntualizar o estudiar bien la viavilidad en ciertos escenarios.

Sobre incendios, CPD’s y otros desastres naturales

General, Negocios, Proyectos, Sistemas, Técnico, , , ,

Supongo que a estas alturas ya la mayoría os habréis enterado del incendio ocurrido en uno de los CPD’s (centro de proceso de datos) que The Planet tiene en Houston, Texas. Al parecer la causa del incendio fué la explosión de uno de los transformadores que dan servicio al CPD. Debido al incendio se tuvo que cortar completamente sl suministro eléctrico del centro provocando con ello el apagado de unos 9.000 servidores, entre ellos los DNS principales de la antigua EV1, había servicio de respaldo pero los bomberos obligaron al corte completo como medida de seguridad. Creo que han tardado algo más de 24h en restaurar completamente el servicio, desde el foro se pudo seguir la evolución de la incidencia.

El CPD en cuestión era uno de los que EV1 Servers tenía cuando fue adquirida por The Planet hace un par de años y el más antiguo de la compañía.

Pues bien, nosotros tenemos servidores en The Planet desde 2002, de hecho teníamos servidores en ese CPD de EV1 hasta agosto del año pasado cuando, gracias a unas buenas ofertas, los migramos a nuevas máquinas y con ello cambiamos de centro de datos, ahora estamos en Dallas, sino ahora mismo seríamos uno de los afectados.

He leído mucho estos días acerca de lo ocurrido. He llegado a leer si realmente vale la pena llevarte la infraestructura a USA cuando puede ocurrir esto que ha ocurrido. Y yo me pregunto, ¿acaso esto no podría ocurrir en España? Esto y mucho más 😉 , los problemas son independientes del lugar, si no es un transformador el que explota es una regleta que se quema, una fuente estropeada o un router colgado. También podría ser otra máquina con la que compartes RACK y/o router que ha sido atacada o mil historias más, ¿verdad Raúl?, pero problemas los hay en todas partes. ¿Acaso por tener tus máquinas en un CPD de Logroño estando tú en Valencia vas a resolver algo que no podrías resolver si están en USA? La respuesta es obvia a no ser que tengas enchufe y te vayan a tratar antes y mejor por ser tú, cosa poco probable para la mayoría. Lo que debes pensar es en tener gente detrás que vaya a solucionarte los problemas que tengas y que no puedas solucionar tú.

Nuestra experiencia, tanto en EV1 primero como en The Planet después, es inmejorable. Rápida respuesta a los pocos problemas que nos han dado, avisos con semanas de antelación de ventanas de actuaciones, soporte rápido y eficaz, etc. Cuando hemos tenido algún problema más grave han hecho las cosas con profesionalidad y siempre preguntando primero, reinicios manuales, fsck’s controlados, cambios de cables de discos defectuosos que estaban provocando problemas, etc. En una ocasión incluso se hizo el cambio de un disco defectuoso con dos parones de unos 5 minutos cada uno, el disco no había dejado de funcionar, simplemente lanzaba errores esporádicos de lectura/escritura. En una parada añadieron un disco duro para que lo preparásemos todo y en la siguiente reemplazaron el original por la copia. Todo funcionó a la perfección y en 24h se cambió un discon sin afectar al servicio. Reconozco que también puede ser que hayamos tenido algo de suerte 🙂 .

Profundizando un poco más en el asunto, el incendio de The Planet es sólo uno de los problemas que pueden ocurrir y ante los que apenas hay opciones de protección. Recordemos casos como el del Edificio Windsor de Madrid donde había ni más ni menos que un CPD de Colt Telecom, o las inundaciones en Louisiana tras el Katrina donde todo quedó arrasado y devastado. Nadie ni nada puede asegurar que sus servidores estarán seguros 100% y que nunca ocurrirá nada. Por contra, tú si que puedes asegurar que estarás protegido ante estas situaciones y así poder minimizar los efectos. En función del presupuesto de que dispongas podrás estar mejor o peor preparado, pero lo básico es muy barato y sencillo.

Si tu presupuesto lo permite, lo mejor es, sin duda, tener siempre un CPD de respaldo con toda tu infraestructura de producción duplicada, actualizada y preparada para entrar en producción cuando la principal se venga abajo. Obviamente esto es un gasto que casi nadie va a ser capaz de justificar ante sus superiores.

Si, como la mayoría, no puedes permitirte un CPD de respaldo, mantén una buena política de copias de seguridad y un plan de contingencia bien documentado y actualizado. Si lo haces bien, en apenas unas horas podrás tener levantado desde cero una máquina que haya fallado. NO, repito, NO confíes en los RAID1 (espejo) y ve con cautela con los RAID5, he visto muchos servidores completamente perdidos por culpa de la controladora RAID. ¿De qué sirve tener un RAID1 bien chulo si al petar la controladora se van los dos discos a paseo? A la hora de hacer tus backups ten en cuenta que no sólo necesitas los datos propiamente dichos, sé previsor y guarda todos los archivos de configuración y scripts que te has ido haciendo con los años y que sigues utilizando. Documenta en el plan de contingencia cada detalle que estimes oportuno para restaurar el servicio. Apunta cada cambio que haces en la configuración de cada servicio. ¿De qué te va a servir tener todos tus datos si no has guardado la configuración de Apache y ahora tienes que crear uno a uno todos los Virtual Hosts?

Finalmente, aunque parece evidente, llegado el momento muchos se olvidan. Distribuye tus copias de seguridad. NO tengas el backup en el mismo CPD y mucho menos en la misma máquina. A ser posible almacena los backups en varios sitios. A mi me gusta hacerlo en otro CPD bien alejado del de producción y en tus oficinas.

Como último consejo, pon en marcha el plan de contingencia al menos una vez al año. Coge una máquina limpia, tu plan de contingencia y mide el tiempo que tardas en tenerlo todo online y revisa los problemas que te van surgiendo. Alimenta con esta experiencia tu plan de contingencia para hacer frente a posibles imprevistos llegado el momento.

Eso es todo amigos, ojalá nunca tengáis que poner en práctica el plan de contingencia 😛 .