En una estrategia de backup seria, no basta con “hacer copias de seguridad”. La pregunta importante no es solo si existen respaldos, sino cuánto dato se puede perder y cuánto tiempo puede estar detenido el negocio después de un incidente. Ahí entran dos métricas centrales: RPO y RTO.

Ambas sirven para traducir el riesgo técnico en impacto operativo. Sin ellas, una política de backups queda incompleta: puede ser demasiado débil para proteger procesos críticos o demasiado costosa para sistemas que no requieren recuperación inmediata.

Qué es RPO

RPO significa Recovery Point Objective, u objetivo de punto de recuperación. Define la cantidad máxima de información que una organización está dispuesta a perder medida en tiempo.

Por ejemplo, si una empresa tiene un RPO de 24 horas para su sistema contable, acepta que, ante un incidente, podría perder hasta un día de registros. Si el RPO es de 15 minutos, la estrategia de backup debe permitir recuperar la información casi hasta el momento del fallo.

La lógica es simple: cuanto menor sea el RPO, más frecuentes deben ser las copias o la replicación de datos.

Un RPO bajo suele exigir tecnologías más avanzadas, como snapshots frecuentes, replicación continua, journaling, almacenamiento redundante o soluciones de backup incremental muy frecuente. En cambio, un RPO alto puede cubrirse con respaldos diarios o incluso menos frecuentes, dependiendo del sistema.

Qué es RTO

RTO significa Recovery Time Objective, u objetivo de tiempo de recuperación. Define cuánto tiempo máximo puede tardar un sistema, aplicación o servicio en volver a estar operativo después de una interrupción.

Si una tienda en línea tiene un RTO de una hora, la infraestructura debe estar diseñada para restaurar el servicio dentro de ese margen. Si el RTO es de 48 horas, la recuperación puede apoyarse en procesos más manuales o menos costosos.

El RTO no mide la pérdida de datos, sino el tiempo de indisponibilidad. Por eso afecta directamente a la arquitectura de recuperación: infraestructura redundante, automatización, documentación, pruebas de restauración, disponibilidad del personal técnico y acuerdos con proveedores.

Un RTO agresivo exige preparación operativa. No basta con tener el backup; hay que poder restaurarlo rápido, con procedimientos probados y recursos disponibles.

Diferencia entre RPO y RTO

Aunq

ue suelen mencionarse juntos, RPO y RTO responden preguntas distintas.

El RPO pregunta: “¿Hasta qué punto en el tiemp

o necesito recuperar los datos?”

El RTO pregunta: “¿Cuánto tiempo puedo tardar en recuperar el servicio?”

Un sistema puede tener un RPO bajo y un RTO alto. Por ejemplo, una base de datos puede respaldarse cada pocos minutos, pero restaurarse manualmente en varias horas. También puede ocurrir lo contrario: un sistema puede volver rápido, pero con datos de hace varias horas si la política de backup no es suficientemente frecuente.

Diseñar una estrategia de backup requiere equilibrar ambas métricas. Concentrarse solo en una produce una falsa sensación de seguridad.

Por qué son importantes para el negocio

RPO y RTO permiten clasificar sistemas según criticidad. No todos los activos necesitan el mismo nivel de protección.

Un CRM, una plataforma de pagos, un ERP o una base de datos transaccional suelen requerir RPO y RTO bajos. En cambio, archivos históricos, reportes internos o repositorios documentales pueden tolerar más pérdida temporal o más demora en la recuperación.

Esta clasificación evita dos errores frecuentes. El primero es proteger poco los sistemas críticos, exponiendo al negocio a pérdidas graves. El segundo es sobreproteger sistemas secundarios, elevando costos sin justificación.

La estrategia correcta parte del impacto: pérdida de ingresos, sanciones regulatorias, daño reputacional, interrupción operativa, incumplimiento contractual y costo de reconstrucción de datos.

Cómo definir un RPO adecuado

Para definir el RPO, hay que analizar la velocidad con la que cambian los datos y el impacto de perderlos.

Una plataforma de pedidos puede requerir un RPO de minutos porque cada transacción perdida afecta ingresos, inventario y experiencia del cliente. Un repositorio de documentos administrativos quizá pueda aceptar un RPO de 24 horas. Un archivo histórico podría tolerar incluso más.

La pregunta central es: ¿qué pasa si perdemos los datos generados en los últimos minutos, horas o días?

Si la respuesta implica pérdidas económicas relevantes, reprocesamiento costoso, incumplimiento legal o daño a clientes, el RPO debe reducirse. Pero reducirlo implica inversión: más almacenamiento, más ancho de banda, más automatización y más complejidad operativa.

Cómo definir un RTO adecuado

El RTO depende de cuánto tiempo puede funcionar la organización sin un sistema específico.

Para una plataforma de comercio electrónico, una caída de varias horas puede ser inaceptable. Para un sistema interno de reportes, quizá una recuperación al día siguiente sea suficiente. Para correo, autenticación o sistemas de atención al cliente, la tolerancia suele ser baja porque afectan a múltiples áreas.

La pregunta clave es: ¿cuánto tiempo puede estar detenido este servicio antes de causar daño significativo?

Un RTO bajo puede requerir alta disponibilidad, ambientes de contingencia, restauración automatizada, infraestructura como código, monitoreo, runbooks y pruebas periódicas. Sin estos elementos, el RTO definido será solo una aspiración, no una capacidad real.

Backup no es lo mismo que recuperación

Uno de los errores más comunes es asumir que tener backups equivale a estar protegido. No es cierto.

Un backup que no se puede restaurar, que tarda demasiado, que está corrupto o que no cubre los datos correctos no cumple su función. La estrategia debe incluir pruebas de restauración, validación de integridad, control de versiones, retención adecuada y protección contra ransomware.

También importa dónde están los backups. Una copia almacenada en el mismo entorno comprometido puede ser inútil ante un ataque. Por eso se suelen aplicar principios como copias fuera de línea, almacenamiento inmutable, separación de credenciales y esquemas tipo 3-2-1: tres copias, en dos medios distintos, con una fuera del sitio principal.

RPO y RTO frente a ransomware

El ransomware ha cambiado la forma de diseñar backups. Ya no basta con restaurar datos después de una falla accidental. Hay que asumir que un atacante puede intentar cifrar, borrar o contaminar los respaldos.

En este escenario, el RPO debe considerar no solo la frecuencia del backup, sino también la posibilidad de que las copias recientes estén afectadas. El RTO debe contemplar el tiempo necesario para identificar un punto limpio de restauración, reconstruir sistemas, rotar credenciales y validar que la amenaza fue contenida.

Una recuperación rápida pero insegura puede reactivar el incidente. Por eso, en ciberseguridad, RTO no debe medirse solo como “volver a encender sistemas”, sino como restaurar operación de forma controlada.

El equilibrio entre costo y riesgo

RPO y RTO bajos suelen ser deseables, pero no siempre son económicamente racionales. Reducir la pérdida máxima de datos y el tiempo de recuperación requiere inversión.

La decisión correcta no es buscar siempre cero pérdida y cero interrupción. Eso puede ser técnicamente complejo y financieramente desproporcionado. Lo correcto es alinear cada sistema con su impacto real en el negocio.

Un sistema crítico puede justificar replicación en tiempo casi real y recuperación automatizada. Un sistema secundario puede operar con backups diarios y recuperación manual. La madurez está en diferenciar, no en aplicar la misma política a todo.