Cuando todo falla

Los datos sobreviven a todo, menos al descuido

Una tienda en línea guarda sus pedidos en una base de datos. Hay tres tipos de desastre que la amenazan:

• Naturales: un incendio, un terremoto o una inundación que destruye el lugar donde está el servidor.
• Técnicos: un disco que se daña, una fuente de poder que falla, un error del software.
• Humanos: alguien que ejecuta DROP TABLE pedidos en el servidor equivocado.

Antes de elegir tecnología, quien administra la base de datos responde dos preguntas de negocio:

• ¿Cuántos datos puedo perder? Si respaldo cada noche, en el peor caso pierdo un día de ventas. A esto se le llama RPO, el punto de recuperación.
• ¿Cuánto tiempo puedo estar sin servicio? Restaurar un respaldo grande puede tardar horas. A esto se le llama RTO, el tiempo de recuperación.

Las dos herramientas principales para responderlas son distintas y se complementan: el respaldo (una copia para volver al pasado) y la alta disponibilidad (otro servidor listo para seguir atendiendo ahora).

Completo e incremental

Un respaldo completo copia toda la base de datos. Es simple de restaurar, pero ocupa mucho espacio y tarda. Un respaldo incremental copia solo lo que cambió desde el respaldo anterior: es pequeño y rápido de hacer, pero para restaurar hace falta el último completo y todos los incrementales que lo siguen, en orden.

Por eso lo habitual es combinarlos: un completo periódico (por ejemplo, el domingo) e incrementales frecuentes (cada noche). Y un respaldo solo vale si se puede restaurar: hay que probar la restauración con regularidad, no solo crear archivos.

Un respaldo junto al servidor se quema con él

Si los respaldos están en el mismo edificio que el servidor, un incendio se lleva ambos. Una arquitectura común combina dos lugares:

• Un servidor de respaldo local, con discos redundantes (RAID) y energía de respaldo (UPS), para restaurar rápido los problemas cotidianos.
• Un almacenamiento en la nube, como un servicio de objetos, con políticas de retención y los datos cifrados, que sobrevive a un desastre en el sitio principal.

Para mover todo eso hace falta una red rápida, tanto entre los servidores locales como hacia internet, y automatizar los respaldos con scripts y herramientas: un proceso que depende de que alguien se acuerde termina fallando.

Una réplica lista para tomar el relevo

Restaurar un respaldo tarda. Para no quedarse sin servicio se usa la replicación: un servidor maestro (o primario) envía cada cambio a uno o más servidores esclavos (o réplicas), en otro sitio. En la replicación asincrónica, el primario no espera a la réplica: es rápida, pero la réplica puede ir unos segundos atrás.

Si el primario cae, se promueve la réplica a primario: eso es el failover. Un balanceador de carga que detecta la caída puede hacerlo automáticamente, para que los usuarios casi no lo noten. Cuando el sitio original se repara, el failback sincroniza lo que cambió y devuelve la producción a su lugar.

Redundancia no es historial

La réplica protege contra lo que destruye un servidor: un disco, un incendio. Pero copia fielmente cualquier cambio, incluso un DROP TABLE por error: no guarda el pasado. El respaldo sí lo guarda, pero restaurarlo tarda y se pierde lo ocurrido después de la última copia.

Un plan serio usa las dos, y además las prueba: restaurar un respaldo en un servidor de prueba, simular la caída del primario y medir cuánto tarda el failover. Las herramientas de monitoreo avisan cuando un respaldo falla o la réplica se atrasa.

Antes de leer la respuesta