5.2Plan de copia y recuperación ante desastres
Lo esencial en 30 segundos
- Hacer copias no basta: el DRP describe cómo reanudar tras un desastre; el BCP, cómo mantener la actividad durante el incidente.
- RTO = tiempo máximo de recuperación; RPO = pérdida de datos tolerable — estas dos referencias dimensionan el plan y justifican el presupuesto.
- Un plan no probado no es un plan: los simulacros de restauración y una documentación al día hacen que la recuperación sea real, no teórica.
Mini-caso hilado — Sofiane esboza el DRP de las nóminas
Sofiane, técnico de soporte en una pyme de distribución en Argel, constata que la empresa tiene copias de seguridad pero ningún plan de recuperación. Esboza un DRP mínimo para el servicio de nóminas, crítico a fin de mes. Razona por principios: este servicio tolera muy poca pérdida de datos, por lo que copias frecuentes y un tiempo de recuperación corto — sin fijar una duración numérica, retiene sobre todo que estos objetivos se deciden con la dirección según las restricciones del negocio. Enumera lo que hay que restaurar y en qué orden, anota quién hace qué, y luego programa un simulacro de restauración. Transforma «tenemos copias» en «sabemos reanudar».
Caso autónomo de esta sección: reaparece en el curso, el esquema, el script y el reto de 48 h de la sección 5.2.
1. De la copia al plan
Hacer copias es necesario pero insuficiente. Un plan de recuperación ante desastres (DRP) describe cómo reanudar tras un desastre (fallo grave, incendio, ransomware): qué restaurar, en qué orden, por quién y con qué recursos. El plan de continuidad del negocio (BCP) busca, en cambio, mantener la actividad durante el incidente. Sofiane retiene la frase simple: se pasa de «tenemos copias» a «sabemos reanudar».
2. RTO y RPO, las dos referencias
Dos objetivos estructuran el plan. El RTO (Recovery Time Objective): ¿en cuánto tiempo hay que estar de nuevo operativo? El RPO (Recovery Point Objective): ¿qué cantidad de datos podemos aceptar perder? Un RPO ajustado impone copias muy frecuentes; un RTO ajustado impone un procedimiento rápido y recursos listos. Estas referencias dictan la inversión — Sofiane las hace validar con la dirección, servicio por servicio, sin imponer un valor prefabricado.
3. Un plan no probado no es un plan
Como con las copias, un DRP se prueba: simulacros de restauración, simulaciones de desastre, actualización de la documentación. Un plan escrito una vez y luego olvidado falla el día clave (contactos caducados, procedimiento incompleto, recursos no disponibles). Sofiane programa por tanto simulacros regulares para que el plan siga siendo real, no teórico.
🔎 Ejemplo concreto — 🔎 Ejemplo concreto — Razonar RTO y RPO para las nóminas
Sofiane razona por principios sobre un servicio crítico, sin imponer un valor numérico prefabricado:
RPO ajustado → copias más frecuentes (menos datos perdidos)
RTO ajustado → procedimiento rápido + recursos listos (recuperación más veloz)
→ estas referencias se deciden con la dirección, servicio por servicioLectura: el RPO guía la frecuencia de las copias; el RTO guía la rapidez de la recuperación.
Lección: sin referencias definidas con el negocio, es imposible dimensionar (ni justificar) el plan.
Vocabulario de la sección
- DRP
- Plan de recuperación ante desastres: cómo reanudar tras un desastre.
Ejemplo sencillo: Sofiane esboza el DRP del servicio de nóminas.
Lo que no es: creer que las copias bastan.
Reflejo: DRP = cómo reanudar.
- BCP
- Plan de continuidad del negocio: mantener la actividad durante el incidente.
Ejemplo sencillo: Sofiane prevé cómo funcionan las nóminas en modo degradado.
Lo que no es: confundir continuidad (BCP) y recuperación (DRP).
Reflejo: BCP = seguir durante.
- RTO
- Duración máxima aceptable para estar de nuevo operativo.
Ejemplo sencillo: Sofiane lo fija con la dirección para cada servicio.
Lo que no es: un plazo elegido sin relación con el negocio.
Reflejo: RTO = tiempo de recuperación.
- RPO
- Cantidad máxima de datos que se acepta perder.
Ejemplo sencillo: Un RPO ajustado empuja a copias frecuentes.
Lo que no es: olvidarlo y descubrir la pérdida el día clave.
Reflejo: RPO = pérdida de datos tolerable.
- Simulacro de recuperación
- Prueba real que verifica que el plan funciona.
Ejemplo sencillo: Sofiane programa un simulacro de restauración de las nóminas.
Lo que no es: un DRP escrito y nunca probado.
Reflejo: probar el plan con regularidad.
En la práctica — En la práctica — Esbozar un DRP mínimo
- Elige un servicio crítico (como las nóminas en el caso de Sofiane) y determina con el negocio sus referencias: tiempo de recuperación (RTO) y pérdida de datos tolerable (RPO).
- Enumera qué hay que restaurar y en qué orden para volver a ponerlo en marcha (primero las dependencias).
- Anota quién hace qué y qué recursos son necesarios durante la recuperación.
- Programa un simulacro de restauración para validar el plan sobre el terreno.
Script paso a paso — esbozar tu plan como Sofiane (8 min)
1) Nombra un servicio crítico y fija con el negocio sus referencias RTO y RPO. 2) Enumera los elementos que hay que restaurar y su orden, respetando las dependencias. 3) Escribe quién hace qué y los recursos necesarios. 4) Fija una fecha para un primer simulacro de restauración. 5) Anota dónde se almacenan las copias y cómo acceder a ellas sin el sistema principal. 6) Relee el plan como si tuviera que usarlo una persona ausente.
Un plan útil cabe en una página por servicio: claro, ordenado y, sobre todo, probado con regularidad.
Plantilla copiar-pegar — mi ficha de DRP (un servicio)
Servicio: ___ (p. ej. nóminas de la pyme de Sofiane)
Referencias: RTO = ___ (tiempo de recuperación) · RPO = ___ (pérdida tolerada)
A restaurar (en orden): ___
Quién hace qué: ___
Recursos: ___
Fecha del último simulacro: ___
Regla: un plan no probado no es un plan.Un plan para las nóminas
Sofiane apunta primero al servicio de nóminas, crítico a fin de mes, con referencias ajustadas.
Un plan para los archivos
Sofiane cubre el recurso compartido de documentos de los comerciales, útil a diario.
Mantener durante (BCP)
Sofiane prevé un modo degradado para que la distribución continúe durante el incidente.
Probar, probar aún
Sofiane programa simulacros de restauración regulares en lugar de un plan escrito una sola vez.
✓ Buenas prácticas
- Definir RTO y RPO con el negocio, servicio por servicio, no en abstracto.
- Ordenar las restauraciones según las dependencias (lo esencial primero).
- Probar el plan con simulacros regulares: si no, no existe.
✗ Errores frecuentes
- Confundir «tener copias» y «saber reanudar».
- Escribir un DRP y luego no probarlo nunca.
- Olvidar las dependencias y restaurar en desorden.
Puntos clave
- El DRP describe cómo reanudar; el BCP, cómo continuar durante el incidente.
- RTO = tiempo de recuperación; RPO = pérdida de datos tolerable.
- Estas referencias dictan la frecuencia de las copias y la inversión.
- Un plan no probado falla: simulacros regulares obligatorios.
Reto 48 h — aplícalo mañana
Como Sofiane, esboza el DRP de UN servicio crítico: anota sus referencias RTO y RPO con el negocio, la lista ordenada de lo que hay que restaurar, quién hace qué, y luego fija una fecha para un primer simulacro de restauración. Escribe en una frase qué ganaría la pyme sabiendo reanudar.
- Distingo copia de seguridad, DRP y BCP.
- Sé leer RTO (tiempo de recuperación) y RPO (pérdida tolerable).
- Sé por qué un plan debe probarse con regularidad.
Preguntas frecuentes
¿Qué diferencia hay entre DRP y BCP?
El BCP busca mantener la actividad durante el incidente (soluciones de respaldo, modo degradado); el DRP busca reconstruir y reanudar después. Ambos se complementan: continuar en la medida de lo posible y luego restaurar por completo.
¿Cómo justificar el presupuesto de un DRP ante la dirección?
Cuantificando el coste de una interrupción (horas perdidas, datos, reputación) frente al coste del plan, y traduciendo las necesidades en RTO y RPO. Estas referencias hacen concreta la inversión en lugar de teórica — sin imponer valores prefabricados.
¿Qué mide el RPO de un plan de recuperación ante desastres?