| Nivel (propuesto) | Disponibilidad | Patrón | RPO / RTO |
|---|---|---|---|
| Estándar | 99,7% | Base de datos multizona de alta disponibilidad, copias de seguridad aisladas de la red. | Zona: RPO ≈ 0. Región: restaurar desde el almacén. |
| Live DR | 99,9% | Una segunda región funcionando en directo | RPO segundos, RTO ≤ 15 min |
| Live DR Premium | 99,95% | Tráfico en ambas regiones, prioridad 24 horas al día, 7 días a la semana | RPO segundos, RTO ≤ 5 min |
La inactividad productiva es del 95%. La disponibilidad se mide mensualmente en el punto de acceso TRANXACT, excluyendo el período de mantenimiento acordado (propuesto de 4 horas al mes).
Corrija el nivel antes de dimensionarlo. Live DR es una segunda región de tamaño completo y prácticamente duplica el costo de la infraestructura en tiempo de ejecución; muéstrela como una línea aparte, frente al costo del tiempo de inactividad que elimina.
Vive, no seas pasivo.
Un sistema de reserva pasivo permanece inactivo, se verifica una vez al año, si es que se verifica, y la conmutación por error se realiza mediante restauración y escalado. Live DR ejecuta un clúster de tamaño completo y una base de datos replicada continuamente que proporciona lecturas, informes, ASK y publicaciones sintéticas durante todo el día. La conmutación por error es una promoción (no se reconstruye nada) y su estado se verifica cada minuto.
| Prueba | Impacto | Con qué frecuencia | Categoría |
|---|---|---|---|
| Verificación continua: contabilizaciones sintéticas, alertas de retraso, suma de comprobación del libro mayor entre regiones. | Ninguno | Cada minuto | Estándar (TO_4.10.01) |
| Simulacro de cambio planificado: pausar la escritura, promover, cambiar, verificar; intercambio de roles | La escritura se detuvo durante segundos. | Trimestral | Estándar (TO_4.10.03) |
| Simulacro de cambio adicional | La escritura se detuvo durante segundos. | Previa solicitud, con dos semanas de antelación. | Adicional (TO_4.10.04) |
| Taladro aislado: un clon cercado con integraciones deshabilitadas | Ninguno en producción | Previa solicitud, con dos semanas de antelación. | Adicional (TO_4.10.05) |
| Prueba de restauración de sala limpia | Ninguno en producción | Anual | Estándar (TO_4.9.07) |
| Validación del negocio después de un ejercicio | Esfuerzo del cliente | Cada ejercicio | Excluido (TO_4.10.06) |
Copias de seguridad
| Base de datos de producción | Base de datos no productiva | |
|---|---|---|
| Tomado | Instantánea diaria + registros continuos | Instantánea diaria |
| Recuperarse a | En cualquier momento dentro de 30 días | La última instantánea, 14 días |
| Copia de la bóveda | Diario, inmutable, 90 días | Semanal, inmutable, 30 días |
Los documentos se versionan continuamente y se copian diariamente al repositorio para su uso en producción. La infraestructura como código y la configuración también se encuentran en el repositorio, por lo que el entorno de ejecución se reconstruye a partir del código en lugar de restaurarse.
¿Por qué la bóveda?
La replicación protege contra interrupciones, no contra la corrupción. El ransomware o los datos erróneos se replican en la región de respaldo y en la de recuperación ante desastres en cuestión de segundos. La bóveda es una cuenta independiente con identidades y claves propias, sin conexión de red con el entorno de producción, con retención de escritura única que ni siquiera los administradores pueden acortar y eliminación con doble aprobación. Las restauraciones se realizan en un entorno aislado (escaneo, conciliación y posterior promoción), nunca directamente en el entorno de producción.
Una vez establecido, el período de retención no se puede acortar. Si se requiere una retención por auditoría o por motivos legales, extiéndalo con anticipación y calcule el tamaño de las copias a largo plazo en función del crecimiento del libro mayor y el volumen de documentos, no del tamaño actual de la base de datos.
Calderwood optó por Live DR con una disponibilidad del 99,9 % en una segunda región de Azure dentro de la misma jurisdicción. Su primer simulacro de conmutación por error y una restauración desde cero están programados antes de la puesta en marcha como puntos de control. Sus socios bancarios y de nómina están incluidos en el plan de conmutación por error para que sus puntos finales sigan al administrador de tráfico.
Pruébalo Un proceso por lotes corrompe 4000 facturas de Calderwood a las 14:05. Live DR funciona correctamente, con un retraso de 2 segundos. ¿La solución es conmutar a la región de DR?
No. La corrupción se replicó en la región de respaldo y en la de recuperación ante desastres segundos después de ocurrir; la conmutación por error implica el uso de los mismos datos erróneos. La solución consiste en una restauración a un punto en el tiempo a las 14:04 (TO_4.9.05, Estándar) o, si el historial es sospechoso, una restauración limpia desde el repositorio (TO_4.9.06), con la aprobación del controlador financiero de los datos restaurados (TO_4.9.11).