Ir al contenido
RPO y RTO

Qué significan RPO y RTO

Cómo definir cuánta información puede perderse y cuánto tiempo puede permanecer interrumpido un proceso antes de diseñar su recuperación.

8 min de lectura Responsables de operaciones Inicial Concepto Revisado el 21/07/2026
Método NeWeL Relevar Ordenar Documentar Mejorar
Documento en revisión. Esta primera versión requiere validación técnica y editorial antes de publicarse.

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

  1. Identificar procesos y responsables, no empezar por servidores aislados.
  2. Estimar impacto por hora o etapa y alternativas manuales disponibles.
  3. Acordar RPO, RTO, prioridad y nivel mínimo de operación.
  4. Diseñar tecnología, documentación y personal para alcanzar los objetivos.
  5. 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.

También te puede servir