Plan De Disaster Recovery: RTO, RPO y Cómo Montarlo
Casi todas las empresas tienen copias de seguridad. Muy pocas tienen un plan de disaster recovery. La diferencia entre las dos cosas se descubre siempre en el peor momento: el día que el servidor no arranca y alguien pregunta cuánto vamos a tardar en volver, y la respuesta honesta es «no lo sabemos».
Este artículo explica cómo se construye un plan de recuperación que responda a esa pregunta con una cifra, y no con una esperanza.
Backup, disaster recovery y continuidad: no son lo mismo
Se usan como sinónimos y no lo son:
| Concepto | Qué responde | Alcance |
| Copia de seguridad | ¿Tengo los datos guardados? | Los datos |
| Disaster recovery | ¿En cuánto tiempo vuelven a funcionar los sistemas? | La infraestructura de TI |
| Continuidad de negocio | ¿Cómo sigue operando la empresa mientras tanto? | Toda la organización |
Un backup es una condición necesaria y claramente insuficiente. Tener la copia y no tener dónde restaurarla, ni el orden en que hay que hacerlo, ni las credenciales a mano, ni las licencias, es tener los datos y no tener el servicio.
El disaster recovery es justamente el plan que convierte una copia en un sistema funcionando.
RTO y RPO: las dos cifras que lo definen todo
Todo el plan se construye sobre dos números, y merece la pena entenderlos bien porque se confunden constantemente.
- RTO (Recovery Time Objective). Cuánto tiempo puede estar caído el servicio. Se mide en horas. Responde a «¿cuándo tenemos que estar de vuelta?».
- RPO (Recovery Point Objective). Cuánta información puedes permitirte perder, medida en tiempo. Responde a «¿hasta qué momento hacia atrás podemos volver?».
Un ejemplo que lo aclara todo: si haces copia una vez al día a las 22:00 y el servidor muere a las 19:00, has perdido el trabajo de todo el día. Tu RPO real es de 24 horas, digas lo que digas en el papel.
| Sistema | RTO típico | RPO típico |
| ERP y facturación | 4 – 8 h | 1 h |
| Correo electrónico | 4 h | 15 min |
| Servidor de ficheros | 8 – 24 h | 4 h |
| Web corporativa | 24 h | 24 h |
| Puestos de usuario | 24 – 48 h | 24 h |
Estas cifras no las decide el departamento de informática: las decide la dirección, porque son una decisión de negocio con coste asociado. Bajar el RTO de 24 horas a 1 hora puede multiplicar la inversión por cinco. La pregunta correcta es cuánto cuesta cada hora de parada comparado con cuánto cuesta evitarla.
El análisis de impacto: por dónde se empieza
Antes de elegir tecnología hay que saber qué proteger y en qué orden. Ese ejercicio es el análisis de impacto en el negocio:
- Inventaría los servicios, no los servidores. «Facturación» es un servicio; puede depender de tres máquinas, una base de datos y una conexión con el banco.
- Estima el coste de la parada de cada uno: por hora y por día. En euros y también en incumplimientos legales o contractuales.
- Ordénalos por criticidad. Casi siempre hay tres o cuatro servicios que son la empresa y quince que pueden esperar.
- Mapea las dependencias. El ERP no arranca si antes no está el directorio; el directorio no arranca sin DNS. El orden de recuperación es media batalla.
- Asigna RTO y RPO a cada servicio con la dirección delante.
Las cuatro estrategias de disaster recovery
Cuanto más bajo el RTO, más caro. Estas son las opciones, de menos a más:
| Estrategia | RTO orientativo | Cómo funciona | Coste |
| Copia y restauración | Días | Restaurar sobre hardware nuevo | Bajo |
| Pilot light | Horas | Núcleo mínimo replicado y apagado | Medio-bajo |
| Warm standby | Minutos-horas | Entorno reducido encendido y sincronizado | Medio-alto |
| Activo-activo | Casi cero | Dos entornos operativos simultáneos | Alto |
Para la mayoría de pymes, el punto de equilibrio está en el pilot light: una réplica en la nube o en una segunda ubicación con los servicios críticos preparados y apagados, que se levantan cuando hacen falta. Se paga poco por tenerlo parado y se recupera en horas en lugar de en días.
La regla 3-2-1 y el matiz del ransomware
La base de cualquier plan de disaster recovery sigue siendo la regla clásica: 3 copias, en 2 soportes distintos, con 1 fuera de las instalaciones.
Con el ransomware ha aparecido un matiz que ha dejado obsoletas muchas configuraciones: el atacante moderno busca y borra las copias antes de cifrar. Si el repositorio de backup está en el dominio, accesible con credenciales de administrador, no es una copia: es un objetivo.
De ahí que la regla se haya extendido con dos condiciones más:
- Una copia inmutable, que no se puede modificar ni borrar durante un periodo fijado ni siquiera con credenciales de administrador.
- Una copia aislada de las credenciales del dominio, en otro plano de autenticación.
Y una comprobación incómoda que conviene hacer hoy: si un atacante consiguiera la contraseña del administrador del dominio, ¿podría borrar vuestras copias? Si la respuesta es sí, no tenéis plan de recuperación frente a ransomware.
El runbook: el documento que se usa a las tres de la mañana
Un plan que solo existe en la cabeza de una persona no es un plan. El runbook es el documento operativo, y debe contener:
- Criterios de activación. Quién decide que esto es un desastre y no una incidencia.
- Teléfonos y responsables, incluidos los del proveedor y los del fabricante. En papel, no solo en el correo corporativo que quizá esté caído.
- Orden de recuperación de los servicios, con sus dependencias.
- Procedimientos paso a paso para cada sistema, con capturas si hace falta.
- Ubicación de credenciales y claves de cifrado, protegidas pero accesibles al equipo autorizado. Guardar la única copia de las contraseñas en el gestor que está en el servidor caído es un error clásico.
- Licencias y contratos de soporte.
- Comunicación: qué se dice a clientes, empleados y —si aplica— a la autoridad de protección de datos.
Ese documento tiene que estar fuera de la infraestructura que puede caer. Impreso, en una nube independiente o en las dos.
Probarlo: la parte que casi nadie hace
Un plan de recuperación no probado es una hipótesis. Las pruebas, de menor a mayor exigencia:
- Restauración de ficheros sueltos, mensual. Cinco minutos y detecta el 80 % de los problemas de copia.
- Restauración completa de un servidor en un entorno aislado, semestral. Es donde aparecen las sorpresas: la copia que no incluía el estado del sistema, el driver que falta, la licencia que no activa.
- Simulacro de conmutación, anual. Levantar los servicios críticos en el entorno secundario y cronometrarlo. Ese cronómetro es tu RTO real.
Después de cada prueba se actualiza el runbook. Sin excepción.
Preguntas frecuentes
¿Cada cuánto se revisa el plan de disaster recovery?
Como mínimo una vez al año, y siempre que haya un cambio relevante: un servidor nuevo, una migración a la nube, un cambio de ERP o de sede. Un plan que describe una infraestructura que ya no existe es peor que no tener plan, porque da falsa seguridad.
¿Sirve la nube como plan de recuperación?
Muy bien, y es lo que ha puesto el disaster recovery al alcance de las pymes: pagas por el almacenamiento mientras está parado y solo por la computación cuando lo levantas. Lo que no debes asumir es que por estar en la nube ya estás protegido: los proveedores garantizan su infraestructura, no tus datos ni tus errores.
¿Cuánto cuesta montar un plan?
El análisis y la documentación son horas de consultoría. La tecnología depende del RTO que hayáis fijado. Por eso el orden correcto es primero decidir RTO y RPO con la dirección, y luego cotizar; al revés se compra tecnología que no encaja con lo que el negocio necesita.
¿Y si somos una empresa pequeña?
Con más razón: una pyme sin plan que sufre un ransomware tarda semanas en volver, y muchas no vuelven. Un plan proporcionado —copias inmutables, réplica en la nube y un runbook de diez páginas— es asumible y cambia por completo el resultado.
En resumen
Un plan de disaster recovery empieza por dos números acordados con la dirección, RTO y RPO, y termina en un runbook probado. En medio: análisis de impacto, elección de estrategia, copias inmutables fuera del alcance del dominio y simulacros cronometrados.
Si hoy no sabes cuánto tardarías en levantar tu ERP desde cero, ese es exactamente el motivo para empezar. Y la buena noticia es que la primera versión útil del plan se saca en unas pocas sesiones de trabajo.Enlaces internos sugeridos: «Copia De Seguridad En La Nube: Guía Para Empresas», «Cómo Protegerse Correctamente de Ransomware», «ICS enumera las