Publi

Y tú, ¿cuándo fue la última vez que hiciste una copia de seguridad de tus servidores?

seguridad

En este post me quiero dirigir a todos aquellos que administráis un servidor, una web o un blog. Son los grandes olvidados, las copias de seguridad. Esas que nadie tiene en cuenta, esas que todos ignoran, las que siempre se dejan para luego y las que nunca es un buen día para hacerlas. “Da mucha pereza”, “cuando suba estos cambios me pongo”… luego pasa un tiempo y ni te acuerdas hasta que un lluvioso y fatídico día de otoño, de esos que es mejor no levantarse de la cama, te falla la conexión a Internet, tienes 100 cosas que hacer, y parece que estás mangando un resfriado. De repente, tu blog no funciona, el servidor se ha caído ¡ y no puede levantarse ! y empiezan a lloverte mensajes por Facebook, por Whatsapp, te llaman por teléfono repetidas veces (lo que nadie sabe es que mientras estás al teléfono no puedes estar arreglando nada) y te das cuenta de que algo terrible ha sucedido: ha habido un fallo de hardware, tu servidor ha sido infectado por un ransomware, que alguien (porque uno mismo nunca tiene la culpa) ha utilizado DELETE sin el WHERE, o que haya caído un rayo en el centro de datos donde tienes tu alojamiento y tengas que llevarte los datos a otro sitio. En definitiva, siempre echamos de menos un buen sistema de copias de seguridad cuando realmente lo necesitamos.

Los ingredientes del sistema

Y es que los sistemas de copias de seguridad, consumen recursos, hacen que todo vaya mucho más lento y raramente se utilizan. Es más, ahora casi todos tenemos discos SSD en nuestro servidor. Los discos SSD nos dan una velocidad de lectura y escritura enormes, pero claro, las operaciones de nuestras webs también han aumentado, y seguramente nuestros visitantes, por lo que el uso que hace un sistema de copia de seguridad de disco tiene que hacer poco ruido, o al menos hacerse a una hora en la que no estemos utilizando intensamente los servicios.
Por otro lado, el espacio ocupado por estos sistemas se ha incrementado exponencialmente. Hace 12 años teníamos una web que ocupaba 200Mb y nos quejábamos porque el espacio en servidor era caro, y esos 200Mb en nuestro disco duro también se notaban. Ahora todo ocupa mucho más. Por ejemplo este blog se va acercando a los 4Gb. Con esto quiero decir que cuando hacemos la copia de seguridad debemos comprimirla y, además, no podemos copiar siempre todo, es decir, se recomienda hacer copias de seguridad incrementales.
Las copias de seguridad incrementales necesitan un punto de partida que, por ejemplo, puede ser una vez a la semana, pongamos los domingos (que suponemos que es cuando menos visitas tenemos), luego todos los días crearemos una copia de seguridad en la que sólo guardaremos las diferencias con respecto a nuestro punto de partida. Podemos probar esto, por ejemplo, con tar:

tar cvjpf /backup/copia_20161104.tar.bz2 -g /backup/snapshot ~/www/miweb

La primera vez que lo ejecutemos creará un archivo tar.bz2 completo y guardará en snapshot todo lo que ha hecho. La segunda vez se compara lo que hay actualmente con este snapshot y se guarda sólo lo nuevo (actualizando también el snapshot para la siguiente copia).

Un buen sistema de copias de seguridad debe ser automático y resolver problemas. El proceso de creación de copias debe ser automático, todos los días a una determinada hora es una buena idea, debemos tener en mente que tendremos un RPO (Recovery Point Objective) de 1 día, lo que quiere decir que en caso de pérdida de datos, tras una restauración se han podido perder datos generados durante un día. Datos que se podrán recuperar (por ejemplo si son posts de tu blog, puedes tenerlos almacenados en tu ordenador, o puedes incluso volver a escribirlos), o serán irrecuperables (si son las estadísticas de visitas, e-mails que no has llegado a ver, etc). También tiene que resolver problemas, por ejemplo, si al realizar la copia de seguridad se produce un fallo o una desconexión, el sistema automáticamente podrá intentarlo de nuevo, si se comprueba la copia y esta no coincide, volver a intentarlo, y por último notificar al administrador si el sistema no encuentra una solución a su problema.

El sistema debe tener alta disponibilidad. No vale de nada que cuando esté haciendo la copia de seguridad tenga que pararlo todo. Es decir, paro la web, pongo una pantalla de mantenimiento (en el mejor de los casos) y cuando termine de copiar quito el mantenimiento y levanto mi web. Pueden transcurrir varios minutos para realizar la copia y serán minutos en los que no pueda entrar nadie y si tienes servicios como el correo en ese mismo servidor, tiembla más por lo que puedes perder. A veces, realizar una copia de esta forma (se suele hacer cuando haces imágenes completas de disco) es muy fácil y luego restaurarla también, pero dado que tanto la copia como restauración tarda más cuanta más información se copie, a poco que crezca tu servidor, puedes perder muchísimas visitas.

El sistema debe ser seguro y confiable, como dijimos antes, la copia de seguridad debe comprobarse, es decir, verificar que el fichero se puede leer y no hay fallos. Además, es conveniente que estas copias se cifren y permanezcan cifradas, porque no sería la primera vez que una brecha de seguridad aprovecha la información de una copia de seguridad (puedo decir seguridad 10 veces más y estaremos igual de expuestos) para hacer estragos en nuestra información. Si tienes un blog en WordPress, ¿para qué quieres esto? Sencillamente para proteger tu contraseña de usuario (ya cifrada, pero no es imposible descifrar), la contraseña de base de datos, y de las APIs a las que conectes (algunos plugins de Facebook, Twitter, y otros servicios).

El sistema debe replicarse. De nada sirve hacer una copia de seguridad en un servidor y dejarla ahí. Si por ejemplo, hay un fallo de hardware en tu servidor y deja los discos inservibles, ahí tenías la copia de seguridad y la has perdido igual, por lo que es interesante que ésta se copie a otro servidor, o si es una web personal puedes hacer un pequeño script que se descargue la copia todos los días y la guarde en tu ordenador, o en una Raspberry PI, ya como quieras. Eso sí, cada vez que cambie un fichero de sitio es importante hacer una suma md5 o sha en origen y destino y compararlas, para que veamos que el archivo se ha copiado exactamente igual.

Además, el sistema debe poder seleccionar qué restaurar. Está muy bien tenerlo todo en un archivo enorme de tu servidor, en 35Gb de archivo (hablamos de una web / servidor modesto) tengo webs, bases de datos, correo, configuración (importante guardar la configuración de tus servidores, gran olvidada), pero ahora quiero restaurar sólo la base de datos, es más, un schema determinado de base de datos, o ciertos archivos del servidor web. Nuestro sistema debe permitir hacer esa descarga de la forma más rápida posible sin hacer que la copia deje de ser manejable o utilice muchos más recursos de los necesarios. Es más, deberíamos poder restaurar por lo menos el estado de nuestros sistemas en cualquier día dentro de por lo menos una semana (porque no siempre descubrimos los problemas nada más ocurrir).

Los grandes sistemas de backups

network-cables-499792_1280
Hasta ahora hablábamos de un sistema pequeño, un servidor, dos, o un pequeño cluster donde alojar alguna aplicación web. Pero claro, cuando tienes un datacenter con miles de servidores ya estamos hablando de otra cosa. Normalmente un centro de datos suele utilizar replicación en todo momento. Es decir, en lugar de un disco SSD para alojar un servidor tiene dos (o más) y automáticamente mantienen los mismos datos, de modo que si falla un disco duro, un operador se acerca a la máquina física donde está el problema, retira el disco defectuoso y coloca uno nuevo (esta operación en muchos casos se puede hacer incluso en caliente, sin apagar nada, para que el servicio no se pare ni por un segundo. Lo mejor es que los usuarios que visitan la web no se han enterado de que ha fallado un disco duro, ni lo harán, porque en datacenters grandes es muy común que haya fallos de este tipo todos los días. Sólo por estadística, de todos los discos que he comprado en mi vida un par de discos han salido malos (un 10% así a ojo), imaginad lo que pasaría cuando gestionas decenas de miles de discos a los que les estás dando un uso intensivo.
Otra forma de replicación es por equipos, es decir, servidores de bases de datos enormes, destinados al Big Data, en los que por supuesto que la información que manejan estas bases de datos no cabe en un disco convencional (podemos hablar de Petabytes), dicha información estará repartida en varios servidores, pero a su vez, cada fragmento de información estará replicado también en varios servidores por lo que si un nodo completo se quema no pasa absolutamente nada, se compra un nodo nuevo, se enchufa a la red y automáticamente obtendrá los datos que debería tener. Y nadie ajeno al centro de datos se ha enterado de nada.

Pero entonces, en un sistema así, ¿tiene sentido hacer copias de seguridad? Siempre tiene sentido, los errores suceden, los desastres naturales también, y los desastres humanos mucho más. No vamos a decir ahora que es algo barato, es cierto que en la actualidad, en pleno auge de discos SSD, los discos magnéticos son muy baratos (por el precio de un SSD me puedo comprar 8 discos magnéticos), y podemos aprovechar a hacer copias en discos magnéticos porque hay mucha información que copiar, al estar utilizando información comprimida o incluso por red no va a ir mucho más lento y la entrada/salida no va a ser el cuello de botella de mi sistema.

Eso sí, diseñar un sistema que automatice las copias de un centro de datos es un trabajo muy duro, y luego un proceso de restauración que cumpla con los parámetros aceptables, es complicado y no siempre se consigue. Dadas las veces que se hace una restauración, que suele ser tras una serie de catastróficas desdichas (por ejemplo que fallen todos los discos donde está replicada la web de un cliente), no se suele trabajar mucho en la velocidad de las mismas, por lo que podríamos tener a nuestro cliente sin servicio casi todo un día.

Una amarga experiencia personal

Hago este pequeño inciso en el post para comentar algo que me pasó hace mucho tiempo. Ocurrió con un hosting compartido donde tenía una web con bastantes visitas diarias. De repente, un día la web había sido suplantada. Aparecía la cara de una persona con actitud beligerante y mensajes de que la página había sido hackeada. Me di cuenta de que todos los archivos del servidor tenían un pequeño script al final que replicaba esta web de nuevo en todas partes.
Tras ponerme en contacto con mi proveedor de aquel entonces me dijo que la culpa fue de un Drupal desactualizado que fue aprovechado por los atacantes para causar estragos en el servidor, que compartíamos unos 200 clientes. El problema sucedió al pedir que restauraran mi copia de seguridad. En palabras del responsable de ese hosting: “Había sido un problema en muchos clientes, por lo que podría tardar hasta un mes en restaurar”. Estamos hablando de 2004, siglo XXI y dejar una web durante un mes offline no se podía permitir. Finalmente, yo que tenía una copia de seguridad de unas semanas atrás la restauré y seguí con ella.

Con esto quiero decir que la restauración de las copias de seguridad es una gran olvidada, y no debería ser así.

Nuevo sistema de copias de seguridad en el hosting de Siteground

Hablemos de una empresa diferente que sí se toma en serio este tipo de asuntos. El caso particular de Siteground, comenzó con un gran problema: el sistema que utilizaban, R1Soft, era lento. Aunque R1Soft es ampliamente utilizado por la industria del hosting. Este software hace un procesamiento en serie de todos los servicios a copiar por cada servidor y los transmite al servidor donde alojamos nuestras copias de seguridad. En principio está bien, la copia de seguridad no nos interesa que interfiera con nuestro servicio y si es un poco más lenta no pasa nada. El problema surgió al restaurar la copia, al ser máquinas con gran espacio de almacenamiento y muchos servicios tirando de ellas todos los servicios debían estar parados mientras se restauraba la copia que, a 1 Gigabit por segundo (interfaz de red estándar) hace una tasa de transferencia en el mejor de los casos de unos 100Mb/s (redondeando y quitando datos de protocolo y demás), aunque si habéis trabajado con este tipo de copias (comprimidas y cifradas) para restaurarse tienen que descifrarse y descomprimirse y esto utiliza intensamente el procesador (y aunque tengamos 24 núcleos por servidor, toda esta carga se la lleva uno).
El principal reto de las restauraciones era paralelizarlas, tanto en interfaces de red (los grandes servidores tienen varios interfaces conectados a la vez con los que, cuando uno está congestionado podemos utilizar otro para ir más rápido) como en procesadores (sobre todo si es algo crítico ponemos a trabajar varios núcleos del servidor para la restauración), con lo que se consigue una mejora del 700% en el RTO (Recovery Time Objective), o el tiempo que se tarda en tener todo funcionando de nuevo y los clientes no tendrán así sus webs offline demasiado tiempo. En su blog cuentan cómo pasaron de 28h a sólo 4h. (Sus equipos vienen con 12 discos SSD de 960Gb cada uno en RAID10, es decir, en lugar de casi 12Tb de espacio tienen cerca de 6Tb replicados, lo que dejaría quitando sistemas operativos, sistema de archivos, software y demás algo más de 4Tb para datos de clientes).
SiteGround-Logo
Por otro lado, con R1Soft, se dieron cuenta de que hasta que no estuviera todo 100% restaurado no podían restablecer el servicio (como sucede cuando haces copias de imágenes de disco), eso sí, todo funcionaría de nuevo al mismo tiempo, webs grandes y pequeñas a la vez, aunque estaría bien para ir tranquilizando a los clientes ir reanudando el servicio de forma escalonada a medida que se van restaurando las webs, y seguro que a Siteground también le vendría bien ir probando el servicio y asegurando la calidad de los servicios que se van restaurando, cosa que sí han logrado con este nuevo sistema.
En cierto modo, vemos que 28h de downtime comparadas con 8760h que tiene un año, es algo más del 0.3%, eso sí, sólo en caso de un desastre encadenado de varios sistemas de redundancia, y Siteground no miente al asegurar un 99% de disponibilidad (en realidad consiguieron un 99.6% que está muy bien), pero es cierto que 28h de espera por un servicio es terrible para el cliente. Yo mismo me desespero cuando mi conexión a Internet de casa falla durante una hora…

Además, como ventaja añadida seguro que ahorran costes en licencias de software de copias de seguridad.

Referencias

También podría interesarte....

Leave a Reply