RPO y RTO explicados: cuántos datos puede perder y con qué rapidez debe volver a funcionar

Por Lucas Flores, IT Systeme Flores UG. Última actualización: 2026-10-21

¿Qué significan RPO y RTO?

NIST SP 800-34 Rev. 1, la guía de planificación de contingencias, define tres medidas relacionadas. El SNIA Dictionary formula las dos primeras con palabras algo distintas, con el mismo sentido. INCIBE usa nombres españoles para los mismos conceptos: «tiempo de recuperación» para el RTO, «tiempo máximo tolerable de caída» para el MTD y «grado de dependencia de la actualidad de los datos» para el RPO.

NIST señala además que, a diferencia del RTO, el RPO no forma parte del MTD: mide cuánta pérdida de datos tolera el proceso, no el tiempo que está parado. Ambas cifras salen de un análisis de impacto en el negocio (BIA, business impact analysis), que INCIBE también recomienda para identificar las necesidades de recuperación: usted pregunta al responsable de cada proceso cuánto cuesta una interrupción y fija los objetivos a partir de las respuestas.

Esquemático. Los tramos no están a escala.

¿Cómo fijan el RPO la frecuencia de las copias y su duración?

Una copia captura el estado de los datos hacia el momento en que se ejecuta. Si una ejecución empieza cada T horas y tarda d horas en terminar, un fallo que llegue justo antes de que termine la siguiente ejecución encuentra el punto de restauración completo más reciente con unas T + d horas de antigüedad. Esa es la pérdida de datos en el peor caso:

pérdida de datos en el peor caso = intervalo de copia + duración de una ejecución

Hay dos consecuencias fáciles de pasar por alto. Una copia nocturna no cumple un RPO de 24 horas, porque la propia ejecución lleva tiempo. Y una ejecución fallida añade un intervalo entero: si la ejecución anterior al fallo no se completó, el último punto de restauración bueno tiene dos intervalos de antigüedad. Un RPO solo lo cumple una programación con algo de margen, y que alguien reciba un aviso cuando falla una ejecución. INCIBE lo plantea igual: si se determina que el periodo máximo de pérdida de datos es de 8 horas, las copias deben hacerse a intervalos más cortos que ese periodo.

El RPO tampoco es lo mismo que la retención. El RPO se refiere al punto de restauración más reciente; la retención decide hasta dónde se puede volver atrás (véase la rotación abuelo-padre-hijo). NIST SP 800-34 dice que la política debe fijar la frecuencia mínima y el alcance de las copias según lo críticos que sean los datos y la frecuencia con que llega información nueva.

¿Qué fija el RTO?

El tiempo de recuperación es la suma de varios pasos, y solo uno de ellos es copiar datos:

1. Darse cuenta del fallo y decidir restaurar.
2. Preparar un destino: una máquina nueva, un buzón nuevo, acceso y credenciales.
3. Restaurar los datos, que lleva la cantidad de datos dividida por la velocidad que realmente se consigue.
4. Comprobar el resultado y devolverlo a los usuarios.

tiempo de restauración = tiempo fijo + datos que restaurar ÷ rendimiento de restauración

El rendimiento es donde importa la vía de restauración. Es el más lento de estos: el almacenamiento del que lee, la conexión entre ese almacenamiento y el destino, la velocidad de escritura del propio destino y los límites del servicio en el que restaura. La vía también decide cuánto tiene que restaurar: un buzón, una carpeta o una máquina entera, para la cual una copia a nivel de fichero exige instalar primero un sistema operativo. Las clases de almacenamiento también cuentan: las clases de archivo en la nube pueden tardar horas hasta que está disponible el primer byte, por ejemplo S3 Glacier Flexible Retrieval con tiempos de minutos a horas, y recuperaciones masivas de 5 a 12 horas según AWS, y una cinta hay que ir a buscarla y cargarla. Véase elegir almacenamiento para copias.

Un ejemplo de cálculo

Una empresa de 25 personas tiene correo y OneDrive de Microsoft 365 y un servidor de archivos de 800 GB. Los responsables fijan estos objetivos: el buzón de pedidos puede perder como mucho cuatro horas de correo y debe estar de vuelta en cuatro horas; el servidor de archivos puede perder un día y debe estar de vuelta en ocho horas. Todas las cifras siguientes son supuestos elegidos para mostrar el método.

• Correo, RPO de cuatro horas. Una copia cada 4 horas que dura 20 minutos da un peor caso de 4 h 20 min, que no cumple el objetivo. Cada 3 horas da 3 h 20 min, que sí lo cumple, con margen para una ejecución lenta.
• Servidor de archivos, RPO de 24 horas. Una copia nocturna que dura dos horas da un peor caso de 26 horas. Para cumplir 24 horas, el intervalo debe ser de 22 horas o menos, o la ejecución debe acelerarse.
• Servidor de archivos, RTO de ocho horas. Restaurar los 800 GB desde un almacenamiento en el mismo edificio a 100 MB/s lleva 2 h 13 min; con dos horas de tiempo fijo para darse cuenta, decidir y preparar un destino, el total es de unas 4 h 13 min, lo que cumple el objetivo. Si la única copia está en un bucket al que se llega por una línea de 25 MB/s, solo el paso de copia lleva 8 h 53 min y el total ronda las 10 h 53 min, lo que no lo cumple. Las opciones son una vía más rápida, una copia cerca del destino, restaurar primero las carpetas más importantes o un objetivo menos exigente.

El tiempo fijo es de 60 minutos para el correo y la máquina virtual y de 120 minutos para el servidor de archivos, y las duraciones de ejecución son 30, 20, 120, 120 y 10 minutos en el orden de las filas. Ninguna de estas cifras es la medición de un producto. Mida las suyas: restaure una cantidad conocida de datos en un destino de prueba y tome el tiempo.

Pruebe sus propias cifras

La calculadora de abajo usa las mismas dos fórmulas. Necesita JavaScript; sin él, la tabla de arriba lleva el cálculo. Nada de lo que escriba sale de su navegador.

¿Qué no dicen RPO y RTO?

• Son objetivos, no garantías. Una programación puede cumplir el RPO sobre el papel y aun así perder datos si hay ejecuciones que fallan sin que nadie se entere.
• Suponen que la copia es buena. Un punto de restauración que no se puede leer de vuelta no cumple ningún objetivo; ese es el «0» de la regla 3-2-1-1-0.
• Suponen que las personas y el acceso están ahí: las credenciales, las claves y la persona que conoce los pasos.
• El RPO se refiere solo al punto de restauración más reciente. No dice nada de hasta dónde se puede volver atrás, que es la retención.

Cómo lo resuelve Restow

Restow le da las palancas para el RPO y algunas de las vías para el RTO. No promete ninguna de las dos cifras y no tiene tiempos de restauración medidos que citar.

Programaciones, el lado del RPO

• Los trabajos de correo (Microsoft 365 e IMAP) se ejecutan según una programación que usted fija: cada 15 minutos o con menos frecuencia, hasta 31 días, o según una expresión cron. La primera fuente activa de un inquilino nuevo recibe un trabajo que copia cada 8 horas y ejecuta una comprobación de restauración cada domingo a las 03:00.
• Los trabajos de equipos para servidores y clientes se ejecutan cada pocos minutos u horas (el intervalo mínimo es de 5 minutos), a diario a una hora fija o cuando el equipo se conecta. El agente consulta a su instancia más o menos cada 5 minutos.
• Los trabajos de recursos compartidos de archivos se ejecutan según una programación que usted fija (a diario, cada N horas o según una expresión cron), como mucho cada hora, de modo que el intervalo mínimo para un recurso es de una hora.
• Los trabajos de Proxmox VE (una vista previa) admiten desde la 0.4.2 las cadencias de un trabajo de correo: cada pocas horas, a diario, en los días de la semana elegidos, cada mes o con una expresión cron, y no más a menudo que cada hora.
• Para servidores y equipos, las políticas de los agentes cambian lo que entrega la programación. Una política puede fijar una ventana de copia (Backup window; días de la semana y un intervalo horario) dentro de la cual pueden empezar las copias programadas, las recuperaciones de copias perdidas y los reintentos; una copia en curso continúa, y «Copiar ahora» (Back up now) ignora la ventana. Puede recuperar una copia perdida en la siguiente ventana, opcionalmente solo hasta una antigüedad máxima, y reintentar una fallida hasta diez veces. Una ventana puede por tanto alargar su RPO más allá del intervalo que escribió, y una recuperación o un reintento recupera parte de ese tiempo. La ventana, la recuperación de copias perdidas y los reintentos necesitan el agente 0.4.0, y sin política los agentes se comportan como antes.
• Una actualización de Restow también desplaza la siguiente ejecución. Desde que un administrador la confirma hasta que termina, no empieza ninguna ejecución nueva; el cuadro de diálogo cuenta lo que está en marcha y lo detiene de forma limpia (lo predeterminado), espera a que termine o no espera. Las programaciones que vencen se ejecutan después. El agente 0.4.0 mantiene sus propias programaciones en pausa durante ese tiempo; los agentes anteriores no. Desde la 0.4.2 una actualización también se puede planificar para una fecha y hora elegidas, y antes de la confirmación, que llega la cuenta atrás antes, no se pausa nada. Tras la actualización del servidor, las ejecuciones nuevas esperan además mientras los nodos de Proxmox VE y los agentes instalan la versión nueva, 15 minutos como máximo.
• Una copia que un administrador detiene desde la aplicación web (desde la 0.4.2) termina como cancelada y no cuenta como la última copia, así que el tiempo desde la última copia sigue creciendo hasta que la siguiente ejecución programada arranca con normalidad.
• Hasta que termina la primera copia de un objeto no hay ningún punto de restauración, así que no se puede recuperar nada. La primera copia de un inquilino grande de Microsoft 365 puede tardar días, porque Microsoft limita la velocidad de la API de Graph.
• Un aviso de copia atrasada (backup.overdue) le dice cuándo una copia va más tarde de lo que permite su programación, de modo que una ejecución fallida se note en lugar de duplicar en silencio su pérdida de datos.

Vías de restauración, el lado del RTO

• Correo, calendario, contactos y OneDrive: restaure un elemento, una carpeta o un buzón o un OneDrive completos, en la cuenta original o en otra, de forma no destructiva. Los usuarios pueden restaurar su propio buzón. También puede exportar el correo como EML en un ZIP o como MBOX; el enlace de descarga es válido durante 24 horas.
• Servidores y equipos: restaure en una carpeta nueva del equipo o descargue los ficheros como ZIP. Restaurar un equipo entero supone instalar primero el sistema operativo; la copia de imagen con restauración completa (bare metal) todavía no está disponible.
• Sitios de SharePoint: descargue bibliotecas, carpetas, archivos, listas y elementos como ZIP, devuelva archivos y carpetas a su biblioteca original o a otra biblioteca de un sitio copiado, y devuelva elementos de lista a su lista original como elementos nuevos.
• Recursos compartidos de archivos: desde un punto de restauración, descargue como ZIP, restaure en una carpeta nueva, en la ubicación original o en otro recurso que permita restauraciones. Véase recursos compartidos de archivos (SMB y NFS).
• Invitados de Proxmox VE (vista previa): restaure como un invitado nuevo con una VMID nueva. No hay restauración en vivo.
• Si se pierde el almacenamiento principal, un repositorio de copia puede promoverse a principal cuando se ha comprobado que está completo. Una copia cubre correo, calendario, contactos, OneDrive, sitios de SharePoint, IMAP y los datos de las VM de Proxmox VE, no servidores, equipos, recursos compartidos de archivos ni contenedores de Proxmox. Véase almacenamiento.
• Sin un servidor de Restow en marcha, una herramienta de restauración independiente lee el almacenamiento y la clave maestra.

Lo que no está medido

Restow muestra cuánto duró cada ejecución y representa su rendimiento en un gráfico, de modo que usted ve sus propias cifras. No publica velocidades de copia ni de restauración, y las comprobaciones de la versión no dan una cifra que podamos citar. La copia y la restauración de Microsoft 365 todavía no se han ejecutado contra un inquilino real de Microsoft 365 en las comprobaciones de la versión, así que los tiempos de restauración de Microsoft 365 no están medidos. La comprobación de restauración semanal demuestra que una muestra se lee de vuelta y coincide; no cronometra una restauración completa. Dos comprobaciones más recientes van más allá sin ser una restauración de prueba completa. Cada punto de restauración nuevo de un recurso compartido de archivos se comprueba releyendo hasta 20 archivos de muestra y comparándolos, y desde la 0.4.2 cada punto de restauración nuevo de un invitado de Proxmox VE se relee en minutos (una muestra de sus bloques). Una prueba de arranque (Boot test) de Proxmox VE (una vista previa, desactivada por defecto) restaura un punto de restauración como un invitado temporal y aislado, lo arranca, espera a su agente de invitado y lo destruye de nuevo; eso demuestra que el punto de restauración arranca, pero no que las aplicaciones de dentro funcionen. Una restauración de prueba completa en un destino aparte sigue prevista. Hasta entonces, cronometre usted una restauración real. Véanse copia de seguridad de Microsoft 365 e IMAP, restauración y verificación.

Preguntas frecuentes

Fuentes

Consultado el 21 de octubre de 2026.

1. INCIBE: Copias de seguridad: una guía de aproximación para el empresario (2018). RTO, MTD y RPO con sus nombres en español, el análisis de impacto en el negocio y que las copias deben hacerse a intervalos más cortos que el RPO (apartado 5.5)
2. NIST SP 800-34 Rev. 1: Contingency Planning Guide for Federal Information Systems (mayo de 2010, en inglés). El apartado 3.2.1 define MTD, RTO y RPO; el apartado 3.4.2 vincula la frecuencia de las copias con la criticidad de los datos
3. Glosario del NIST (en inglés): recovery point objective. El punto en el tiempo hasta el que deben recuperarse los datos tras una interrupción
4. Glosario del NIST (en inglés): recovery time objective. Cuánto tiempo pueden estar en la fase de recuperación los componentes de un sistema antes de que el daño sea inaceptable
5. SNIA Dictionary (generado el 28 de abril de 2026, en inglés): Recovery Point Objective, Recovery Time Objective. Las definiciones del sector del almacenamiento, incluido que cero es un RPO válido
6. Amazon S3: Clases de almacenamiento de Amazon S3. Las clases de archivo como S3 Glacier Flexible Retrieval se recuperan en minutos u horas

Artículos relacionados

• La regla 3-2-1 de copias de seguridad Tres copias, dos tipos de almacenamiento, una copia en otro lugar, y la ampliación con una copia inmutable y cero errores. Con un ejemplo de Microsoft 365.
• Completa, incremental, diferencial y completa sintética Una tabla comparativa de espacio, duración, esfuerzo de restauración y riesgo de la cadena, además de incremental permanente, seguimiento de bloques modificados y deduplicación.
• Elegir almacenamiento para copias Disco local, NAS y NFS, almacenamiento de objetos compatible con S3, cinta y niveles de archivo en la nube, comparados en coste, durabilidad, inmutabilidad y velocidad de restauración.
• Rotación abuelo-padre-hijo (GFS) Puntos de restauración diarios, semanales, mensuales y anuales con un ejemplo de calendario, en qué se distingue de conservar todas las copias N días y cómo pasa de la cinta al disco y al almacenamiento de objetos.
• Glosario de copias de seguridad referencia Definiciones breves de términos de copia, restauración, retención, almacenamiento y RGPD, de la regla 3-2-1 a WORM, con enlaces a los artículos y páginas de funciones que profundizan.