Cuando un servidor cae, una base de datos se corrompe o un ataque cifra tus sistemas, las dos primeras preguntas que importan son siempre las mismas: ¿cuánto tardamos en volver a operar? y ¿cuántos datos hemos perdido por el camino? Esas dos preguntas tienen nombre técnico, RTO y RPO, y están en el centro de lo que en el sector se llama disaster recovery (recuperación ante desastres). Con ellas se decide cuánto invertir en copias de seguridad y continuidad. En esta guía te explicamos qué es el disaster recovery, en qué se diferencia del backup y de la alta disponibilidad, cómo calcular RTO y RPO para tu negocio y cómo se traducen en un plan de recuperación ante desastres (DRP) que funcione el día que haga falta.
Qué es el RTO (tiempo de recuperación)
El RTO (Recovery Time Objective) es el tiempo máximo que tu empresa puede tolerar con un sistema caído antes de que el impacto sea inaceptable. Es la respuesta a «¿cuánto podemos estar parados?». Si tu ERP se cae a las 9:00 y tu RTO es de cuatro horas, el objetivo es tenerlo operativo antes de las 13:00, y toda la estrategia de recuperación (backups, réplicas, procedimientos, quién hace qué) debe estar dimensionada para cumplir ese plazo. Cada RTO tiene su coste. Recuperar en minutos exige infraestructura redundante con failover automático; recuperar en horas se resuelve con buenos backups y un procedimiento ensayado; recuperar «cuando se pueda» equivale a no tener plan. Y cada sistema puede tener el suyo, porque el ERP no tolera lo mismo que la intranet.
Un RTO bajo (minutos) exige infraestructura redundante y mecanismos de conmutación automática, y cuesta más. Un RTO alto (un día entero) permite estrategias más sencillas y económicas. Lo que fija el RTO es el coste de estar parado.
Qué es el RPO (cuántos datos puedes perder)
El RPO (Recovery Point Objective) es la cantidad máxima de datos que puedes permitirte perder, medida en tiempo. Es la respuesta a «¿hasta qué momento podemos retroceder sin que duela?». Si haces una copia cada 24 horas y el fallo ocurre justo antes de la siguiente, podrías perder casi un día entero de trabajo: ese es tu RPO real, independientemente del que creas tener. Por eso el RPO se decide primero y la frecuencia de copia después, no al revés: un RPO de 15 minutos exige replicación continua o incrementales muy frecuentes; uno de 24 horas se cubre con la copia nocturna de toda la vida. Y varía por sistema: perder un día de la web corporativa es asumible, perder un día de pedidos o de facturación puede no serlo.
Un ejemplo claro: una gestoría que registra facturas durante toda la jornada no puede permitirse perder un día de altas. Necesita un RPO de minutos, lo que implica copias frecuentes o replicación continua. En cambio, un sitio corporativo que se actualiza una vez por semana puede vivir con un RPO de varios días sin mayor problema.
Por qué RTO y RPO van siempre juntos
Son dos ejes distintos del mismo problema y conviene no confundirlos. El RTO mide tiempo de inactividad; el RPO mide pérdida de datos. Puedes tener un RTO excelente (recuperas el sistema en minutos) y un RPO malo (recuperas, pero con los datos de ayer). O al revés. Una estrategia de recuperación seria define ambos para cada sistema crítico por separado, porque no todo tu negocio tiene las mismas necesidades.
- RTO: cuánto tiempo aguantas parado. Marca el diseño de la infraestructura.
- RPO: cuántos datos asumes perder. Marca la frecuencia de las copias.
Cómo calcularlos para tu empresa
No hay un número universal: depende de lo que cuesta cada hora de parada y cada hora de datos perdidos en tu negocio concreto. El método es sencillo y se hace con el equipo de negocio, no solo con el técnico: se listan los sistemas, se estima para cada uno el coste por hora de caída (ventas paradas, personal sin trabajar, penalizaciones, imagen) y el coste de rehacer o perder los datos de una hora, y de ahí salen un RTO y un RPO por sistema que la parte técnica traduce a solución y presupuesto. El error habitual es hacerlo al revés, comprar primero la herramienta de backup y aceptar como objetivos lo que la herramienta dé de sí. En una tarde de trabajo conjunto sale una tabla que evita tanto pagar redundancia innecesaria como descubrir el hueco el día del incidente. Los pasos:
- Inventaría tus sistemas y clasifícalos por criticidad: ¿cuáles paran el negocio si caen?
- Para cada uno, estima el coste de una hora de inactividad (ventas perdidas, parálisis del equipo, penalizaciones, daño reputacional).
- Define el RTO: el tiempo máximo que ese coste es asumible.
- Define el RPO: cuánto trabajo perdido podrías rehacer o asumir sin un impacto grave.
- Contrasta esos objetivos con lo que tu infraestructura permite hoy. La diferencia es tu plan de mejora.
El error más común es fijar RTO y RPO de cero «por seguridad». La recuperación instantánea sin pérdida de datos existe, pero es cara y rara vez la necesita todo el negocio. Lo honesto es ajustar la exigencia (y el gasto) a cada sistema según lo que de verdad cuesta su caída.
De los objetivos a la estrategia de backups y continuidad
Una vez tienes los números, dictan las decisiones técnicas. Un RPO de minutos exige copias muy frecuentes o replicación; un RPO de un día se cubre con una copia diaria bien verificada. Un RTO de minutos pide sistemas redundantes con conmutación automática; un RTO de horas se puede cubrir restaurando desde copia sobre infraestructura preparada.
Se olvida demasiado que una copia que nunca se ha probado a restaurar no garantiza nada. Cualquier plan serio de backup y continuidad de negocio incluye pruebas de restauración periódicas, retención adecuada (incluida una copia fuera de línea o aislada frente a ransomware) y un procedimiento documentado de quién hace qué cuando suena la alarma. Sin esa parte, los mejores RTO y RPO sobre el papel no sirven de nada.
Por qué insistimos en probar las restauraciones
Un objetivo de recuperación solo vale lo que valga la última prueba real. Dos ejemplos de nuestro día a día (anonimizados):
En una prueba de restauración programada, una copia no arrancaba: el proceso usaba la llave de cifrado equivocada. Se diagnosticó y corrigió en menos de una hora, con calma, porque era un simulacro. Ese mismo fallo descubierto el día de un incidente real habría convertido un RTO de horas en uno de días. Es la razón por la que las restauraciones se prueban de forma periódica, no se presuponen.
En otro caso, tras revisar la capacidad de la plataforma de copias, se añadió un segundo repositorio de backups en otra ubicación. Semanas después, esa redundancia mantuvo el servicio de copias intacto durante una sustitución de hardware que de otro modo habría dejado a los clientes sin protección temporalmente.
El resultado de trabajar así se puede ver con números en nuestro caso de backup y continuidad: 18 meses sin un solo corte por copias y RTO garantizado por debajo de 2 horas, con pruebas de restauración automáticas cada mes.
Disaster recovery frente a backup, alta disponibilidad y continuidad de negocio
Son cuatro términos que se mezclan en cualquier conversación sobre resiliencia y que no significan lo mismo. Tenerlos claros evita comprar la herramienta equivocada para el problema que se tiene.
Disaster recovery vs backup
El backup es la copia de los datos. El disaster recovery es todo lo que hace falta para volver a operar a partir de esa copia: dónde se restaura, en cuánto tiempo, quién lo hace y en qué orden. Tener backup sin plan de recuperación es tener los ingredientes sin la receta. Un backup responde al RPO; el disaster recovery responde además al RTO.
Disaster recovery vs alta disponibilidad
La alta disponibilidad evita la parada: sistemas redundantes que conmutan solos (failover) cuando falla un componente, con RTO de segundos o minutos. El disaster recovery asume que la parada ha ocurrido y organiza la vuelta, normalmente desde otra ubicación o desde copias. La alta disponibilidad no sustituye al disaster recovery: un ransomware o un borrado accidental se replican a todos los nodos en cuestión de segundos, y ahí solo te saca una copia anterior y un plan para restaurarla.
Disaster recovery vs plan de continuidad de negocio
El plan de continuidad de negocio (BCP) abarca a toda la empresa: cómo se sigue vendiendo, atendiendo y facturando mientras la tecnología no está. El disaster recovery es la parte tecnológica de ese plan: recuperar sistemas y datos. Una pyme puede empezar por el disaster recovery, que es lo más concreto, y ampliarlo después al resto de la organización sin necesidad de certificarse en ninguna norma.
Qué contiene un plan de disaster recovery (DRP)
- Inventario de sistemas con su RTO y RPO.
- Dónde y cómo se restaura cada uno (mismo CPD, otro CPD, nube).
- Orden de recuperación: qué tiene que estar arriba antes que qué (red, identidad, base de datos, aplicación).
- Responsables y forma de contacto cuando el correo corporativo también está caído.
- Calendario de pruebas de restauración y registro de resultados.
Define tus objetivos antes de que el incidente lo haga por ti
RTO y RPO convierten una preocupación difusa («espero no perder nada») en objetivos medibles que guían inversión y diseño. En Elimática ayudamos a empresas a definir esos objetivos por sistema y a montar la estrategia de backup y continuidad que de verdad los cumple, con pruebas de restauración incluidas. Si quieres saber si tu plan actual aguantaría un incidente real, cuéntanos tu caso y lo revisamos contigo.