Respaldo o recuperación

Respaldo en la nube

Te devuelve los datos.

La copia sale del sitio sin cambiar tu operación.

Ver detalle

Estás aquí

Recuperación ante desastres

Te devuelve la operación corriendo.

Cómputo donde levantarla, red que la comunique y nombres que resuelvan.

Tener lo primero sin lo segundo significa que tienes tus archivos y no tienes dónde levantarlos.

Lo que se cae cuando no hay a dónde levantar

Los datos están, pero no hay servidores disponibles para arrancarlos, y conseguir hardware en medio de una crisis no es cuestión de horas.
Las aplicaciones arrancan y no se encuentran entre sí, porque los nombres siguen apuntando a direcciones del sitio caído.
Nadie sabe en qué orden encender las cosas, así que el ERP intenta levantar antes que la base de datos de la que depende.
El tiempo de recuperación que aparece en el plan nunca se midió, así que es una estimación, no un número.

Dos formas de recuperar

Replicación de servidores

Cuando lo que hay que levantar son servidores completos.

Un agente en cada servidor replica los cambios hacia un área de espera en la nube, y el cómputo aparece sólo cuando se ejecuta el failover.

Recuperación de plataforma y bases de datos

Cuando conviven aplicaciones heredadas, contenedores y bases de datos grandes, y hoy la recuperación depende de coordinar a varias áreas.

Los dos sitios salen del mismo código, las bases de datos se replican enviando sólo los bloques que cambiaron, y el failover y el regreso se orquestan como un procedimiento automatizado. El simulacro corre en aislamiento, sin tocar producción.

Cómo funciona

Replicación continua, no copia nocturna. Un agente ligero en cada servidor envía los cambios conforme ocurren hacia un área de espera en la nube. Lo que se pierde en una caída es lo que cambió en los últimos instantes, no el trabajo del día.
La capacidad se materializa en el failover. Mientras no hay desastre, del otro lado no hay servidores corriendo, sólo el área de replicación. El cómputo aparece cuando se ejecuta la recuperación. Esa es la diferencia de fondo frente a sostener un sitio alterno físico.
El regreso se diseña junto con la ida. Superada la crisis hay que volver al sitio original. Ese camino se define desde el principio, porque quedarse operando indefinidamente en modo de emergencia tiene su propio costo.

Qué entra en el alcance

Pérdida parcial. Fallan uno o varios servidores mientras el sitio sigue de pie. Sus instancias de recuperación toman el relevo en la nube y tus usuarios siguen trabajando por la misma red.
Pérdida total del sitio. El centro de datos está caído y su conectividad también. Los sistemas se levantan en la nube y tu gente trabaja de forma remota con escritorios virtuales, como si estuviera en la oficina.
Failover de prueba. Las instancias de recuperación arrancan en una red aislada para comprobar que los sistemas regresan y que los datos están íntegros, sin tocar producción.
Failback. Cuando tu sitio vuelve, todo lo que cambió durante el incidente regresa a él sincronizado, para que nadie tenga que reconciliar dos versiones de la verdad.

Cómo trabajamos

Clasificamos qué tiene que volver primero
No todo el ambiente merece el mismo tratamiento. Las cargas se ordenan por lo que tu operación deja de hacer sin ellas, y de ahí salen los objetivos de tiempo de recuperación y de pérdida de datos tolerable para cada una.
Diseñamos el destino
Conectividad segura entre tu sitio y la nube, resolución de nombres y orden de arranque de las dependencias. La mayoría de los planes fallan aquí, no en la replicación.
Replicamos
Se instala el agente en los servidores en alcance y se deja correr hasta que la réplica está al día, verificando que no compita con el rendimiento de producción.
Probamos el failover en un subconjunto
La recuperación se ejecuta de verdad sobre un grupo acotado de cargas, aislado de producción, para ver el comportamiento y medir el tiempo antes de involucrar el ambiente completo.
Medimos y escribimos el runbook
El resultado no es "funciona". Es cuánto tardó, qué salió distinto de lo esperado y el procedimiento paso a paso para el día real, incluido el regreso.

Por qué importa lo que pasa después

Un plan de recuperación envejece más rápido que cualquier otra cosa en tu infraestructura. Entra un servidor nuevo y nadie lo agrega a la replicación. Cambia una dependencia y el orden de arranque deja de ser válido. Se actualiza una aplicación y el runbook queda atrás.

Un plan que no se vuelve a probar deja de ser un plan y se convierte en un documento. Por eso la prueba recurrente es la parte que no termina, y es algo de lo que nuestro equipo puede hacerse cargo.

Preguntas

¿Cuál es la diferencia entre alta disponibilidad y recuperación ante desastres?

Alta disponibilidad es que falle un componente y la operación siga sin que nadie se entere. Recuperación ante desastres es que pierdas un sitio completo y puedas levantar la operación en otro lado. Uno no sustituye al otro y resuelven fallas de escala distinta.

¿La replicación afecta el rendimiento de mis servidores?

El agente está diseñado para capturar cambios sin competir con la aplicación por recursos. Aun así se valida con medición sobre tu ambiente, porque el comportamiento depende de cuánto dato cambia y del enlace que tengas.

¿Tengo que replicar todo?

Casi nunca conviene. Replicar todo por igual encarece sin mejorar la recuperación, porque el problema real es el orden en que las cosas vuelven y no el volumen. Por eso el primer paso es clasificar.

¿Cuántos datos podría perder?

Con replicación continua a nivel de bloque, típicamente segundos de cambios. También puedes regresar en el tiempo: por defecto, AWS Elastic Disaster Recovery guarda un punto de recuperación cada diez minutos durante la última hora, uno por hora durante el último día y uno por día durante la retención que configures. Eso es lo que te deja regresar a un momento anterior a que el ransomware cifrara algo.

¿El failover puede ser automático?

La ejecución sí. Las alarmas detectan la falla, un runbook orquestado arranca los sistemas en el orden correcto y el DNS mueve a los usuarios al sitio nuevo. La decisión no debería serlo. Declarar un desastre es una decisión de negocio, así que lo diseñamos para que una persona la tome en un paso y la automatización haga el resto.

¿Mis aplicaciones necesitan cambios?

A veces uno. Las aplicaciones que apuntan a direcciones IP fijas necesitan apuntar a nombres, para poder cambiar de sitio sin reconfigurarse. Esas las encontramos durante el diseño, no durante el incidente.

¿Mi enlace a internet alcanza?

La replicación continua necesita ancho de banda sostenido. Lo dimensionamos a partir de tu tasa real de cambio antes de empezar y te decimos si tu enlace actual alcanza, necesita control de tráfico o necesita un canal dedicado para la replicación.

¿Qué recibo al final?

Diagramas de arquitectura editables para replicación, prueba, failover y failback. Runbooks de failover y failback probados. Los tiempos medidos en la prueba. Las grabaciones de las sesiones de trabajo, y capacitación para tu equipo para que el plan no dependa de nosotros.

Agenda una llamada

Recuperar los datos no es recuperar la operación.