RPO y RTO: las dos métricas que convierten un backup en continuidad de negocio

Tener copias de seguridad está bien. Saber para qué sirven, cuándo se restauran y cuántos datos se pueden perder está mucho mejor. Ahí entran dos siglas que parecen de consultoría, pero que deberían estar en cualquier conversación seria sobre disponibilidad: RPO y RTO. No son conceptos reservados a bancos, hospitales o grandes plataformas cloud. También afectan a una tienda online, una pyme, un despacho profesional o un proyecto web pequeño. La diferencia es clara: una copia de seguridad responde a “qué puedo recuperar”; RPO y RTO responden a “cuánto daño puedo asumir antes de que el problema sea crítico”.

RPO: cuántos datos puedes permitirte perder

RPO significa Recovery Point Objective. El glosario del NIST lo define como el punto temporal al que deben recuperarse los datos después de una interrupción. Dicho de forma práctica: si tu RPO es de 24 horas, aceptas perder hasta un día de información. Si es de una hora, necesitas copias mucho más frecuentes. Si es casi cero, ya no hablamos de un backup nocturno, sino de replicación, journaling, snapshots frecuentes o arquitecturas más sofisticadas.

La clave es que el RPO no lo debería decidir solo el departamento técnico. Lo marca el negocio. Un blog puede tolerar perder el último borrador. Una gestoría no debería perder facturas del día. Un comercio electrónico que pierda pedidos confirmados tiene un problema operativo, contable y reputacional. Por eso el RPO obliga a clasificar datos: no todo merece el mismo nivel de protección.

RTO: cuánto tiempo puedes estar parado

RTO significa Recovery Time Objective. Según el NIST, mide el tiempo máximo que un sistema puede estar en fase de recuperación antes de impactar negativamente en la misión o en los procesos de negocio. En lenguaje más directo: cuánto tiempo puedes aguantar sin ese servicio.

Aquí conviene separar dos ideas que se confunden mucho. Tener una copia no significa poder volver rápido. Restaurar varios terabytes desde un almacenamiento lento puede llevar horas o días. Levantar una base de datos, comprobar su integridad, reconfigurar DNS, validar credenciales y asegurar que la aplicación vuelve en un estado consistente también consume tiempo.

Por eso el RTO condiciona la arquitectura. Si una aplicación puede estar caída un día, quizá basta con una restauración manual documentada. Si debe volver en menos de una hora, hacen falta automatización, infraestructura preparada, pruebas periódicas y procedimientos claros. Cuanto más bajo sea el RTO, más cara y compleja suele ser la solución.

Backup, alta disponibilidad y recuperación ante desastres no son lo mismo

Uno de los errores habituales es meterlo todo en el mismo saco. Backup, alta disponibilidad y recuperación ante desastres se complementan, pero no resuelven exactamente el mismo problema.

El backup permite recuperar datos desde un punto anterior. La alta disponibilidad intenta que el servicio siga funcionando aunque falle un componente: balanceadores, nodos redundantes, clusters, bases de datos replicadas o zonas de disponibilidad. La recuperación ante desastres mira un escenario más duro: qué ocurre si cae el centro de datos, se compromete el entorno principal, falla un proveedor cloud o un ransomware deja inutilizable la infraestructura.

Esta distinción importa porque una arquitectura puede tener alta disponibilidad y aun así replicar un borrado accidental en segundos. También puede tener backups correctos, pero tardar demasiado en restaurar. En Tecnoic ya traté la regla 3-2-1 para copias de seguridad: tres copias, dos soportes y una fuera de la ubicación principal. RPO y RTO añaden la capa que falta: medir si esa estrategia sirve realmente para volver a operar.

El ransomware cambió la forma de pensar la recuperación

Durante años se hablaba de backups casi siempre pensando en discos rotos, borrados accidentales o migraciones fallidas. Todo eso sigue pasando. Pero el ransomware ha cambiado la conversación. Ya no basta con tener copias; hay que protegerlas, aislarlas y probarlas.

La guía StopRansomware de CISA recomienda mantener copias offline, cifradas y comprobar de forma regular su disponibilidad e integridad. Tiene sentido: muchos ataques intentan localizar y destruir los backups accesibles antes de cifrar los sistemas principales. Si la copia está conectada permanentemente, con las mismas credenciales y sin retención suficiente, puede caer con el resto.

Aquí RPO y RTO ayudan a tomar decisiones incómodas. ¿Cada cuánto hago copias inmutables? ¿Cuántos días de histórico necesito? ¿Qué sistemas restauro primero? ¿Puedo operar de forma degradada mientras se recupera todo? La respuesta no siempre es “recuperarlo todo cuanto antes”. A veces lo inteligente es definir un mínimo operativo viable: facturación, atención al cliente, identidad, correo, web pública o base de datos crítica.

Cómo definir RPO y RTO sin caer en fantasías

La parte difícil no es escribir “RPO: 15 minutos” y “RTO: 1 hora” en un documento. Eso lo puede hacer cualquiera. La parte seria es demostrar que se puede cumplir.

Un buen punto de partida es hacer inventario de servicios y clasificarlos por impacto. No necesita el mismo tratamiento una intranet informativa que el sistema de pedidos, el ERP, el correo corporativo o la base de datos de clientes. Después hay que cruzar tres variables: pérdida máxima de datos, tiempo máximo de parada y coste de la solución.

También conviene hacer pruebas reales. Restaurar un archivo no es restaurar un servicio completo. Hay que probar bases de datos, permisos, dependencias, certificados, DNS, integraciones con terceros y credenciales. En continuidad, lo que no se ensaya tiende a fallar el día que hace falta.

La pregunta buena no es “¿tenemos backup?”, sino “¿cuándo fue la última vez que restauramos algo importante y cuánto tardamos?”. Esa respuesta vale más que muchas diapositivas.

Conclusión

RPO y RTO convierten la recuperación en una decisión medible. Obligan a dejar de hablar de backups en abstracto y empezar a hablar de pérdida aceptable, tiempo de parada, coste y prioridades reales. No todos los sistemas necesitan el máximo nivel de protección, pero todos deberían tener una respuesta clara. ¿Tu organización sabe cuánto puede perder y cuánto puede estar parada? Te leo en comentarios.