Continuidad · Copia / DR

Copia de seguridad y disaster recovery: RPO, RTO y pruebas de restauración

Una copia sin RPO/RTO definidos ni pruebas de restauración es solo coste de disco. Un disaster recovery sin procedimiento ni ventanas de comunicación es un plan de papel. En un modelo gestionado ambas capas deben formar parte del SLA — no un extra « cuando haya tiempo ».

RPO y RTO — en claro

• RPO (Recovery Point Objective) — cuánta pérdida de datos es aceptable (por ejemplo 15 minutos, 4 horas),
• RTO (Recovery Time Objective) — en cuánto tiempo el entorno debe volver a operar.

Valores más bajos implican una arquitectura más cara: instantáneas más frecuentes, replicación, warm/hot standby, emplazamiento distinto. No toda aplicación necesita un RPO casi nulo. En BaseCloud el RPO/RTO solo aplica cuando es contractual tras la evaluación. No publicamos una fecha de « última restauración » como promesa de producto.

Errores frecuentes en la práctica

• copia en la misma cabina / la misma AZ que producción,
• ninguna prueba de restauración (o una prueba « cada dos años »),
• poco claro quién aprueba la restauración y quién comunica con los clientes,
• retención demasiado corta para contabilidad o requisitos del sector.

Qué incluye el DR gestionado en BaseCloud

En los paquetes Professional y Enterprise, los procedimientos de copia y recuperación forman parte de la operación: calendarios, supervisión de trabajos, retención y participación en pruebas DR. El alcance RPO/RTO se concreta tras la evaluación — no prometemos « cero interrupción » sin una arquitectura que realmente lo permita.

Lista de comprobación antes de firmar el SLA

• lista de sistemas críticos y sus responsables de negocio,
• objetivos RPO/RTO por sistema (no un único número para toda la empresa),
• frecuencia y forma de las pruebas de restauración,
• vía de escalado e informe posterior al incidente.

Ver paquetes · DORA y continuidad de negocio · Más artículos