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.
La diferencia no es semántica. Obliga a inventariar la aplicación completa y a definir quién toma decisiones durante el incidente. Un documento sin responsables ni prueba no es todavía un plan operativo.
RPO limita la pérdida de datos
El RPO expresa hasta qué punto anterior podría ser aceptable recuperar. Un RPO de una hora plantea una ventana máxima de una hora de cambios no recuperados; no promete que siempre se pierda exactamente ese tiempo. La frecuencia de réplica o copia debe sostener ese objetivo.
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.
AMBG parte de una carga concreta, documenta dependencias y ensaya el recorrido con los responsables del cliente. El objetivo no es exhibir una arquitectura; es saber qué ocurrirá cuando la operación la necesite.
