RTO y RPO se derivan de un análisis de impacto en el negocio (BIA), no de lo que la tecnología actual permite: primero se decide qué puede permitirse perder cada proceso y luego se dimensiona la arquitectura. Un ERP puede tolerar 24 horas; la pasarela de pagos, minutos.
¿Qué es el disaster recovery?
El disaster recovery (DR) o recuperación ante desastres es la capacidad —planificada, documentada y probada— de restaurar los sistemas, datos y servicios TIC críticos de una organización tras un incidente grave, dentro de dos objetivos pactados con el negocio: el RTO (Recovery Time Objective, cuánto tiempo puede estar caído un servicio) y el RPO (Recovery Point Objective, cuántos datos se pueden perder). El desastre ya casi nunca es un incendio: hoy el escenario dominante es el ransomware que cifra producción y copias a la vez, seguido de borrados maliciosos, fallos de proveedor cloud y errores humanos. El DR es la parte tecnológica de la continuidad de negocio: esta decide qué procesos deben sobrevivir; el DR se ocupa de levantar la tecnología que los sostiene.
¿Por qué importa?
Porque la pregunta ya no es si perderás sistemas, sino cuánto tardas en recuperarlos y cuánto dato pierdes por el camino. Un RTO y un RPO son decisiones de negocio con precio: pasar de recuperar en 24 horas a recuperar en 1 hora puede multiplicar el coste de la arquitectura, y asumir un RPO de un día significa aceptar perder la facturación de ese día. Sin esas cifras acordadas, IT improvisa durante la crisis y el comité de dirección descubre en el peor momento que "el backup" tarda dos semanas en restaurarse. Los atacantes lo saben: los operadores de ransomware buscan y destruyen las copias de seguridad antes de cifrar, por lo que sin backup inmutable o aislado el plan entero se sostiene sobre nada. Además es exigencia regulatoria directa: DORA obliga a las entidades financieras a mantener políticas de backup y métodos de restauración verificados y a probarlos periódicamente; NIS2 (art. 21) exige gestión de copias, recuperación y continuidad a los sectores esenciales; e ISO 22301 e ISO/IEC 27031 son los marcos de referencia para demostrarlo.
Puntos clave
DR no es sinónimo de continuidad de negocio: la continuidad cubre personas, procesos, proveedores y comunicación de crisis; el DR es su capítulo tecnológico. Puede haber continuidad sin tecnología (procedimientos en papel) y DR inútil sin continuidad que lo dirija.
La regla 3-2-1-1-0 como base: tres copias, en dos soportes, una fuera del entorno, una inmutable u offline (air gap), y cero errores verificados de restauración. La copia inmutable —object lock S3, cabinas WORM, vault desconectado— es lo que sobrevive cuando el atacante tiene privilegios de administrador de dominio. Ver backup inmutable.
Estrategias por coste y velocidad: backup & restore (horas o días), pilot light y warm standby (minutos u horas, réplica mínima lista para escalar), activo-activo multi-sitio (RTO cercano a cero, coste máximo) y DRaaS cuando se delega la infraestructura de recuperación en un tercero.
El plan es un runbook, no un PDF: orden de arranque por dependencias (primero identidad y red, luego datos, luego aplicaciones), responsables nombrados con suplentes, credenciales de emergencia accesibles fuera del dominio y criterios claros de activación y de vuelta atrás.
Sin prueba no hay plan: tabletop para el comité, restauraciones parciales mensuales, failover completo al menos anual con tiempos cronometrados. La métrica que importa no es cuántos backups terminan bien, sino cuánto se tardó en restaurar de verdad la última vez.
Ejemplo: ransomware un viernes por la noche, dos finales distintos
Una industria de 400 empleados sufre un ransomware que cifra la plataforma de virtualización completa. Los operadores, con credenciales de administrador robadas semanas antes, han borrado primero el repositorio de backups en disco, que estaba unido al mismo dominio. Resultado sin DR real: no hay copia utilizable, la fábrica para 18 días, se negocia el rescate y la restauración es artesanal.
La misma empresa con un plan de DR maduro vive otro final. La copia inmutable en un vault con object lock no puede borrarse ni con privilegios de dominio. El runbook establece el orden: restaurar el directorio activo en red limpia y aislada, verificar con el equipo de respuesta a incidentes que las copias del punto elegido no contienen la puerta trasera, levantar las 12 aplicaciones críticas identificadas en el BIA y dejar el resto para después. RTO comprometido: 24 horas para lo crítico; RPO: 4 horas por la replicación al vault. El lunes la fábrica arranca, y la diferencia entre ambos finales no fue el antivirus: fue una copia que el atacante no pudo tocar y un procedimiento ensayado dos veces al año.
Errores habituales
- Confundir tener backups con tener DR: una copia sin orden de arranque, sin dependencias mapeadas y sin responsables es un fichero, no un plan. La restauración de un entorno completo sin runbook se improvisa en semanas.
- Dejar que IT fije RTO y RPO sin el negocio: o se promete un 'cero pérdida' imposible de pagar, o se asume un día de pérdida de datos que dirección nunca aceptó conscientemente.
- Backups alcanzables desde el dominio comprometido: repositorios unidos a Active Directory, credenciales de backup en el mismo gestor que cifra el atacante, sin inmutabilidad ni air gap. Es el primer objetivo de todo operador de ransomware.
- Probar solo restauraciones de ficheros sueltos y nunca un failover completo: el día del desastre aparecen las sorpresas (licencias, DNS, certificados caducados, orden de arranque) que una prueba anual habría destapado.
- Olvidar el SaaS y la identidad: Microsoft 365, el CRM o Entra ID no los respalda 'el proveedor' más allá de retenciones básicas. Sin copia propia de buzones, SharePoint y configuración de identidad, el plan cubre solo la mitad del negocio.
Términos relacionados
Servicios relacionados
Este concepto puede tener relación con servicios como:
Preguntas frecuentes
¿Qué diferencia hay entre disaster recovery y continuidad de negocio? ¿Necesito los dos planes?
Sí, y conviene no fusionarlos. El plan de continuidad de negocio responde a "¿cómo sigue operando la empresa?" e incluye personas, procesos manuales alternativos, proveedores y comunicación de crisis; el plan de DR responde a "¿cómo recupero la tecnología?" con runbooks, RTO/RPO y arquitectura de respaldo. La continuidad decide, por ejemplo, que facturación debe funcionar en 4 horas aunque sea en modo degradado; el DR define cómo se restaura el ERP para conseguirlo. Un DR sin continuidad recupera servidores que quizá nadie necesita primero; una continuidad sin DR es un documento sin músculo técnico.
Dirijo una pyme y hacemos copia de seguridad diaria, ¿no es eso ya un plan de DR?
Es la materia prima, no el plan. Las preguntas que convierten un backup en DR son: ¿la copia sobrevive si roban credenciales de administrador (inmutabilidad, air gap)? ¿Cuánto se tarda en restaurar el servidor completo, no un fichero, y cuándo se probó por última vez? ¿En qué orden arrancan los sistemas y quién lo ejecuta si el responsable está de vacaciones? ¿Dónde están las credenciales de emergencia si el gestor de contraseñas también está cifrado? Un backup inmutable, un runbook de una decena de páginas y una prueba de restauración semestral ponen a una pyme por delante de la mayoría de su sector sin gran inversión.
¿Cada cuánto y cómo debería probar mi plan de recuperación?
Con tres niveles de exigencia. Continuo y automatizado: verificación de integridad de cada copia y restauraciones de muestra que confirmen que el dato es legible (el 0 de la regla 3-2-1-1-0). Trimestral o semestral: restauración completa de un sistema crítico en entorno aislado, cronometrada y comparada con el RTO comprometido. Anual: ejercicio de failover del conjunto crítico con el equipo real, incluyendo un escenario de ransomware en el que el dominio se considera hostil y no se puede usar. Cada prueba termina con informe de desviaciones y acciones; si el RTO real duplica al prometido, o se invierte en arquitectura o se renegocia el objetivo con dirección.
Soy CISO de una entidad financiera sujeta a DORA, ¿qué me exige exactamente en recuperación?
DORA dedica a esto parte del pilar de gestión de riesgos TIC: políticas y procedimientos de backup, métodos de restauración y recuperación documentados, sistemas redundantes para funciones críticas, y verificación periódica de que todo ello funciona —no basta declarar el plan, hay que evidenciar las pruebas—. Los RTO/RPO deben estar definidos por función crítica y alineados con el análisis de impacto, y los acuerdos con proveedores TIC (incluido tu proveedor de DRaaS o cloud) deben contemplar la recuperación. NIS2 impone obligaciones equivalentes, algo menos prescriptivas, a los sectores esenciales e importantes. Un gap assessment frente a DORA suele empezar precisamente por backup, restauración y pruebas.