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.
| Servicio | Si cae | RPO | RTO | Nivel |
|---|---|---|---|---|
| ERP (pedidos y facturación) | No se factura ni se envía | 15 min | 4 h | 1 |
| Active Directory y DNS | No entra nadie a nada | 1 h | 2 h | 1 |
| Servidor de ficheros (unidad S:) | Se trabaja con copias locales | 24 h | 8 h | 2 |
| Intranet | Molestia, hay alternativas | 24 h | 48 h | 3 |
| Correo (Microsoft 365) | SaaS: depende de Microsoft | 24 h (copia propia) | — | 1 |
- 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:33Cada 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:
| Paso | RTO objetivo | Medido | Nota |
|---|---|---|---|
| AD y DNS en línea | 2 h | 1 h 10 min | — |
| ERP dando servicio | 4 h | 5 h 25 min | La licencia del ERP estaba ligada a la MAC del servidor original |
| Unidad S: accesible | 8 h | 3 h 05 min | — |
| Último dato del ERP (RPO) | 15 min | 12 min | — |
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.
What you'll get
Moving from "we have backups" to "we know how long it takes us to come back, and we have measured it". Every service with an RPO and RTO agreed with the business, backups ransomware can't delete, a recovery plan someone else can follow at three in the morning, and a yearly test that proves all of it works.
Before you start
- The list of services and their dependencies (CMDB, inventory or whatever spreadsheet exists). Repo 32 in the portfolio, *Backup Restore Test Tracker*, works as a template to track services, RPOs and tests.
- One business owner per service who can decide how long it may be down.
- The backup tool with working jobs (Level 2 Veeam guide) and a second site or cloud region.
- Two clear words: RPO is how much data you can lose (the age of the last good backup) and RTO is how long you can take to restore service.
1. The impact analysis (BIA) in one table
One meeting per area with one question: "if this service goes down at 10:00 on a Monday, from what time is it a serious problem, and how much lost work will you accept redoing?". The table comes from there, not from IT.
| Service | If it goes down | RPO | RTO | Tier |
|---|---|---|---|---|
| ERP (orders and invoicing) | No invoicing, no shipping | 15 min | 4 h | 1 |
| Active Directory and DNS | Nobody can get into anything | 1 h | 2 h | 1 |
| File server (S: drive) | People work from local copies | 24 h | 8 h | 2 |
| Intranet | Annoying, there are alternatives | 24 h | 48 h | 3 |
| Email (Microsoft 365) | SaaS: depends on Microsoft | 24 h (own backup) | — | 1 |
- The tier decides the recovery order and the budget: a 15-minute RPO needs replication or database logs, not a nightly backup.
- Microsoft 365 is not "no backup needed": Microsoft guarantees the service, not that you recover what a user or an attacker deleted four months ago. Your own backup (for example Veeam Backup for Microsoft 365) covers that gap.
2. The 3-2-1-1-0 rule
- 3 copies of the data (production plus two).
- 2 different media (disk and object, or disk and tape).
- 1 off site.
- 1 immutable or offline: not even a compromised administrator can delete it before it expires.
- 0 errors in verification: a backup that has never been restored is a hypothesis.
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:33Every *Warning* has a cause and an owner before midday: a locked file today is an incomplete restore tomorrow.
3. The recovery plan (runbook)
The plan lives outside the infrastructure it protects: printed, in another provider's document store or in the repository, not only in the SharePoint that may be down.
- The order comes from dependencies, not from the tier: the ERP is tier 1, but without AD and DNS it won't start.
- Every step has a check that proves it worked, and the time it was ticked.
- The providers' phone numbers and the contracts with their customer numbers go inside the plan.
4. The test
There are three kinds and you do all three: tabletop (the plan is read aloud against a scenario and the gaps appear), partial (one service is restored into an isolated network) and full (the whole site is recovered at the secondary site, without touching production).
In the full test each runbook step is timed:
| Step | Target RTO | Measured | Note |
|---|---|---|---|
| AD and DNS online | 2 h | 1 h 10 min | — |
| ERP serving | 4 h | 5 h 25 min | The ERP licence was tied to the original server's MAC address |
| S: drive reachable | 8 h | 3 h 05 min | — |
| Latest ERP data (RPO) | 15 min | 12 min | — |
The ERP missed its RTO because of something no backup fixes: the licence. That is what tests are for.
5. The report and the actions
- Scope, scenario, start and end time, who took part.
- The table of measured times against the targets, service by service.
- Every deviation with an action, an owner and a date (in the example: ask the vendor for a licence for the secondary site and add it to the runbook).
- What changes in the plan. The new runbook version is published the same month.
- It goes to management: the BCP is a business decision, IT brings the numbers.
6. What you review every month and every year
- Every month: jobs with warnings or errors, the SureBackup result, that the immutable copy still is (the lock date of the latest point).
- Whenever a new service arrives: its row in the BIA table and its step in the runbook. Without them, it doesn't go into production.
- Every year: the full test and the BIA review with the business (RPOs and RTOs change when the business changes).
Next steps
- Azure Site Recovery to use an Azure region as the secondary site and pay for compute only when you use it.
- A ransomware-specific plan: isolate, decide which point to restore from (the last clean one, not the last one) and scan that point before it goes back to production.
- ISO 22301 if the company needs to certify its business continuity.
- The Sentinel alert that fires when someone tries to delete backups or change immutability (Microsoft Sentinel guide).
Is something missing, or different in your environment? Get in touch and I'll fix it.
Tech Career Lab · newsletter
¿Te ha servido? Cada dos semanas envío una idea práctica para perfiles IT: LinkedIn, proyectos, networking y procesos de selección.Found this useful? Every two weeks I send one practical idea for IT professionals: LinkedIn, projects, networking and hiring processes.
Apúntate y llévate las 33 ideasSign up and get the 33 ideas →