Casi todas las empresas hacen alguna copia de seguridad. Muchas menos saben cuánto trabajo perderían tras un fallo, cuánto tiempo estarían sin sistemas o si alguien ha restaurado alguna vez desde esas copias. El RPO y el RTO convierten esas dudas en decisiones que puede tomar la dirección.
Esta guía explica el RPO y el RTO en lenguaje llano, cómo fijarlos por proceso, la regla 3-2-1 y su variante 3-2-1-1-0. También trata las copias en la nube, el ransomware y las pruebas de restauración.
Qué son el RPO y el RTO, y en qué se diferencian
El RPO (objetivo de punto de recuperación) es la cantidad de datos que puede permitirse perder, medida en tiempo. Con un RPO de cuatro horas, sus copias nunca deben tener más de cuatro horas. El RTO (objetivo de tiempo de recuperación) es el tiempo que su empresa puede estar sin un sistema antes de que el daño sea inaceptable. Con un RTO de dos horas para el correo, debe funcionar de nuevo en ese plazo tras el fallo.
Para distinguirlos: el RPO mira hacia atrás, a la última copia válida; el RTO mira hacia delante, al momento en que se reanuda el trabajo.
Un ejemplo práctico (cifras ilustrativas)
Cifras inventadas para mostrar el cálculo; no son objetivos recomendados.
- Un sistema de pedidos tiene copia cada noche a las 22:00.
- El servidor falla a las 16:00 del día siguiente. La última copia tiene 18 horas, así que se pierde todo lo introducido desde las 22:00. El RPO efectivo llega a 24 horas: un fallo justo antes de la siguiente copia costaría un día completo.
- Restaurar el servidor y la aplicación y comprobar los datos lleva seis horas. El RTO conseguido es de seis horas, de 16:00 a 22:00.
- Si la empresa aceptara perder como máximo una hora de pedidos y esperar como máximo dos, la copia nocturna y la restauración de seis horas incumplen el objetivo. La diferencia indica qué cambiar: copias más frecuentes, recuperación más rápida, o ambas.
Los objetivos más exigentes cuestan más: fíjelos por sistema, no una sola vez para toda la empresa.
Ejemplo 2: objetivos distintos para sistemas distintos
Imagine una empresa ficticia de servicios profesionales que sigue la secuencia del apartado siguiente y acaba con cuatro niveles. Las cifras son inventadas y solo sirven para ilustrar la idea; no son objetivos recomendados.
| Sistema | RPO de ejemplo | RTO de ejemplo | Qué implica |
|---|---|---|---|
| Base de datos de facturación | 1 hora | 4 horas | Copias frecuentes de los datos y un procedimiento de restauración que alguien haya ensayado |
| Correo y calendarios | 4 horas | 4 horas | Una copia guardada aparte del propio servicio de correo, como se explica más abajo |
| Archivos compartidos de proyectos | 1 día | 1 jornada laboral | Basta una copia nocturna, siempre que la restauración quepa en la jornada |
| Archivo de proyectos cerrados | 1 semana | 1 semana | Una copia semanal en almacenamiento más lento, que solo se restaura cuando alguien pide un archivo antiguo |
Los objetivos difieren mucho, así que una política única para todo sobreprotegería el archivo o dejaría la facturación insuficientemente protegida. Y cada fila solo es fiable cuando se compara con un tiempo de restauración medido.
Ejemplo 3: la cadena de dependencias
En otro caso ficticio, la aplicación de contabilidad se restaura en una hora, una vez que su servidor está disponible. Pero necesita además el servicio de inicio de sesión, que tarda tres horas en reconstruirse, y la configuración de red de la oficina, que lleva dos horas y nunca se documentó.
- Si una sola persona lo hace todo en orden, el RTO conseguido ronda las seis horas: dos para la red, tres para el inicio de sesión y una para la aplicación.
- Si el inicio de sesión y la configuración de red no dependen entre sí y dos personas pueden trabajar en paralelo, la restauración de la aplicación puede empezar cuando está listo el requisito más lento, y el RTO ronda las cuatro horas.
- Si nadie puede reconstruir la configuración de red, el tiempo no es de cuatro ni de seis horas, sino desconocido, y eso es lo peor que puede descubrirse durante un fallo real.
Un «RTO de una hora» de la aplicación describe un eslabón, no la cadena. Dejar por escrito el orden de restauración y quién hace cada paso es un cambio pequeño que puede tener un efecto grande.
Cómo fijar el RPO y el RTO por proceso de negocio
Parta del negocio, no de la tecnología. Una secuencia práctica:
- Liste los procesos que importan: pedidos, facturación, nóminas, atención al cliente, correo, archivos compartidos.
- Asocie cada proceso a sus sistemas y datos: la aplicación, su base de datos, sus carpetas compartidas y las cuentas que necesita.
- Pregunte a cada responsable cuánto trabajo reciente podría rehacerse a mano y cuánto tiempo se puede operar sin el sistema antes de afectar a clientes, personal o contratos.
- Escriba las respuestas como RPO y RTO, en pocos niveles.
- Compárelas con lo que tiene hoy: frecuencia de copia, retención y duración real de una restauración.
Solo como ilustración, la facturación puede requerir un RPO y un RTO cortos y un archivo antiguo tolerar un día o más. Lo importante es que decidan quienes dirigen el proceso y que quede por escrito.
No olvide las dependencias: un sistema que se restaura en una hora sirve de poco si la red o el servicio de identidades de los que depende tardan un día. Su RTO real es el de toda la cadena.
La regla de copias de seguridad 3-2-1
La regla 3-2-1 es una pauta clásica para copias resistentes:
- 3 copias de sus datos: los datos en uso más al menos dos copias de seguridad.
- 2 tipos de soporte o almacenamiento distintos, para que un mismo fallo no afecte a ambos. Por ejemplo, un equipo local y almacenamiento en la nube.
- 1 copia fuera de las instalaciones, lejos del edificio y de la red principal, para que un incendio, un robo o una red de oficina comprometida no la alcancen.
Una segunda copia en el mismo servidor, o en la misma cuenta, protege de un archivo borrado, pero no de un disco averiado ni de un atacante con permisos de administrador.
Es una estructura mínima: no dice nada sobre frecuencia, retención ni si las copias se restauran bien. Combínela con objetivos de RPO y RTO y con pruebas periódicas.
3-2-1-1-0: la variante actual
El ransomware cambió lo que deben soportar las copias. Hoy los atacantes intentan borrar o cifrar primero las copias. La variante 3-2-1-1-0 añade dos puntos a la regla clásica:
- 1 copia inmutable o desconectada: una copia que no puede modificarse ni borrarse durante un periodo determinado, ni por un administrador, o desconectada de la red.
- 0 errores: las copias se verifican y las pruebas de restauración terminan sin errores. Una tarea «correcta» no demuestra que los datos sirvan.
La inmutabilidad puede venir de funciones de almacenamiento que bloquean los datos durante la retención, o de soportes extraíbles guardados fuera de línea.
Copias de seguridad en la nube: disponibilidad no es copia
Microsoft 365 y servicios similares están diseñados para mantenerse disponibles, y eso no equivale a tener una copia independiente y recuperable de su información. Según el modelo de responsabilidad compartida, el proveedor opera la plataforma y el cliente sigue siendo responsable de sus datos: quién puede borrarlos, cuánto se conservan y cómo se recuperan tras un error o un ataque.
La papelera y el historial de versiones ayudan ante borrados accidentales, pero sus plazos de retención son limitados y varían según el servicio y la licencia. Consulte la documentación vigente del proveedor. Rara vez cubren el borrado por un empleado que se marcha, cambios maliciosos sincronizados o una cuenta de administrador comprometida.
Por eso las copias de los datos en la nube deben tratarse al configurar el uso compartido, el almacenamiento y el gobierno. Si usa Microsoft 365, nuestra página de Cloud y Microsoft 365 explica cómo abordamos la puesta en marcha, y la guía de servicios cloud trata la cuestión más amplia de quién responde de qué. Para los ajustes de inicio de sesión y administración que pueden hacer menos probable tener que restaurar, vea nuestra lista de comprobación de seguridad de Microsoft 365.
Resistencia al ransomware: inmutabilidad y credenciales separadas
Una copia a la que el atacante puede llegar no es una red de seguridad. Tres hábitos marcan la diferencia:
- Credenciales separadas. La administración de las copias no debe usar las cuentas de la administración diaria ni del directorio principal. Si roban una cuenta de administrador de dominio, no debería poder borrar las copias.
- Inmutabilidad o almacenamiento desconectado. Al menos una copia debe resistir el borrado y el cifrado.
- Acceso limitado. Pocas personas deben poder cambiar la configuración, con autenticación multifactor y avisos si se acorta la retención o se desactivan tareas.
Las copias son solo una parte: la seguridad de las cuentas, las actualizaciones y la preparación ante incidentes reducen la probabilidad de tener que restaurar. Nuestros servicios de ciberseguridad revisan estos aspectos en conjunto. Si está comparando proveedores, nuestra guía para elegir servicios de ciberseguridad recoge preguntas que conviene hacer.
Una copia que no ha restaurado es una suposición
Los fallos de restauración suelen tener causas corrientes: una base de datos copiada en uso, una carpeta que falta en la tarea, una credencial caducada, una restauración que tarda tres días. Solo una prueba los revela.
- Pruebe con regularidad, según cambien sus sistemas, y al menos una vez al año la recuperación completa del más importante.
- Restaure en un entorno separado, sin sobrescribir datos reales.
- Cronometre. Compare la duración real con su RTO y la antigüedad de los datos restaurados con su RPO.
- Registre el resultado: qué se restauró, cuánto tardó y qué falló.
- Pruebe a las personas: quién decide, a quién se informa, dónde están las instrucciones.
Lista de comprobación para una prueba de restauración
Úsela como lista de trabajo en cada prueba. Parte de que ya tiene un RPO y un RTO para el sistema.
Antes de la prueba
- Elija un sistema y un escenario: una carpeta borrada, un servidor averiado, un buzón perdido o una cuenta bloqueada por un atacante.
- Anote los objetivos de ese sistema, para que el resultado tenga con qué compararse.
- Designe tres funciones: quién ejecuta la restauración, quién comprueba los datos y quién decide si la prueba se ha superado.
- Compruebe el acceso a las instrucciones y a las credenciales: dónde se guardan y si dependen del sistema que se va a restaurar, por ejemplo un gestor de contraseñas alojado en el servidor averiado.
Durante la prueba
- Ponga en marcha el cronómetro al declarar el fallo, no al empezar la restauración, y anote cada espera: buscar credenciales, descargar datos, pedir autorización.
- Restaure en un entorno separado, para que la prueba no pueda sobrescribir datos reales.
- Compruebe el resultado usándolo: abra archivos de muestra, ejecute un informe y verifique que un usuario puede iniciar sesión y ver datos actuales. Un registro sin errores no basta.
- Pruebe una restauración pequeña además de una grande. Un solo archivo o un correo suelto es a menudo la petición más frecuente.
Después de la prueba
- Compare el intervalo entre la última copia válida y el fallo con su RPO, y el tiempo transcurrido con su RTO.
- Registre cada carencia con un responsable y una fecha, corríjala y repita el mismo escenario si no se alcanzó algún objetivo.
- Programe la siguiente prueba y repítala tras cambios importantes, como una migración o un nuevo producto de copias de seguridad.
Si está preparando su adecuación a NIS2, la lista de comprobación de nuestra guía de NIS2 para pymes incluye una fila de copias y recuperación, y un registro breve de cada prueba, con las cifras medidas, es el tipo de evidencia que sugiere conservar. Es información general, no asesoramiento jurídico, y una prueba de restauración no demuestra por sí sola que se cumpla ninguna normativa.
Lista de comprobación breve
- Tenemos RPO y RTO por escrito para los procesos principales.
- Sabemos qué se copia y qué no.
- Tenemos tres copias, en dos tipos de almacenamiento, una fuera de las instalaciones.
- Al menos una copia es inmutable o está desconectada.
- Las cuentas de copia son distintas de las de administración diaria y usan autenticación multifactor.
- Microsoft 365 y otros datos en la nube tienen una copia que controlamos nosotros.
- Hemos restaurado un sistema real en el último año y registramos el resultado.
- El plan de recuperación está disponible fuera de línea, con datos de contacto. Nuestra guía del plan de recuperación ante desastres para pymes muestra qué puede incluir un plan de una página.
Qué puede revisar BlueNova IT con usted
BlueNova IT tiene su sede en Tallin, con soporte en español e inglés de lunes a viernes, de 09:00 a 18:00 CET. En un trabajo de ciberseguridad o de servicios IT gestionados, podemos repasar con usted:
- Qué se copia y si falta algún sistema, buzón o ubicación de archivos importante.
- Dónde están las copias y si cumplen la estructura 3-2-1.
- Quién puede borrarlas o modificarlas, y con qué cuentas.
- Si se han probado las restauraciones y cómo se comparan los resultados con su RPO y su RTO.
El resultado es una lista escrita y priorizada de carencias para que usted decida. El alcance se acuerda con cada organización; no prometemos tiempos de recuperación ni resultados. La revisión de copias también puede formar parte de nuestros servicios IT gestionados. Contáctenos para empezar.
Relacionado: Cloud y Microsoft 365, servicios de ciberseguridad, servicios IT gestionados, Cómo elegir servicios cloud: SaaS, PaaS e IaaS comparados, Gestión de infraestructura IT.
Fuentes
- NCSC (Reino Unido): Offline backups in an online world (en inglés): cómo mantener una copia de seguridad sin conexión o desconectada de los sistemas en producción, incluidas las copias alojadas en la nube pública
- CISA (EE. UU.): #StopRansomware Guide (en inglés): prácticas de prevención y lista de verificación de respuesta, incluidas las copias cifradas sin conexión y las pruebas de restauración
- Microsoft Learn: Resistencia de datos en Microsoft 365: cómo está diseñada la plataforma Microsoft 365 para la disponibilidad y la recuperabilidad
- Microsoft Learn: Responsabilidad compartida en la nube: qué tareas asume el proveedor de la nube y cuáles corresponden al cliente
