RPO vs RTO: cómo definir antes de comprar backup (y por qué la mayoría de las empresas se equivoca en esa cuenta)

Casi toda empresa que contrata backup hace la misma pregunta equivocada: "¿cuánto cuesta el backup?"

La pregunta correcta es otra: "¿cuánto tiempo de datos puedo perder y cuánto tiempo puedo estar fuera de servicio hasta recuperar?"

Esas dos respuestas tienen nombre técnico — RPO y RTO — y son ellas las que definen el diseño real de una solución de backup, no al contrario. Comprar backup sin definir RPO y RTO antes es como comprar un seguro de coche sin saber si quiere cobertura contra robo, contra colisión o ambas — solo descubrirá lo que compró el día en que necesite usarlo.

En este artículo

1. Qué es RPO, en términos prácticos

2. Qué es RTO, en términos prácticos

3. Por qué las dos métricas juntas definen el costo

4. El error más común: definir RPO/RTO después de comprar la solución

5. Cómo calcular RPO y RTO para su negocio

6. Backup no es igual a Disaster Recovery

7. La política 3-2-1 (y por qué sigue siendo la base de todo)

8. Restore probado: el paso que todos se saltan

9. Conclusión

Qué es RPO, en términos prácticos

RPO — Recovery Point Objective responde a una pregunta: si algo sale mal ahora, ¿cuál es la antigüedad máxima aceptable del dato que voy a recuperar?

Si su backup se ejecuta una vez al día, a medianoche, y el sistema falla a las 17h del día siguiente, el RPO real de su entorno es de hasta 24 horas — porque la última copia válida tiene esa antigüedad. Todo lo que se escribió, vendió, facturó o registró entre la medianoche y las 17h no existe en ninguna copia. No es que vaya a tardar en recuperarse — es que ese dato específico nunca volverá a existir.

RPO es, por lo tanto, una decisión sobre cuánto trabajo la empresa está dispuesta a perder y rehacer manualmente (cuando es posible rehacerlo) en caso de desastre.

• RPO de 24 horas: el backup diario es suficiente.

• RPO de 4 horas: el backup debe ejecutarse cada 4 horas, o usar tecnología de réplica continua.

• RPO de minutos o próximo a cero: exige replicación síncrona o casi síncrona entre entornos — una arquitectura mucho más cara y más compleja, típicamente reservada a sistemas donde cada transacción tiene valor financiero directo (ERP financiero, sistemas de pago, bases de datos transaccionales críticas).

Qué es RTO, en términos prácticos

RTO — Recovery Time Objective responde a una pregunta diferente: después de que ocurre el desastre, ¿cuánto tiempo puede estar la operación detenida hasta volver a funcionar?

Si el RTO definido es de 4 horas, esto significa que, entre el momento de la falla y el momento en que el sistema está de vuelta — restaurado, validado y en producción — no pueden pasar más de 4 horas. Este número conduce decisiones de arquitectura completamente diferentes de las del RPO:

• RTO de días: restaurar a partir de un backup frío (almacenamiento externo, cinta, nube fría) es aceptable.

• RTO de horas: exige infraestructura de restauración rápida — almacenamiento de alto rendimiento, automatización de restauración, entorno de contingencia preconfigurado.

• RTO de minutos: exige un entorno de failover automático, con una réplica ya en ejecución (o lista para encenderse casi instantáneamente) en otro lugar — lo que es, en la práctica, una arquitectura de Disaster Recovery completa, no solo backup.

Por qué las dos métricas juntas definen el costo

RPO y RTO no son números aislados — forman una matriz, y cada combinación tiene una arquitectura (y un costo) diferente:

El error más caro que se ve en el mercado es que la empresa pida, sin darse cuenta, la esquina inferior derecha de esa tabla ("no podemos perder nada y no podemos detenernos nunca") pagando el precio de la esquina superior izquierda ("un backup básico, lo más barato posible"). Esas dos cosas son físicamente incompatibles — y es función de quien diseña la solución dejar eso claro antes de cerrar contrato, no después de un incidente.

El error más común: definir RPO/RTO después de comprar la solución

El orden natural (y equivocado) con el que la mayoría de las empresas aborda el backup es:

1. Se investiga una herramienta o un plan de backup.

2. Se compra con base en el precio y el espacio de almacenamiento.

3. Solo durante un incidente real, se descubre: "esperábamos recuperar en 1 hora, pero el proceso está llevando 2 días" o "creíamos que teníamos los datos de ayer, pero el último backup íntegro tiene una semana".

El orden correcto invierte completamente esa lógica:

1. Se definen el RPO y el RTO por sistema — no todo sistema de la empresa tiene el mismo nivel de criticidad. El ERP financiero puede exigir RPO de 1 hora; un servidor de archivos administrativos puede tolerar RPO de 24 horas sin problema real.

2. Se diseña la arquitectura de backup y/o DR que cumple con esos números — frecuencia de backup, tipo de almacenamiento, necesidad o no de réplica en otro sitio.

3. Solo entonces se elige la herramienta (Veeam, por ejemplo) y se dimensiona el repositorio, el ancho de banda de red y la infraestructura de restauración.

Hacer esto al revés es decidir el remedio antes de conocer el diagnóstico.

Cómo calcular RPO y RTO para su negocio

No existe un RPO/RTO "correcto" universal — existe el RPO/RTO correcto para cada sistema, con base en una pregunta financiera y operativa simple: ¿cuánto cuesta, por hora, quedarse sin ese sistema, y cuánto cuesta perder X horas de datos de ese sistema?

Un ejercicio práctico, sistema por sistema:

• Enumere los sistemas críticos (ERP, correo electrónico, base de datos, sistema de punto de venta, CRM, archivos compartidos).

• Para cada uno, pregunte: "si este sistema desaparece ahora, ¿qué se detiene en la empresa y cuánto cuesta eso por hora?" — esto le da una pista fuerte del RTO aceptable.

• Para cada uno, pregunte: "si pierdo las últimas X horas de datos de este sistema, ¿qué significa eso en retrabajo o pérdida real?" — esto le da el RPO aceptable.

• Clasifique los sistemas en niveles (por ejemplo: crítico, importante, baja prioridad) — porque dimensionar todo en el nivel "crítico" sin necesidad real es la forma más rápida de pagar caro por una protección que el negocio no necesita.

Este ejercicio, formalizado, es lo que se denomina BIA — Business Impact Analysis, y es el punto de partida de cualquier plan de continuidad de negocio serio, no solo de backup.

Backup no es igual a Disaster Recovery

Esta es una confusión extremadamente común, y que vale la pena deshacer directamente: el backup protege los datos. Disaster Recovery protege la operación.

• Backup garantiza que existe una copia recuperable de sus datos en algún lugar, con una cierta frecuencia (RPO) y que puede restaurarse en un cierto tiempo (RTO), pero generalmente implica recrear o reconectar la infraestructura primero.

• Disaster Recovery (DR) garantiza que, incluso si se pierde todo el sitio primario (incendio, inundación, falla estructural, ataque de ransomware que destruye el entorno), existe una infraestructura alternativa — lista o casi lista — para asumir la operación, con un RTO mucho más agresivo.

Una empresa puede tener un backup excelente y, aun así, no tener Disaster Recovery: si el backup está guardado, pero no existe ningún servidor, red o entorno para restaurarlo rápidamente, el RTO real puede ser de muchos días — incluso con el dato intacto. Es por eso que un plan de continuidad de negocio serio trata el BIA, RTO/RPO, arquitectura de DR y pruebas de simulación como piezas del mismo proceso, no como productos aislados.

La política 3-2-1 (y por qué sigue siendo la base de todo)

Independientemente del RPO y RTO definidos, existe una regla estructural de resiliencia que debería estar presente en cualquier estrategia de backup, conocida como regla 3-2-1:

• 3 copias de los datos (la copia de producción + dos copias de backup).

• 2 tipos diferentes de medios o almacenamiento (por ejemplo, un almacenamiento local y un almacenamiento en la nube — para no depender de un único tipo de fallo).

• 1 copia fuera del sitio principal (off-site o en la nube), para sobrevivir a un desastre físico que destruya el lugar de producción.

Una variación más moderna, especialmente relevante tras el crecimiento de ataques de ransomware dirigidos a backups, es la 3-2-1-1, que añade 1 copia inmutable — es decir, una copia que no puede ser alterada ni eliminada ni siquiera por un administrador comprometido, generalmente usando WORM (Write Once, Read Many) en almacenamiento de objetos. Esto es particularmente relevante porque los ataques de ransomware modernos ya apuntan específicamente a los repositorios de backup antes de cifrar la producción — sabiendo que, si destruyen el backup, la víctima no tiene alternativa más que pagar el rescate.

Restore probado: el paso que todos se saltan

Este es, posiblemente, el punto más descuidado en toda la discusión sobre backup: un backup que nunca se ha restaurado en una prueba es una suposición, no una garantía.

Es extremadamente común — más de lo que se imagina — que una empresa descubra, en el momento real de un incidente, que:

• El backup se estaba ejecutando, pero omitía archivos específicos por permisos.

• El backup de la base de datos se estaba realizando en modo inconsistente (sin aplicar el log de transacciones), lo que corrompía la restauración.

• El proceso de restauración documentado estaba desactualizado, referenciando un servidor que ya no existe.

• El tiempo real de restauración es el triple del RTO contratado, porque nadie lo había medido en la práctica.

Un programa de Backup como Servicio (BaaS) maduro incluye, como rutina — no como excepción — pruebas periódicas de restauración, validando no solo que el backup "existe", sino que efectivamente vuelve a funcionar dentro del RTO esperado. Esto debería ser tan rutinario como el propio backup, con un informe formal de cada prueba.

Conclusión

La pregunta "¿cuánto cuesta el backup?" solo puede responderse después de responder otras dos: cuántos datos puedo perder y cuánto tiempo puedo estar detenido.

Estos dos números — RPO y RTO — no son jerga técnica decorativa. Son la especificación real de lo que se está comprando. Sin ellos definidos antes de la contratación, la empresa solo descubrirá lo que compró en el peor momento posible: durante el incidente, cuando ya es tarde para negociar.

Nyverra estructura políticas de backup y disaster recovery a partir del RPO/RTO real de cada sistema de su negocio — con restore probado, retención adecuada e informes que demuestran, con datos, que la protección contratada funciona. Conozca la solución de Backup Veeam empresarial en nyverra.com.br/pt-br/backup-veeam-empresarial.