Cómo nuestro nuevo sistema de backup ahorra más de 24h de parada del sistema

¿Recuerdas cuando anunciamos nuestra nueva infraestructura en octubre el año pasado? Parte de la innovación, de la cual estamos particularmente orgullosos, fue el sistema de backup/restauración creado por nosotros. Hace unos días, este sistema fue sometido a una prueba real crítica y los resultados fueron impresionantes. Hemos sido capaces de restaurar 3 veces más cantidad de datos y hacerlo 7 veces más rápido en comparación con nuestra solución de backup anterior. Te contamos cómo lo hicimos.

¿Con qué frecuencia necesitamos restauraciones de copias de seguridad masivas?

La respuesta corta es: muy raramente. Tener una infraestructura altamente redundante con múltiples unidades SSD en RAID elimina prácticamente la necesidad de este tipo de restauraciones. Normalmente, cuando un SSD falla, se reemplaza perfectamente por una nueva pieza de hardware sin ningún tiempo de inactividad notable o pérdida de datos. Los fallos de disco son muy comunes: para un proveedor de nuestro tamaño es normal ver este tipo de eventos casi a diario. Sin embargo, de vez en cuando, una coincidencia desafortunada de varios fallos de hardware y software simultáneos puede hacer que el reemplazo de hardware estándar sea imposible. Y éstos son los casos en los que necesitamos restaurar todas las cuentas que fueron dañadas a partir de nuestras copias de seguridad.

Previamente, antes de nuestro nuevo sistema de backup.

La última vez que necesitamos hacer una restauración completa de un servidor compartido fue hace más de un año. En aquel entonces usábamos el software para copias de seguridad de R1Soft, que es uno de los más populares en nuestra industria. Los proveedores de alojamiento web como nosotros utilizan este software por dos razones principales. En primer lugar, es muy fiable. Casi nunca hemos tenido problemas serios con copias de seguridad perdidas y/o corruptas. Y en segundo lugar, es muy ligero y no crea carga significativa en los servidores de producción mientras se crean las copias de seguridad (un proceso que consume muchos recursos y que tiene lugar todos los días). Con estas dos características R1Soft funciona perfectamente el 99% de las veces: cuando crea copias de seguridad y cuando se necesitan copias de seguridad individuales.

Sin embargo, en las raras ocasiones en que una restauración completa de múltiples cuentas es necesaria, R1Soft tiene un serio inconveniente: el proceso de recuperación es muy lento y los sitios web pueden experimentar una interrupción prolongada. En el caso en cuestión, todas nuestras cuentas afectadas estuvieron caídas durante 28 horas. Se tomó tanto tiempo por dos razones. En primer lugar, R1Soft no permite restauraciones simultáneas desde y hacia múltiples ubicaciones. Todos los datos necesitan ser recuperados a través de una interfaz de red única y esto es lento. Otro problema con R1Soft es que la recuperación no puede ser gradual y el servidor está caído durante todo el proceso de restauración. Todos los sitios afectados sólo pueden volver on-line al mismo tiempo una vez que toda la información se haya transferido desde el servidor de backup al servidor en producción. Por lo tanto, incluso el sitio web más pequeño no se podía estar activo de nuevo hasta que hubiésemos restaurado el servidor completo.

La mayoría de los proveedores de alojamiento compartido no consideraría esta historia como un problema grave ni que tampoco requiera acciones adicionales correctivas una vez que la restauración haya terminado. Después de todo, únicamente una sola máquina se vio afectada y todos los clientes tuvieron sus sitios web on-line de nuevo sin pérdida de datos. El tiempo de inactividad de los sitios también era casi insignificante si tomamos como base un año: 28 horas son sólo el 0,3% del año. Sin embargo, en SiteGround, quedamos bastante insatisfechos con la duración del problema y estábamos decididos a evitar que esto se repitiese en el futuro.

Y ahora, después de nuestro nuevo sistema de backup.

Esta situación nos llevó a creación de nuestro propio sistema de copias de seguridad para garantizar un proceso de restauración más rápido. Nuestro talentoso departamento de DevOps empezó a trabajar en él. Pusimos en marcha la nueva solución en octubre de 2015, pero no fue hasta hace pocos días que tuvimos que usarlo en un evento similar al descrito anteriormente. En comparación con la solución utilizada entonces basada en R1Soft, nuestro propio sistema hace copias de seguridad distribuidas y permite restauraciones simultáneas desde múltiples instancias de backup a múltiples servidores de producción. Por lo tanto, ahora fuimos capaces de recuperar 4 TB de datos (que era casi tres veces más que la vez anterior), en sólo 4 horas, en comparación con las 28 horas de la vez anterior.

Además, nuestro sistema permite una recuperación gradual y las primeras cuentas volvieron a estar on-line tan sólo unos minutos después de que se identificase el incidencia, con el tiempo de inactividad más largo (aproximadamente 4 horas) afectando sólo a unos pocos sitios individuales. Esto hizo caer el tiempo de inactividad promedio para todas las cuentas afectadas a menos de 2 horas, en comparación con las 28 horas de antes. Una mejora bastante impresionante, ¿verdad? Pero…

¿Se puede hacer aún más rápido ?

¡Sí se puede! En nuestro caso más reciente de restauración masiva, que en realidad no fuimos capaces de utilizar la conectividad de red Infiniband entre nuestros servidores de backup y los de producción, según lo previsto en tales casos. Por lo tanto los datos se transfirieron a través de la red estándar de 1 Gbit/s, en lugar través de la conexión Infiniband 10 Gbit/s. Nos dimos cuenta de que se debió a una incidencia de hardware en estado latente que fuimos capaces de descubrir sólo durante una restauración real. Ahora ya nos hemos asegurado de que esto no sea un problema la próxima vez y por lo tanto, la restauración será aún más rápida.

De forma adicional, con el nuevo sistema podemos restaurar teóricamente un número ilimitado de instancias de producción al mismo tiempo, pero en la práctica estamos limitados, no por el propio sistema de copias de seguridad, sino por la forma en que nuestro sistema DNS funciona en este momento. Tuvimos tres instancias afectadas por la incidencia y cada una de ellas tenía DNS individual. Así que necesitamos usar las viejas direcciones IP para restaurar esas tres nuevas instancias, para que los dominios que no están registrados con nosotros pudiesen seguir trabajando como antes y no experimentar el tiempo de inactividad adicional, debido a la propagación de DNS. Para evitar esta limitación en el futuro tenemos la intención de trabajar en unos nuevos DNS y/o sistema proxy centralizados.

La historia sobre nuestro sistema de creación de copias de seguridad es sólo otro ejemplo de nuestra forma de enfocar los problemas. Nunca estamos satisfechos solucionando incidencias de forma puntual y olvidarse de ellas hasta la próxima vez. Vemos cada incidencia como un nuevo reto que precisa una solución única. Y si tal solución no existe en ese momento, no tenemos miedo de inventarla nosotros mismos.