Backup y recuperación no son lo mismo
Una copia responde a “¿tenemos los datos?”. Disaster recovery responde a “¿cómo vuelve a operar la empresa?”. Para arrancar un ERP pueden hacer falta máquinas, discos, red, reglas de firewall, identidades, licencias, DNS e integraciones. Si una dependencia falta, los datos existen pero el servicio sigue parado.
Para preparar esa recuperación hay que inventariar la aplicación completa y aclarar quién toma decisiones durante una incidencia. Un documento sin responsables, dependencias ni pruebas ofrece poca ayuda cuando el servicio se detiene.
RPO limita la pérdida de datos
El RPO fija la pérdida máxima de datos que la empresa considera aceptable. Por ejemplo, un objetivo de una hora exige que los puntos de recuperación permitan retroceder, como máximo, ese intervalo. La pérdida real dependerá de cuándo se produzca la incidencia y de qué puntos sigan disponibles.
No todos los sistemas necesitan el mismo RPO. Pedidos activos, documentación histórica y un servidor de pruebas tienen impactos distintos. Aplicar la exigencia más alta a todo encarece la arquitectura sin mejorar la decisión.
RTO limita la duración de la parada
El RTO es el tiempo máximo acordado para recuperar un nivel de servicio útil. Debe incluir las tareas reales: decidir el failover, preparar el entorno, validar datos, comprobar accesos y comunicar la vuelta. Los pasos manuales también consumen tiempo.
Cuanto menor es el RTO, más infraestructura preparada, automatización y pruebas suele necesitarse. Por eso no se puede prometer “otro centro activo en segundos” sin una arquitectura concreta y un simulacro que lo demuestre.
Hay varias estrategias y no cuestan lo mismo
Restaurar copias, mantener una réplica, disponer de un entorno en espera o operar activo-activo son decisiones diferentes. AWS y otros proveedores ordenan estas estrategias por coste, complejidad, RPO y RTO. La opción más avanzada no siempre es la más sensata para una pyme.
Una réplica en otra zona reduce la dependencia del entorno principal, pero no sustituye copias históricas ni controles contra errores lógicos. Si un borrado se replica, también puede llegar al segundo entorno. Continuidad y protección de datos se diseñan juntas.
El segundo entorno necesita dependencias
Replicar solo la máquina suele dejar fuera elementos críticos. Hay que comprobar redes, firewall, usuarios, certificados, almacenamiento, conexiones con terceros y capacidad disponible. También hace falta decidir qué datos pueden escribirse durante la conmutación y cómo se vuelve al entorno principal.
Las plataformas de disaster recovery pueden replicar instancias, discos, redes y reglas a otra zona. El alcance contratado y la frecuencia deben compararse con el RPO y el RTO de la empresa.
El simulacro convierte arquitectura en evidencia
La prueba debe ejecutarse sin improvisar durante una caída real. Se elige un punto, se levanta el entorno alternativo, se valida la aplicación y se anotan tiempos y fallos. El resultado permite ajustar la promesa comercial a lo que el sistema ha demostrado.
El trabajo empieza por una carga concreta: se documentan sus dependencias, se acuerda el orden de recuperación y se ensaya el recorrido con las personas responsables. Así la empresa sabe qué está preparado y qué sigue pendiente.
