Disaster Recovery as a Service: failover a segundo datacenter ES/UE
Planes de recuperación ante desastres con RTO y RPO acordados por contrato, replicación continua y failover a un segundo datacenter en España o la UE. Pruebas de DR periódicas para que funcione cuando de verdad lo necesitas.
Un plan de DR que se prueba, no solo se promete
Un DR que no se ha probado no es un DR: es una esperanza. Nuestro servicio incluye pruebas trimestrales documentadas.
Replicación continua de VMs
Con Veeam Replication o Zerto, los cambios de las VMs críticas se replican al site de DR con RPO de minutos. El site secundario tiene siempre una copia caliente lista para arrancar.
Planes de recuperación orquestados
Runbooks automatizados que arrancan VMs en el orden correcto, reasignan IPs, actualizan DNS y validan la conectividad. El failover completo de un entorno de 20 VMs en menos de 15 minutos.
Pruebas de DR sin impacto
Failover de prueba en red aislada: arrancamos el entorno completo en el site de DR, verificamos que las aplicaciones funcionan y generamos el informe de prueba. Producción no se ve afectada.
RTO y RPO contractuales
No hablamos de objetivos teóricos: los RTO y RPO se definen en el contrato de servicio y se validan en cada prueba trimestral. Si no se cumplen en la prueba, lo corregimos antes del siguiente ciclo.
Failback ordenado a producción
Una vez resuelta la causa raíz del desastre, el proceso de failback devuelve las cargas al site primario de forma controlada y sin pérdida de datos generados durante el periodo de DR.
Datacenters soberanos ES/UE
Primario y secundario ubicados en España y la Unión Europea, bajo jurisdicción europea. Cumples RGPD, ENS y NIS2 sin que tus datos crucen fronteras fuera de la UE en ningún escenario.
Los dos objetivos que dimensionan tu plan
Los dos números que hay que poner por escrito
Un plan de recuperación no se dimensiona por lo que da miedo, se dimensiona por dos cifras que hay que acordar antes de elegir ninguna herramienta. Todo lo demás —la arquitectura, el segundo emplazamiento, el software de replicación y el presupuesto— sale de ahí.
- RTO: cuánto tiempo puedes estar parado. Desde que ocurre el incidente hasta que el servicio vuelve a estar disponible. No es cuánto tarda en arrancar un servidor: incluye detectar qué pasa, decidir que se activa el plan, ejecutarlo y comprobar que lo que ha vuelto funciona de verdad.
- RPO: cuántos datos puedes permitirte perder. El intervalo entre el último punto de recuperación bueno y el momento del desastre. Un RPO de cuatro horas significa que, en el peor caso, se pierde el trabajo de cuatro horas de toda la empresa.
Ninguno de los dos es gratis, y los dos escalan de forma muy poco lineal: bajar el RPO de veinticuatro horas a una es relativamente barato; bajarlo de una hora a cero cambia la arquitectura entera y multiplica el coste. Por eso la conversación útil no es «lo quiero todo a cero» sino qué se merece cada aplicación.
No todo tiene por qué tener el mismo nivel
Es el error más caro que vemos: aplicar a todo el parque el nivel que solo necesita el 10 % de las aplicaciones. Lo razonable es clasificar por lo que le pasa al negocio si eso está caído:
| Nivel | Qué entra | Cómo se consigue |
|---|---|---|
| Crítico | Lo que para la facturación o deja a los clientes sin servicio | Replicación continua a un segundo emplazamiento, conmutación ensayada, RPO de minutos o cero |
| Importante | Lo que la empresa puede sobrellevar unas horas con procedimiento manual | Replicación periódica y restauración desde copia, con RPO de horas |
| Resto | Lo que puede esperar a mañana sin que pase nada grave | Backup diario con retención, restauración bajo demanda |
Esa clasificación no la hace el proveedor: la hace quien conoce el negocio. Nosotros ayudamos a hacerla y a traducirla en arquitectura, y ponemos por escrito el RTO y el RPO que se comprometen para cada nivel.
Backup y recuperación no son lo mismo, y confundirlos sale caro
Un backup es una copia de la que puedes restaurar. Un plan de recuperación es la capacidad de volver a operar. La diferencia se nota el día malo: con solo backups, tienes los datos pero no tienes dónde levantarlos, ni red configurada, ni nadie que sepa en qué orden arrancan las cosas. Recuperar así se mide en días.
Por eso las dos cosas conviven y ninguna sustituye a la otra:
- El backup te protege de los errores. Un borrado accidental, una tabla machacada, un cifrado por ransomware. Aquí lo que importa es la retención —cuánto atrás puedes ir— y la inmutabilidad, porque un backup que se puede borrar con credenciales robadas no protege del escenario para el que lo tienes.
- La recuperación te protege de la pérdida del sitio. El datacenter deja de estar disponible, por lo que sea. Aquí importa que exista un segundo emplazamiento con una copia lo bastante fresca y que la conmutación esté ensayada.
Con la regla habitual de tres copias en dos soportes con una fuera —más una inmutable y cero errores en la verificación— se cubren los dos frentes. Cómo montamos la cadena de copias.
La copia inmutable, y por qué la ventana importa
Un backup inmutable no se puede borrar ni modificar durante el periodo de retención, ni siquiera con credenciales de administrador comprometidas. Es la única defensa real contra un ataque que primero busca las copias y luego cifra. El detalle que decide si sirve o no es la ventana de retención: si el atacante lleva tres semanas dentro y tu inmutabilidad es de catorce días, tus copias inmutables ya están cifradas. La ventana se dimensiona por el tiempo que tarda tu organización en detectar una intrusión, no por lo que ocupe menos.
Un plan que no se ha probado no es un plan
Es la parte que casi todo el mundo tiene sobre el papel y casi nadie ejecuta. Un plan de recuperación que nunca se ha activado es una hipótesis, y el día del incidente es mal momento para descubrir que la hipótesis era falsa. Lo que aparece cuando se prueba de verdad, y aparece casi siempre:
- Dependencias que nadie había documentado: el servicio levanta, pero necesita un servidor de autenticación que sigue en el sitio caído.
- Orden de arranque incorrecto: la aplicación arranca antes que su base de datos y se queda en un estado que hay que limpiar a mano.
- Direccionamiento y DNS que apuntan al emplazamiento antiguo, con propagaciones que añaden horas al RTO real.
- Credenciales y certificados que solo existían en el sitio que se ha perdido.
- Un RTO real que dobla o triplica el que estaba escrito, casi siempre por el tiempo de decisión humana y no por el técnico.
Por eso las pruebas van en el contrato y no en las buenas intenciones: se ejecutan en un entorno aislado, con un guion, y termina con un informe de qué funcionó, qué no y qué RTO se midió de verdad. Cuando la prueba sale mal, esa es exactamente la prueba que valía la pena hacer.
Y una cosa más: dónde se pone el segundo sitio
El segundo emplazamiento tiene que estar lo bastante lejos para no compartir el riesgo del primero —el mismo corte de suministro, la misma zona inundable— y lo bastante cerca para que la replicación aguante la latencia que exige un RPO bajo. Cada plaza tiene sus candidatos, con la distancia y la latencia estimada calculadas: ver los emplazamientos y sus parejas.
Resolvemos tus dudas
¿Cuál es la diferencia entre backup y Disaster Recovery?
El backup protege contra pérdida de datos pero no garantiza el tiempo de recuperación: restaurar un entorno completo desde backup puede llevar horas o días. El DR replica el entorno en caliente a un segundo site y permite arrancarlo en minutos. El DR tiene un coste mayor, pero es la única opción cuando el RTO es de minutos, no de horas.
¿Qué herramienta de replicación utilizáis, Veeam o Zerto?
Depende de tus requisitos. Veeam Replication es ideal para RPO de 15-60 minutos y entornos VMware o Proxmox VE. Zerto usa replicación de journal a nivel de hipervisor y permite RPO de segundos, con mayor granularidad de punto de recuperación. Para RPO de horas, el backup con replicación offsite es suficiente y más económico. Te asesoramos según tu RTO/RPO objetivo y presupuesto.
¿Con qué frecuencia se realizan las pruebas de DR?
Como mínimo trimestralmente, salvo que el contrato establezca otra frecuencia. Las pruebas se ejecutan en red aislada para no afectar a producción y el resultado se documenta en un informe con métricas de RTO alcanzado, estado de cada VM y cualquier desviación respecto al plan.
¿Puedo tener el DR solo para algunas aplicaciones críticas?
Sí. El diseño habitual es aplicar replicación continua y failover orquestado a las aplicaciones tier-1 (ERP, BBDD transaccionales, sistemas de pago) y backup estándar al resto. Esto optimiza el coste manteniendo la cobertura donde realmente importa.
Cuéntanos tu proyecto y elegimos por ti
Un especialista te contacta con la arquitectura recomendada, los plazos y el presupuesto. Sin coste y sin compromiso.