Recuperación ante desastres, copias de seguridad, RTO/RPO, failover y, sobre todo, la pregunta que muchas empresas no se hacen hasta después de una interrupción: ¿realmente podemos recuperar el sistema y volver a trabajar?
Fallo del servidor. Base de datos dañada. Error tras una implementación. Ransomware. Problemas con el proveedor de infraestructura. Eliminación accidental de datos. Caída de toda una región.
Hay muchos escenarios posibles. El problema es que la mayoría de las empresas se preparan principalmente para que la interrupción no ocurra.
Y con mucha menos frecuencia se preparan para la situación en la que sí ocurre.
Este es precisamente el ámbito de la recuperación ante desastres.
Y aquí surge la pregunta fundamental: si tu aplicación deja de funcionar hoy a las 14:00, ¿cuánto tiempo necesitas para volver a ponerla en marcha y cuántos datos podrías perder?
Si la respuesta es «tenemos una copia de seguridad», todavía no has respondido a esa pregunta.
Una copia de seguridad no es recuperación ante desastres
Una copia de seguridad es una copia de los datos. La recuperación ante desastres es el proceso de recuperar el funcionamiento del sistema.
Es una distinción muy importante.
Puedes hacer copias de la base de datos todos los días y, aun así, no saber:
-
si la última copia es válida,
-
si es posible restaurarla,
-
cuánto tardará la restauración,
-
si, después de la restauración, la base de datos será compatible con la versión actual de la aplicación,
-
si también podrás restaurar la configuración del sistema,
-
si dispones de todas las claves, certificados y secretos necesarios para poner en marcha el entorno,
-
si la infraestructura necesaria para ejecutar la aplicación seguirá estando disponible,
-
quién debe realizar cada uno de los pasos,
-
si todo el proceso cabe dentro de un plazo aceptable para el negocio.
NIST señala expresamente la necesidad de probar la restauración de las copias, y las directrices actuales de AWS también consideran las pruebas periódicas de recuperación una forma de comprobar si la copia de seguridad permite realmente alcanzar los RTO y RPO previstos.
Por eso, la copia de seguridad es un elemento de la estrategia de recuperación, no un equivalente completo de esta.
La pregunta más importante: ¿qué ocurrirá después de una interrupción?
Imaginemos una tienda en línea.
A las 10:17, la base de datos deja de responder.
El servidor de aplicaciones sigue funcionando, pero los usuarios no pueden iniciar sesión. Los pedidos no funcionan. El panel de administración deja de responder. El sistema de pagos no recibe la información correcta.
El equipo analiza la situación.
Resulta que la última copia de seguridad de la base de datos se hizo a las 8:00.
En teoría, es posible recuperar los datos.
Pero entonces surgen más preguntas:
- ¿Se sabe dónde está la copia?
- ¿Se sabe cómo restaurarla?
- ¿Está disponible la persona que sabe hacerlo?
- ¿Está completa la copia de seguridad?
- ¿La configuración de la aplicación corresponde a la versión guardada en la copia?
- Después de restaurarla, ¿funcionará la base de datos con la aplicación actual?
- Y lo más importante: ¿cuánto tardará en volver a funcionar la tienda?
Si nadie lo ha comprobado antes, la respuesta podría ser una sorpresa.
RTO: ¿cuánto tiempo de inactividad podemos aceptar?
El RTO, o Recovery Time Objective, establece el tiempo máximo aceptable para recuperar un sistema tras una interrupción.
Por ejemplo: RTO = 4 horas significa que la organización prevé poder recuperar el funcionamiento del sistema en un máximo de cuatro horas.
Sin embargo, esto no significa que todas las aplicaciones deban tener un RTO de cuatro horas.
Para un sistema interno que se utiliza varias veces al día, ese plazo puede ser aceptable. Para una plataforma de ventas que funciona las 24 horas del día, los 7 días de la semana, puede suponer pérdidas muy importantes.
Por tanto, el RTO debe derivarse de las necesidades del negocio, no de lo que ofrezca actualmente la infraestructura.
NIST define el RTO como el tiempo durante el cual un sistema puede permanecer en fase de recuperación antes de que esto afecte negativamente a las operaciones de la organización.
RPO: ¿cuántos datos podemos perder?
El segundo parámetro fundamental es el RPO, o Recovery Point Objective.
El RPO responde a la pregunta: ¿hasta qué punto podemos retroceder en los datos después de una interrupción?
Ejemplo: RPO = 1 hora significa que la organización acepta una posible pérdida de aproximadamente una hora de datos como máximo.
Si el sistema falla a las 15:00 y la última copia utilizable es de las 14:00, ese escenario se ajusta al RPO previsto. Pero si se hace una copia de seguridad una vez al día, es difícil esperar un RPO de una hora.
Por tanto, el RPO influye directamente en cómo se realizan las copias de seguridad, se replican los datos y se diseña la infraestructura.
El RTO nos indica principalmente cuánto tiempo podemos estar sin servicio.
El RPO indica cuántos datos podemos perder.
Estos dos parámetros deben acordarse con el negocio, ya que alcanzarlos implica costes y soluciones técnicas. Microsoft también destaca que el RTO y el RPO deben derivarse de las necesidades reales del negocio, no de la suposición abstracta de «cero tiempo de inactividad y cero pérdida de datos».
Puede haber una copia de seguridad y, aun así, ser inútil
Este es uno de los mitos más peligrosos de TI.
«La copia de seguridad se realiza correctamente» no significa automáticamente «se puede recuperar el sistema a partir de ella».
La copia puede estar incompleta. Puede estar dañada. Puede contener datos que no se puedan utilizar correctamente. Puede haberse creado de una forma que no permita recuperar todo el entorno.
Por eso, hay que probar la copia de seguridad mediante una restauración real.
No basta con comprobar que el archivo existe.
Hay que restaurarlo.
Poner en marcha el sistema.
Comprobar los datos.
Verificar las dependencias.
Comprobar la configuración.
Medir el tiempo.
Y responder a la pregunta de si el resultado cumple los objetivos de RTO y RPO.
AWS señala precisamente como error habitual restaurar una copia de seguridad sin comprobar si el recurso restaurado funciona realmente y si es posible utilizar los datos recuperados.
Failover: cuando no queremos esperar a la restauración
No todas las aplicaciones pueden permitirse esperar varias horas a que se complete la restauración. En estos casos, se utilizan, entre otros, mecanismos de failover.
Failover significa transferir las operaciones del entorno principal a un entorno de reserva preparado.
Puede tratarse de:
-
un servidor de reserva,
-
una segunda zona de disponibilidad,
-
una segunda región,
-
una réplica de la base de datos,
-
un entorno en espera,
-
una infraestructura alternativa lista para ponerse en marcha.
En el modelo más sencillo, la aplicación funciona en un solo lugar y, en caso de avería, ponemos en marcha el entorno de respaldo. En soluciones más avanzadas, parte de la infraestructura funciona en paralelo y está preparada para hacerse cargo del tráfico.
Sin embargo, no existe una única estrategia adecuada para todos.
El backup y la restauración suelen ser más baratos, pero pueden implicar un tiempo de recuperación más prolongado. Las soluciones como el warm standby o la redundancia activa pueden reducir significativamente el tiempo de recuperación, pero requieren una mayor inversión y una infraestructura más compleja.
También hay que probar el failover
Aquí surge otro problema.
Una empresa puede tener un entorno de respaldo que no ha utilizado en dos años;
- ¿Sigue funcionando?
- ¿La configuración se corresponde con producción?
- ¿Tiene suficiente rendimiento?
- ¿Están disponibles todos los servicios?
- ¿Están al día los certificados?
- ¿Se realizará correctamente el cambio de DNS?
- ¿La aplicación se conectará a la base de datos?
- ¿Funcionará el mecanismo de autorización?
- ¿Sabe el equipo exactamente qué debe hacer?
Solo una prueba puede responder a estas preguntas.
AWS recomienda probar el failover con regularidad precisamente para verificar el funcionamiento de la ruta de recuperación y comprobar si el RTO y el RPO reales se ajustan a lo previsto.
Un entorno de disaster recovery que nunca se ha probado es, en parte, solo una suposición.
El disaster recovery no es solo infraestructura
Es fácil considerar el DR únicamente desde el punto de vista de los servidores.
Eso es un error.
La recuperación también incluye:
- Datos
¿Están protegidos todos los datos importantes? - Aplicación
¿Tenemos la versión correcta del código y la posibilidad de desplegarla? - Configuración
¿Sabemos qué ajustes se necesitan para poner en marcha el sistema? - Secretos y certificados
¿Tenemos acceso seguro a las claves, los tokens y los certificados? - Dependencias externas
¿Qué ocurrirá si no está disponible un sistema de pagos externo, una API, un proveedor de identidad o un servicio SaaS? - Infraestructura
¿Tenemos un lugar donde se pueda ejecutar la aplicación? - Personas
¿Está claro quién decide poner en marcha el procedimiento? - Procedimientos
¿Existe un runbook concreto o la recuperación depende de los conocimientos de una sola persona?
Este último punto es especialmente importante.
Si solo un administrador sabe cómo recuperar el sistema, todavía no tenemos un procedimiento resiliente. Dependemos de una persona concreta.
El peor momento para redactar un procedimiento de recuperación
Es cuando el sistema ya no funciona.
En ese momento hay presión por el tiempo, estrés, llamadas de clientes y preguntas de la dirección.
Por eso, el procedimiento debe prepararse con antelación.
Debe especificar, entre otras cosas:
-
cuándo ponemos en marcha el disaster recovery,
-
quién toma la decisión,
-
qué sistemas tienen la máxima prioridad,
-
dónde se encuentran las copias de seguridad,
-
cómo restaurarlas,
-
qué dependencias hay que poner en marcha,
-
cómo se realiza el failover,
-
cómo verificar que todo funciona correctamente,
-
cómo comunicar la avería,
-
cuándo se puede iniciar el failback,
-
quién aprueba la vuelta al entorno principal.
En caso de una avería grave, no debería haber lugar para la pregunta: «¿Qué hacemos ahora?»
El procedimiento debería responder a eso de antemano.
El DR debería probarse como una funcionalidad de la aplicación
Un buen enfoque consiste en tratar la recuperación de forma similar a las pruebas de software. No basta con preparar el procedimiento una sola vez.
El sistema cambia.
La base de datos crece.
Las dependencias cambian.
Se añade nueva infraestructura.
Cambian las versiones de la aplicación.
Aparecen nuevas integraciones.
Cambian los permisos.
Por eso, la estrategia de recuperación también requiere una revisión continua.
Se puede empezar la prueba con un escenario sencillo: «Se ha perdido la base de datos. Vamos a restaurarla desde la última copia.»
Después se puede pasar a escenarios más complejos:
- «El servidor de aplicaciones no funciona.»
- «Todo el entorno de producción no está disponible.»
- «Los datos han sido cifrados.»
- «La región principal de la infraestructura no funciona.»
- «No tenemos acceso al administrador principal.»
Cada prueba de este tipo puede revelar problemas que no se ven durante el funcionamiento normal del sistema.
¿Todas las aplicaciones necesitan un disaster recovery avanzado?
No.
Y esto también es importante.
Diseñar una infraestructura resistente a todos los escenarios posibles puede resultar desproporcionadamente caro.
Si una avería en una aplicación interna puede suponer una hora de molestias, no necesariamente necesitamos una infraestructura active-active en varias regiones. Sin embargo, si la avería del sistema implica detener las ventas, la producción, la atención al cliente o un proceso empresarial crítico, la situación es completamente distinta.
Primero hay que determinar el impacto de una avería en el negocio.
Solo después se debe elegir la tecnología.
Esto puede llevar a distintas soluciones:
Backup + restore
Una solución más sencilla y barata para sistemas de menor criticidad.
Warm standby
El entorno de respaldo está parcialmente preparado y se puede poner en marcha rápidamente.
Hot standby
El entorno de respaldo funciona en mayor medida en paralelo y está listo para asumir la carga.
Active-active
Dos entornos pueden gestionar el tráfico simultáneamente, reduciendo la dependencia de un único punto de fallo.
La elección de la solución debe basarse en el RTO, el RPO, la criticidad del sistema, el coste del tiempo de inactividad y las posibilidades técnicas.
Lista de comprobación: ¿está tu aplicación preparada para una avería?
Vale la pena responder a unas cuantas preguntas sencillas.
1. ¿Tenemos una copia de seguridad?
Esto es solo el principio.
2. ¿Se almacena la copia de seguridad de forma que también quede protegida ante una avería del entorno de producción?
3. ¿Hemos realizado alguna vez una restauración completa?
4. ¿Cuánto tarda realmente la restauración?
5. ¿Conocemos el RTO?
6. ¿Conocemos el RPO?
7. ¿Podemos recuperar no solo los datos, sino también la aplicación y su configuración?
8. ¿Tenemos un procedimiento de recuperación?
9. ¿Puede ejecutarlo más de una persona?
10. ¿Hemos probado el failover?
11. ¿Está actualizado el entorno de respaldo?
12. ¿Hemos vuelto a probar la recuperación después de los últimos cambios en el sistema?
Si respondemos «no lo sé» a varias preguntas, es un muy buen momento para revisar la estrategia de disaster recovery.
La prueba más importante es: «Muéstralo»
En TI es muy fácil decir:
- «Tenemos una copia de seguridad».
- «Tenemos un servidor de respaldo».
- «Tenemos un procedimiento».
- «Tenemos un plan de recuperación ante desastres».
- Pero la seguridad de un sistema no debería basarse únicamente en declaraciones.
La pregunta más importante es: Demuestra que puedes restaurarlo.
- Ejecuta una restauración.
- Mide el tiempo.
- Comprueba los datos.
- Prueba la aplicación.
- Realiza una conmutación por error.
- Comprueba el procedimiento.
- Repite la prueba después de cambios importantes.
Solo entonces se puede decir que la estrategia de recuperación se ha probado en la práctica.
La copia de seguridad protege los datos. La recuperación restablece el negocio
Esta es probablemente la diferencia más importante.
La copia de seguridad responde a la pregunta: «¿Tenemos una copia?»
La recuperación ante desastres responde a una pregunta mucho más difícil: «¿Podemos volver a funcionar después de una avería?»
Y entre una y otra está toda la arquitectura de recuperación: RPO, RTO, replicación, copias de seguridad, restauración, conmutación por error, configuración, procedimientos, responsabilidades y pruebas periódicas.
Un sistema bien diseñado no da por sentado que no se producirá una avería. Da por sentado que algún día se producirá una avería y habrá que saber qué hacer.
Porque la verdadera resiliencia de una aplicación no consiste en que nunca se averíe. Consiste en que, cuando algo salga mal, la organización pueda volver a funcionar de forma previsible, controlada y conforme a los requisitos del negocio.
Glosario
Disaster Recovery (DR) - estrategia y procedimientos que permiten recuperar el funcionamiento de los sistemas después de una avería grave.
Copia de seguridad - copia de los datos destinada a restaurarlos posteriormente.
Restauración - proceso de recuperación de datos o de un sistema a partir de una copia.
RTO (Recovery Time Objective) - tiempo máximo aceptable para recuperar un sistema.
RPO (Recovery Point Objective) - pérdida máxima de datos aceptable, expresada en tiempo.
Conmutación por error - transferencia del funcionamiento del sistema del entorno principal al de respaldo.
Failback - retorno del funcionamiento al entorno principal una vez eliminada la causa de la avería.
Prueba de recuperación - prueba destinada a confirmar que realmente se puede restaurar el sistema de acuerdo con los supuestos establecidos.
Runbook - instrucciones detalladas para actuar ante un escenario de avería determinado.
