DR/BCP: RPO y RTO por servicio, el plan de recuperación y una prueba completa

Qué vas a conseguir

Pasar de "tenemos copias" a "sabemos cuánto tardamos en volver y lo hemos medido". Cada servicio con su RPO y RTO acordados con negocio, copias que un ransomware no puede borrar, un plan de recuperación que otra persona puede seguir a las tres de la mañana, y una prueba anual que demuestra que todo eso funciona.

Antes de empezar

• La lista de servicios y sus dependencias (CMDB, inventario o la hoja que haya). El repo 32 del portfolio, Backup Restore Test Tracker, sirve de plantilla para llevar servicios, RPO y pruebas.
• Un responsable de negocio por servicio que pueda decidir cuánto puede estar parado.
• La herramienta de copias con trabajos funcionando (guía de Veeam del Nivel 2) y un segundo emplazamiento o región de nube.
• Dos palabras claras: RPO es cuánto dato puedes perder (la antigüedad de la última copia buena) y RTO es cuánto puedes tardar en volver a dar servicio.

1. El análisis de impacto (BIA) en una tabla

Una reunión por área con una pregunta: "si este servicio cae a las 10:00 de un lunes, ¿a partir de qué hora es un problema serio, y cuánto trabajo perdido aceptas rehacer?". De ahí sale la tabla, no de IT.

• El nivel decide el orden de recuperación y el presupuesto: un RPO de 15 minutos exige replicación o logs de base de datos, no una copia nocturna.
• Microsoft 365 no es "sin copia": Microsoft garantiza el servicio, no que recuperes lo que un usuario o un atacante borró hace cuatro meses. Una copia propia (por ejemplo Veeam Backup for Microsoft 365) cubre ese hueco.

2. La regla 3-2-1-1-0

• 3 copias de los datos (la producción y dos más).
• 2 soportes distintos (disco y objeto, o disco y cinta).
• 1 fuera del emplazamiento.
• 1 inmutable o desconectada: ni un administrador comprometido puede borrarla antes de que caduque.
• 0 errores en la verificación: una copia que nunca se ha restaurado es una hipótesis.

›Get-VBRBackupSession | Where-Object { $_.EndTime -gt (Get-Date).AddDays(-1) } | Sort-Object JobName | Format-Table JobName, Result, EndTimeJobName              Result    EndTime-------              ------    -------BK-ERP-SQL           Success   27/10/2026 02:14:51BK-FS01              Warning   27/10/2026 03:40:09BK-Tier1-AD          Success   27/10/2026 01:05:33

Cada aviso (Warning) tiene una causa y un dueño antes del mediodía: un archivo bloqueado hoy es una restauración incompleta mañana.

3. El plan de recuperación (runbook)

El plan vive fuera de la infraestructura que protege: impreso, en el gestor de documentos de otro proveedor o en el repositorio, no solo en el SharePoint que puede estar caído.

• El orden sale de las dependencias, no del nivel: el ERP es nivel 1, pero sin AD y DNS no arranca.
• Cada paso tiene una comprobación que demuestra que ha funcionado, y la hora a la que se marcó.
• Los teléfonos de los proveedores y los contratos con sus números de cliente van dentro del plan.

4. La prueba

Hay tres tipos y se hacen los tres: de mesa (se lee el plan en voz alta con un escenario y aparecen los huecos), parcial (se restaura un servicio en una red aislada) y completa (se recupera la sede entera en el sitio secundario, sin tocar producción).

En la prueba completa se cronometra cada paso del runbook:

El ERP se pasó de su RTO por algo que ninguna copia arregla: la licencia. Para eso se hacen las pruebas.

5. El informe y las acciones

• Alcance, escenario, hora de inicio y de fin, quién participó.
• La tabla de tiempos medidos contra los objetivos, servicio a servicio.
• Cada desviación con una acción, un dueño y una fecha (en el ejemplo: pedir al fabricante una licencia para el sitio secundario y añadirla al runbook).
• Qué cambia en el plan. La versión nueva del runbook se publica el mismo mes.
• Se presenta a dirección: el BCP es una decisión de negocio, IT aporta los números.

6. Lo que revisas cada mes y cada año

• Cada mes: trabajos con aviso o error, resultado del SureBackup, que la copia inmutable sigue siéndolo (fecha de bloqueo del último punto).
• Cada vez que entra un servicio nuevo: su fila en la tabla del BIA y su paso en el runbook. Sin eso, no entra en producción.
• Cada año: la prueba completa y la revisión del BIA con negocio (los RPO y RTO cambian cuando cambia el negocio).

Siguientes pasos

• Azure Site Recovery para usar una región de Azure como sitio secundario y pagar el cómputo solo cuando se usa.
• Un plan específico de ransomware: aislar, decidir desde qué punto restaurar (el último limpio, no el último) y comprobar con antivirus el punto antes de devolverlo a producción.
• ISO 22301 si la empresa necesita certificar su continuidad de negocio.
• La alerta de Sentinel que avisa cuando alguien intenta borrar copias o cambiar la inmutabilidad (guía de Microsoft Sentinel).

¿Falta algo o en tu entorno es distinto? Escríbeme y lo corrijo.