RTO y RPO explicados con dinero: cuánto tiempo y cuántos datos puedes perder
Dos siglas que definen todo tu diseño de respaldos y que se responden con una sola pregunta de negocio, no técnica.
Cada vez que alguien te propone un esquema de respaldos, detrás hay dos números que casi nunca se discuten con el negocio: cuántas horas de trabajo estás dispuesto a perder, y cuántas horas puedes operar sin sistemas. Todo el diseño —y todo el precio— sale de ahí.
Se llaman RPO y RTO. Suenan a jerga de consultor y en realidad son dos preguntas de negocio que solo tú puedes responder, porque dependen de cómo gana dinero tu empresa, no de qué tecnología usas. El error habitual es dejar que las conteste el área de sistemas por default: acaban definiéndose solas, según lo que ya estaba instalado, y nadie se entera hasta el día del incidente.
Este artículo las explica sin tecnicismos, muestra cuánto cuesta cada nivel y trae un taller de treinta minutos para definirlas con tus áreas esta semana.
Las dos siglas, en una línea de tiempo
La forma más rápida de entenderlas es verlas colocadas alrededor del momento de la falla.
←──── RPO ────→ ✕ falla ←────── RTO ──────→
──────┬────────────────────┬────────────────────────┬──────►
08:00 10:15 16:45
último el servidor el sistema
respaldo deja de vuelve a
responder operar
RPO real → 2 h 15 min de capturas que hay que rehacer
RTO real → 6 h 30 min sin poder facturar ni despacharRPO —objetivo de punto de recuperación— mira hacia atrás: cuánta información se pierde entre el último respaldo bueno y el momento de la falla. Se mide en datos: pedidos capturados, facturas emitidas, movimientos de almacén que habrá que volver a teclear con la ayuda de papeles y memoria.
RTO —objetivo de tiempo de recuperación— mira hacia adelante: cuánto tarda la empresa en volver a operar. Se mide en tiempo, y se traduce directo a dinero usando tu costo por hora de operación detenida.
Son independientes. Puedes tener un RPO excelente y un RTO pésimo: los datos están completos hasta el minuto de la falla, pero tardas tres días en levantar el sistema. Y al revés: recuperas en veinte minutos, con la información de anteayer. Cada uno se compra por separado y cada uno cuesta distinto.
La pregunta que define tu RPO
No es «¿cuántos datos podemos perder?» —a esa todo el mundo responde «ninguno»—. La pregunta útil es:
«Si mañana perdiéramos todo lo capturado desde ayer a las 8 de la noche, ¿cuántas horas de trabajo costaría reconstruirlo, y podríamos hacerlo?»
La segunda mitad es la importante. Reconstruir un día de pedidos con las órdenes de compra en papel es molesto pero posible. Reconstruir un día de lecturas de una báscula automática es sencillamente imposible: esa información no existe en ningún otro lado.
Cuando algo no se puede reconstruir, el RPO deja de ser una preferencia y se vuelve un requisito.
La pregunta que define tu RTO
Aquí la trampa es parecida. Preguntar «¿cuánto pueden estar sin el sistema?» produce siempre la misma respuesta: nada. La versión útil introduce el umbral del dolor real:
«¿A partir de cuántas horas detenidos empezamos a perder clientes, a incumplir entregas o a pagar penalizaciones? ¿Y qué podemos hacer a mano mientras tanto?»
La segunda pregunta suele revelar que hay más margen del que parecía. Muchas operaciones aguantan cuatro horas con papel y una hoja de cálculo; muy pocas aguantan dos días. Ese margen manual es dinero ahorrado en el diseño.
Cuánto cuesta cada nivel de RPO
Cada salto de exigencia cambia la tecnología necesaria, y con ella el precio. Los costos van en múltiplos relativos porque dependen mucho del entorno, pero la proporción entre niveles se mantiene bastante estable.
| RPO objetivo | Qué se necesita | Qué se pierde en un incidente | Costo relativo |
|---|---|---|---|
| 24 horas | Respaldo completo nocturno, copia fuera de sitio | Un día de capturas. Reconstruible si hay soporte documental | ×1 |
| 4 horas | Respaldos incrementales varias veces al día | Media jornada. Molesto pero manejable | ×1.5 |
| 1 hora | Respaldo continuo del log de transacciones | Lo capturado en la última hora | ×2.5 |
| 15 minutos | Envío continuo de logs a un servidor secundario | Prácticamente nada perceptible | ×4 |
| Cercano a cero | Replicación síncrona entre dos sitios | Nada. Cada transacción se confirma en ambos lados | ×8 o más |
Cuánto cuesta cada nivel de RTO
| RTO objetivo | Qué se necesita | Costo relativo |
|---|---|---|
| 2 a 3 días | Respaldo externo y conseguir hardware cuando ocurra. Sin equipo de repuesto | ×1 |
| 24 horas | Hardware de repuesto disponible y procedimiento de recuperación probado | ×1.5 |
| 8 horas | Servidor alterno preconfigurado o máquina virtual lista en la nube | ×2.5 |
| 2 horas | Sistema en espera con los datos ya sincronizados, listo para tomar el control | ×5 |
| Minutos | Alta disponibilidad con conmutación automática y sin intervención humana | ×10 o más |
Cuando alguien pide RTO de minutos y RPO de cero, no está pidiendo un respaldo: está pidiendo una arquitectura que cuesta diez veces más y que requiere personal para operarla. La respuesta correcta no es decir que no. Es poner las dos columnas juntas —lo que cuesta el nivel pedido y lo que cuesta la caída que evita— y dejar que el negocio decida con esa información. Casi siempre la conclusión cambia.
El error de ponerle el mismo objetivo a todo
Definir un solo RTO y un solo RPO para toda la empresa es lo que hace que estos proyectos salgan carísimos o inútiles. Si aplicas el objetivo del sistema más crítico a todo, pagas de más por cosas que no lo valen; si aplicas el promedio, dejas descubierto lo importante.
Tres niveles bastan para casi cualquier PyME:
| Nivel | Sistemas típicos | RTO | RPO |
|---|---|---|---|
| Crítico | Facturación, ERP, línea de producción, tienda en línea | 4 horas | 1 hora |
| Importante | CRM, portal de clientes, sistemas de reportes operativos | 24 horas | 8 horas |
| Diferible | Archivos históricos, ambientes de pruebas, herramientas internas | 3 a 5 días | 24 horas |
Un sistema clasificado como «importante» puede ser requisito para arrancar uno «crítico»: el directorio de usuarios, el servidor de licencias, el DNS interno. Si el crítico tiene RTO de 4 horas y depende de algo con RTO de 24, tu RTO real es de 24. Revisa la cadena completa antes de firmar los números, porque esta es la sorpresa más común el día del incidente.
El taller de 30 minutos
Con los responsables de cada área en la misma sala —o en la misma llamada— y sin nadie de sistemas explicando tecnología. Solo negocio.
-
1Lista procesos, no sistemas 5 minutos
«Facturar», «despachar pedidos», «pagar nómina», «atender clientes». La gente de negocio piensa en procesos y responde mejor así. La traducción a sistemas la haces después, tú.
-
2La pregunta de RPO, proceso por proceso 10 minutos
«Si perdiéramos lo capturado desde ayer a las 8, ¿cuántas horas costaría rehacerlo y sería posible?» Anota las dos respuestas. Marca con rojo todo lo que resulte imposible de reconstruir.
-
3La pregunta de RTO, proceso por proceso 10 minutos
«¿A partir de cuántas horas detenidos empezamos a perder dinero de verdad, y qué podemos hacer a mano mientras tanto?» El margen manual que aparezca aquí es dinero que no vas a tener que gastar en infraestructura.
-
4Clasifica y escribe 5 minutos
Cada proceso a uno de los tres niveles, con las cifras acordadas. Una sola página, firmada por quien participó. Ese documento es el que va a gobernar todas las decisiones de respaldo de los próximos años.
Porque no se discute tecnología. Nadie tiene que saber qué es una réplica ni un log de transacciones. Se responden dos preguntas de negocio y se clasifica. El diseño técnico viene después, y ya con el objetivo puesto es una decisión sencilla en lugar de una negociación interminable.
Del papel a la realidad
Los objetivos escritos no sirven de nada hasta que se comprueban. Un RTO de 4 horas en el documento y una recuperación real de 31 horas no es un plan: es una ficción compartida, y de las caras.
Lo que sigue después del taller
Imprimir o guardar como PDF- El documento de objetivos está firmado por las áreas de negocio, no solo por sistemas Quien define el objetivo es quien vive las consecuencias
- Cada sistema crítico tiene su RTO y su RPO por escrito Números concretos, no «lo antes posible»
- Se revisó la cadena de dependencias de cada sistema crítico Directorio, DNS, licencias, integraciones con terceros
- El diseño de respaldos actual se comparó contra los objetivos acordados Aquí es donde suele aparecer la brecha real
- Se midió el tiempo de recuperación real con una prueba, no con una estimación Es el único dato que vale
- Si el RTO real no alcanza el objetivo, se decidió qué cambia: el diseño o la promesa Las dos opciones son válidas; dejarlo así no lo es
- Los objetivos se revisan una vez al año o cuando cambia un proceso importante Un sistema nuevo puede volverse crítico sin que nadie lo reclasifique
El punto cinco es el que más vale y el que más se pospone. Aquí explicamos cómo hacerlo: cómo probar que tus respaldos realmente funcionan.
Y si el escenario que te preocupa es un ataque en lugar de una falla de hardware, considera que ahí el RPO se calcula distinto: hay que recuperar desde un punto anterior al compromiso, que puede ser de semanas atrás. Lo tratamos en cómo opera un ransomware en una PyME.
RTO y RPO no son decisiones técnicas con consecuencias de negocio. Son decisiones de negocio con consecuencias técnicas, y por eso no las puede tomar el área de sistemas sola.
¿Tus objetivos de recuperación están escritos o son un supuesto?
Facilitamos el taller con tus áreas de negocio, traducimos los objetivos acordados a un diseño técnico concreto con su costo, y medimos tu tiempo de recuperación real con una prueba de restauración. Sales con un documento firmado y con la brecha entre lo que prometes y lo que puedes cumplir, medida.
- —Definición de objetivos de recuperación (RTO y RPO)
- —Diseño de respaldos, replicación y alta disponibilidad
- —Pruebas de restauración y planes de continuidad
- —Mantenimiento y monitoreo de servidores