Objetivo
Traducir necesidades del negocio en objetivos de recuperaci贸n medibles y distinguirlos de garant铆as o resultados autom谩ticos.
Contexto
RPO es el punto objetivo de recuperaci贸n: expresa cu谩nta informaci贸n reciente podr铆a perderse, medido como tiempo. Un RPO de cuatro horas implica dise帽ar copias o replicaci贸n para no retroceder m谩s que ese intervalo en condiciones previstas.
RTO es el tiempo objetivo de recuperaci贸n: cu谩nto deber铆a tardar el servicio en volver a un nivel acordado despu茅s de una interrupci贸n. Ambos son objetivos de dise帽o y deben validarse; no son garant铆as por escribirlos en un documento.
Puntos clave
- Cada proceso puede necesitar objetivos diferentes seg煤n impacto y horario.
- Menores RPO y RTO suelen requerir m谩s automatizaci贸n, redundancia, capacidad y costo.
- Recuperar infraestructura no garantiza que aplicaciones y datos funcionen correctamente.
- Dependencias de identidad, red, proveedores y personas deben incluirse.
- El tiempo se mide desde un evento definido hasta un estado de servicio acordado.
Recomendaciones
- Identificar procesos y responsables, no empezar por servidores aislados.
- Estimar impacto por hora o etapa y alternativas manuales disponibles.
- Acordar RPO, RTO, prioridad y nivel m铆nimo de operaci贸n.
- Dise帽ar tecnolog铆a, documentaci贸n y personal para alcanzar los objetivos.
- Probar escenarios y ajustar objetivos o inversi贸n seg煤n resultados.
Riesgos y advertencias
- Definir cero p茅rdida y recuperaci贸n inmediata sin an谩lisis produce objetivos inviables.
- Medir solo restauraci贸n t茅cnica ignora validaci贸n funcional y comunicaci贸n.
- No actualizar objetivos despu茅s de cambios de negocio vuelve obsoleto el plan.
C贸mo validar el resultado
- Una prueba registra hora de inicio, hitos, recuperaci贸n y validaci贸n del usuario responsable.
- La p茅rdida observada y el tiempo total se comparan con objetivos definidos.
- Los desv铆os generan acciones con responsable y fecha.
Buenas pr谩cticas
Utilizar escenarios concretos y documentar supuestos. Diferenciar recuperaci贸n parcial, servicio degradado y operaci贸n completa ayuda a fijar objetivos realistas.
Pr贸ximos pasos
Realizar un taller breve con responsables de procesos cr铆ticos para acordar impacto, prioridades y objetivos antes de revisar la arquitectura de backup y continuidad.
Diferencia entre RPO y RTO con un ejemplo
Supongamos que un sistema deja de funcionar a las 15:00. Si el RPO acordado es de cuatro horas, el dise帽o deber铆a permitir recuperar un punto no anterior a las 11:00 bajo el escenario previsto. Si el RTO es de dos horas, el servicio m铆nimo acordado deber铆a estar disponible antes de las 17:00. Son dos mediciones distintas: p茅rdida de datos y duraci贸n de la interrupci贸n.
| Objetivo | Mide | Pregunta para el negocio |
|---|---|---|
| RPO | P茅rdida de informaci贸n expresada como tiempo. | 驴Cu谩nto trabajo reciente podemos reconstruir o perder? |
| RTO | Tiempo hasta recuperar el nivel de servicio acordado. | 驴Cu谩nto puede permanecer interrumpido este proceso? |
Preguntas frecuentes
驴La frecuencia del backup es igual al RPO?
No siempre. La frecuencia influye, pero tambi茅n importan la finalizaci贸n de las copias, la replicaci贸n, la consistencia y el punto realmente recuperable.
驴El RTO termina cuando enciende el servidor?
Solo si ese fue el estado acordado. Para un proceso de negocio suele incluir aplicaci贸n, datos, accesos, conectividad y validaci贸n funcional.
El siguiente paso es revisar qu茅 es un backup recuperable y relacionar las pruebas con los objetivos de continuidad.