El RPO, objetivo de punto de recuperación, es la cantidad máxima de datos, medida en tiempo, que una empresa acepta perder tras un incidente. Si el RPO es de cuatro horas, las copias tienen que permitir volver a un estado de hace cuatro horas como mucho.

El RTO, objetivo de tiempo de recuperación, es el tiempo máximo que puede pasar desde que un sistema cae hasta que vuelve a estar disponible para trabajar. Incluye detectar el problema, conseguir dónde restaurar, recuperar los datos y comprobar que todo funciona.

¿Qué diferencia hay entre RPO y RTO?

El RPO mide cuántos datos puedes perder y el RTO cuánto tiempo puedes estar sin trabajar. El primero depende sobre todo de la frecuencia de las copias; el segundo, de cómo y dónde se restaura.

¿Cómo se calcula el RPO y el RTO de una empresa?

Se fijan sistema por sistema a partir de un análisis de impacto en el negocio. Para cada aplicación se estima cuánto cuesta rehacer el trabajo perdido y cuánto cuesta cada hora o cada día de parada, y se elige el objetivo que compensa frente a lo que cuesta alcanzarlo.

¿Una copia diaria es suficiente?

Depende del sistema. Para datos que cambian poco puede bastar, pero con una copia diaria se puede perder el trabajo de toda una jornada. Para archivos compartidos y aplicaciones de gestión suele hacer falta copiar varias veces al día.

¿Cada cuánto hay que probar la recuperación?

Con regularidad y después de cada cambio importante en los sistemas. Conviene combinar restauraciones pequeñas y frecuentes con pruebas completas, en las que se mide el tiempo real hasta que los usuarios vuelven a trabajar.

Continuidad

RPO y RTO: dos preguntas que toda empresa debería responder

Una estrategia de continuidad necesita convertir «no podemos perder datos» en decisiones concretas y comprobables. El RPO y el RTO son las dos medidas que lo hacen posible. Esta guía explica qué significan, cómo fijarlas por sistema y cómo llevarlas a un plan de copias que funcione.

Callsoft · Guía práctica para empresas · 8 min de lectura · Actualizada el 25 de septiembre de 2026

Dos preguntas antes de hablar de copias

Cuando se pregunta a una empresa cuántos datos puede perder, la respuesta casi siempre es «ninguno». Y cuánto tiempo puede estar parada, «nada». Son respuestas comprensibles, pero no sirven para diseñar nada: la protección total no existe y acercarse a ella cuesta mucho.

El RPO y el RTO sirven para cambiar esa conversación. Convierten un deseo en dos cifras por sistema, que se pueden comparar con lo que hoy tienes y con lo que costaría mejorarlo. Con ellas se decide qué copiar, cada cuánto, dónde y cómo recuperar.

En la práctica: si no has fijado un RPO y un RTO, tu plan de copias no está diseñado. Está heredado de lo que alguien configuró un día.

Armarios rack con cableado de red en un centro de datos

RPO: cuántos datos puedes perder

RPO son las siglas de recovery point objective, objetivo de punto de recuperación. Es la cantidad máxima de información, medida en tiempo, que la empresa acepta perder si ocurre un incidente. Si tu RPO es de cuatro horas, tras un fallo tienes que poder volver a un estado de hace cuatro horas como mucho.

El RPO lo marca, sobre todo, la frecuencia de las copias. Con una copia cada noche, lo que se pierde en el peor caso es todo lo trabajado desde la última copia: si el servidor falla a última hora de la tarde, se pierde prácticamente la jornada.

Cómo se reduce el RPO

Cuanto menor sea el margen, más exigente tiene que ser la estrategia de copia o de réplica.

Copia diaria: suficiente para datos que cambian poco o que se pueden reconstruir.
Varias copias al día: habitual para archivos compartidos y aplicaciones de gestión.
Instantáneas frecuentes: copias rápidas del estado de un servidor o de un almacenamiento a intervalos cortos.
Réplica continua: los cambios se copian casi en tiempo real a otro sistema. Da el RPO más bajo, pero replica también los errores y el cifrado de un ransomware, así que no sustituye a la copia.

El RPO real ante un ransomware

Si un ransomware lleva días dentro antes de cifrar, las copias más recientes pueden estar contaminadas. El punto de recuperación útil es el último limpio, que puede ser bastante anterior al último. Por eso importan la retención y las copias inmutables, las que no se pueden modificar ni borrar durante un tiempo.

RTO: cuánto tiempo puedes estar parado

RTO son las siglas de recovery time objective, objetivo de tiempo de recuperación. Es el tiempo máximo que puede pasar desde que un sistema cae hasta que vuelve a estar disponible para trabajar. No es el tiempo que tarda en copiarse un fichero, sino todo el camino hasta que la gente puede volver a usarlo.

Detectar el problema y avisar a quien tiene que actuar.
Decidir qué se restaura y desde qué punto, sobre todo si hay sospecha de ataque.
Disponer de dónde restaurar, porque si el servidor está roto hace falta otro equipo o un entorno en la nube.
Restaurar los datos y los sistemas, que con volúmenes grandes puede llevar mucho más de lo esperado.
Comprobar que todo funciona, reconectar a los usuarios y revisar que no falta información.

Cómo se reduce el RTO

Tener una copia local además de la externa acelera la restauración. Algunas herramientas permiten arrancar un servidor virtual directamente desde la copia mientras se restaura en segundo plano. Y para los sistemas más críticos existe la recuperación ante desastres en la nube: una réplica preparada para arrancar en otro sitio si el principal no está disponible.

En la práctica: el RTO se mide de principio a fin. Si la copia se restaura en poco tiempo pero tardas dos días en conseguir un servidor, tu RTO real es de dos días.

Un ejemplo con RPO, RTO y lo que cuesta la parada

Imagina, como ejemplo genérico, una oficina cuyo programa de gestión y archivos compartidos están en un servidor local que se copia cada noche. Un martes a media tarde el servidor deja de arrancar.

El RPO de esa situación es la copia de la noche del lunes: se pierde lo trabajado el martes. El RTO depende de si hay dónde restaurar. Si la copia está en la nube y no hay otro equipo, hay que conseguir hardware, instalarlo y descargar los datos, y la oficina puede estar parada varios días. Si existe un equipo de reserva o la posibilidad de arrancar el servidor en la nube desde la copia, el plazo baja mucho.

Para saber si eso es aceptable hay que preguntar al negocio, no a informática: cuánto cuesta un día sin facturar, sin atender pedidos o sin acceder a los expedientes, y cuánto trabajo supone rehacer lo perdido.

Tiempo máximo tolerable y análisis de impacto

Por encima del RTO está el tiempo máximo tolerable de parada: el punto a partir del cual el daño al negocio es grave o irreversible. El RTO siempre debe quedar por debajo. Para fijar ambos se hace un análisis de impacto en el negocio, conocido como BIA: una revisión, proceso a proceso, de qué pasa si se detiene y durante cuánto tiempo se puede aguantar.

No todo es igual de crítico: clasificar sistemas

Contabilidad, aplicaciones de gestión, archivos compartidos, correo o un servidor de producción no necesitan la misma protección. Aplicar a todo el objetivo más exigente dispara el coste; aplicar a todo el más relajado deja expuesto lo importante.

Críticos: sin ellos la empresa no factura ni atiende. Necesitan un RPO de horas o menos y un RTO lo más corto posible.
Importantes: su caída molesta y retrasa, pero se puede trabajar unas horas o un día con alternativas.
Diferibles: histórico, archivo o entornos de pruebas, que pueden esperar varios días sin daño serio.

Las dependencias que no aparecen en la copia

Un sistema restaurado no sirve si falta algo de lo que depende. Antes de fijar el RTO de una aplicación, anota qué necesita para funcionar.

El directorio de usuarios y las contraseñas con las que se inicia sesión.
La conexión a internet, la VPN (red privada virtual) o el acceso remoto de quien trabaja fuera.
Las licencias del software, que a veces están ligadas al equipo original.
Los certificados, los dominios y los registros DNS que apuntan al servicio.
Las integraciones con otros programas, con el banco o con la administración.

Cómo se traducen en una estrategia de copia

Con el RPO y el RTO de cada sistema ya se puede diseñar la estrategia. La base más extendida es la regla 3-2-1: tres copias de los datos, en dos soportes distintos y una de ellas fuera de la oficina. Hoy conviene añadir que al menos una copia sea inmutable o esté desconectada, para que un atacante no pueda borrarla.

Frecuencia: la marca el RPO de cada sistema, no un horario común para todo.
Retención: cuántos puntos de restauración se guardan y durante cuánto tiempo, pensando en errores que se descubren tarde.
Ubicación: copia local para restaurar rápido y copia externa para sobrevivir a un desastre en la oficina.
Método de recuperación: restaurar archivos, recuperar servidores completos o arrancar en la nube, según el RTO.
Servicios en la nube: Microsoft 365 y otras aplicaciones SaaS también necesitan su propio RPO y su propia copia.

En la práctica: bajar el RPO y el RTO siempre cuesta más. La decisión es de negocio: cuánto pagas por proteger frente a cuánto perderías sin esa protección.

Probar, no suponer

La continuidad se diseña para recuperar, y la única forma de saber si se cumple el RTO es medirlo. Una copia que termina en verde no demuestra que se pueda restaurar ni cuánto tarda. Las pruebas detectan dependencias que no aparecen en ningún informe de copia.

Qué pruebas hacer

Conviene combinar pruebas pequeñas y frecuentes con otras más completas, y repetirlas después de cualquier cambio importante en los sistemas.

Restaurar archivos y correos concretos, elegidos al azar.
Recuperar un servidor completo en un entorno aislado y comprobar que la aplicación arranca.
Simular un desastre y medir el tiempo real hasta que los usuarios vuelven a trabajar.
Dejar por escrito el procedimiento, lo que falló y lo que se corrigió.

Errores habituales

Casi todos salen a la luz el día del incidente, cuando ya no hay margen.

Un mismo objetivo para todo: se protege en exceso lo secundario y poco lo crítico.
Confundir réplica con copia: la réplica propaga los borrados y el cifrado.
Retención corta: cuando se detecta el problema, todos los puntos guardados ya están afectados.
Copias accesibles desde la red: el ransomware las cifra o las borra junto con el resto.
RTO sin hardware: los datos están a salvo, pero no hay dónde restaurarlos.
Procedimientos en la cabeza de una persona: si esa persona no está, nadie sabe por dónde empezar.