Ir al contenido
Continuidad y Recuperación

¿Qué es el RPO (Recovery Point Objective)?

El RPO (Recovery Point Objective, o punto de recuperación) es la cantidad máxima de datos que una empresa acepta perder, medida en tiempo. Si el RPO es de una hora, el backup debe ser reciente lo suficiente para que, en el peor caso, solo se pierdan los datos de la última hora. Es la respuesta a la pregunta “¿cuánto trabajo tendríamos que rehacer si todo se cae ahora?”.

Zamak TechnologiesActualizado el 10 de julio de 2026

Cómo funciona el RPO en la práctica

El RPO conecta una decisión de negocio (cuánto dato se puede perder) con una decisión técnica (cada cuánto corre el backup). Una define la otra.

1

Definir la tolerancia del negocio

Cada tipo de dato tiene un límite: un sistema de ventas no puede perder una hora; un archivo de referencia quizá acepte un día. Ese límite es el RPO.

2

Traducirlo en frecuencia de backup

El RPO define cada cuánto debe ocurrir la copia. Un RPO de 15 minutos exige backup cada 15 minutos, no una vez al día.

3

Medir la distancia hasta la última copia

En el momento de la falla, el dato perdido es todo lo que cambió desde el último punto de backup. Cuanto mayor el intervalo, mayor la pérdida.

4

Ajustar por criticidad

No todo necesita el mismo RPO. Definirlo por sistema evita pagar por protección continua donde no hace falta, y evita perder datos donde sí.

Fuentes: NIST SP 800-34 Rev. 1 e ISO 22301 (continuidad del negocio).

RPO por tipo de dato

  • Transaccional, casi cero Ventas, pedidos, finanzas y base de datos de producción: cada minuto es dinero y obligación. Piden un RPO de minutos, con copia continua o casi.
  • Operativo, algunas horas Archivos de trabajo, correo y sistemas internos: rehacer media mañana duele, pero no detiene a la empresa. Un RPO de pocas horas suele servir.
  • De referencia, un día Documentos que cambian poco, históricos y materiales estables: un RPO diario es suficiente y más barato de mantener.
  • Regulatorio, sin brecha Los datos bajo exigencia legal de guarda pueden necesitar un RPO corto y retención larga a la vez, por obligación, no solo por conveniencia.

Por qué el RPO decide cuánto pierde

85%
reconocen una brecha entre la recuperación que tienen y la que el negocio exige (Veeam 2024)
58%
solo esa parte logró restaurar siguiendo el plan previamente aprobado (Veeam 2024)
N.º 1
el ciberataque es la mayor causa aislada de interrupción de las operaciones (Veeam 2024)

El RPO no es jerga técnica, es la medida del daño invisible de una parada. Una empresa que hace backup una vez al día tiene, en la práctica, un RPO de 24 horas: si el sistema se cae a las 17 h, todo el trabajo desde la copia de la madrugada puede desaparecer. Por eso la mayoría de las organizaciones admite una brecha entre la recuperación que tiene y la que el negocio necesita (Veeam, 2024), y por eso solo una parte logra restaurar siguiendo el plan que tenía en el papel. Definir el RPO por sistema, y sostenerlo con backup en la frecuencia correcta, es lo que transforma “perdimos el día entero” en “perdimos algunos minutos”. A su lado va el RTO, que mide el tiempo hasta volver.

Cómo definir el RPO de su empresa

Definir el RPO es una conversación de negocio antes que técnica. Cuatro pasos lo vuelven concreto:

  1. Liste los sistemas por criticidadSepare lo que detiene a la empresa si desaparece una hora de lo que solo molesta. El RPO nace de esa clasificación.
  2. Pregunte cuánto trabajo se puede rehacerPara cada sistema, ¿cuánto tiempo de dato podría reconstruir el equipo a mano? Ese es el techo del RPO.
  3. Ajuste la frecuencia del backup al RPOLa copia debe correr dentro de la ventana del RPO. Un RPO de una hora con backup diario es una promesa que no se cumple.
  4. Revise cuando el negocio cambiaMás volumen, más clientes o una nueva obligación legal acortan el RPO. No se define una vez y se olvida.

En la práctica

El RPO mira hacia atrás (cuánto dato se pierde); el RTO mira hacia adelante (cuánto tiempo hasta volver). Definir ambos por sistema es lo que vuelve la continuidad un número, no una esperanza.

Cómo trata Zamak el RPO

Zamak Technologies define el RPO junto con el cliente, por sistema y por criticidad, y sostiene cada meta con backup en la frecuencia correcta y prueba de recuperación. Para dimensionar lo que una parada cuesta y qué RPO se justifica, un buen punto de partida es la calculadora de costo de inactividad. Es parte de la Continuidad del Método Zamak.

Preguntas frecuentes sobre RPO

¿Cuál es la diferencia entre RPO y RTO?
El RPO mide cuánto dato acepta perder (el tiempo entre la última copia y la falla). El RTO mide cuánto tiempo acepta estar detenido hasta volver. Uno es sobre datos perdidos, el otro sobre tiempo de inactividad. Los dos juntos definen el plan de continuidad.
¿Cuál es un buen RPO?
No existe un número universal: el buen RPO es el que el negocio puede absorber sin daño relevante. Los sistemas críticos suelen apuntar a minutos; los datos de referencia aceptan horas o un día. El error es aplicar el mismo RPO a todo.
¿Es posible un RPO cero?
Acercarse exige replicación continua, que tiene costo. Por eso el RPO se define por criticidad: se paga por casi cero donde cada minuto importa, y se acepta una ventana mayor donde el dato cambia poco.
¿Cómo se relaciona el RPO con la frecuencia del backup?
Directamente. El RPO es el techo; la frecuencia del backup debe caber dentro de él. Si usted acepta perder como máximo una hora, la copia tiene que correr al menos cada hora.
¿Quién define el RPO, TI o la dirección?
Ambos. La dirección dice cuánto dato puede perder el negocio; TI lo traduce en frecuencia de backup y arquitectura. El RPO es una decisión de negocio con ejecución técnica.

Términos relacionados

Amenazas y Ataques
Endpoint e Identidad
MFAPAM (acceso privilegiado)SSO (inicio de sesión único)
Detección y Respuesta
EDRMDRXDRMITRE ATT&CKSIEMSOC (centro de operaciones)
Red y Acceso
ZTNAFirewallVPNSASE
Gobernanza y Cumplimiento
LGPDISO 27001SOC 2NIST CSFShadow ITEvaluación de madurez cibernéticaHIPAAPCI DSSGDPRCMMCCIS ControlsISO 42001 (gestión de IA)NIST AI RMFNIST 800-171FTC SafeguardsISO 27701 (privacidad)FedRAMPGRC (gobernanza, riesgo, cumplimiento)vCIOvCISO
Conceptos y Fundamentos
Deep webZero TrustDefensa en profundidadSuperficie de ataqueEndpointMenor privilegio
IA y Seguridad
Shadow AIGobernanza de IAInyección de promptsOWASP LLM Top 10Deepfake