Qué vas a conseguir
Una prueba de recuperación que demuestra algo: que los servicios que soportan las funciones críticas arrancan en el centro alternativo dentro del tiempo comprometido, con los datos que se esperaba, y que el negocio puede operar con ellos. Y un informe que lo cuenta con números, con lo que falló y con quién lo arregla y cuándo. En servicios financieros esa prueba no es opcional ni se hace "cuando haya tiempo": forma parte del programa de resiliencia que revisarán auditoría y, si llega el caso, el supervisor.
Antes de empezar
- El análisis de impacto (BIA) con las funciones críticas o importantes y sus objetivos de RTO y RPO, aprobados por el negocio.
- El plan de recuperación de cada servicio en alcance, actualizado: si el último cambio de arquitectura no está en el plan, la prueba probará un plan que ya no existe.
- La réplica al centro alternativo funcionando y vigilada (almacenamiento, bases de datos, copias), con su retraso medido.
- Contactos y compromisos de los proveedores que intervienen: operadoras, proveedores de datos de mercado, plataformas externas de contratación.
1. Alcance y escenario
Una prueba sin alcance claro acaba siendo una demostración de lo que ya funciona. Escribe en una página:
- Escenario: por ejemplo, "pérdida total del centro de datos principal un viernes a las 22:00". Un escenario concreto obliga a decidir qué cae y qué no.
- Servicios en alcance: plataforma de órdenes, conectividad con mercados y contrapartes, datos de mercado, base de datos de operaciones, directorio y DNS que necesitan todos los demás.
- Fuera de alcance, por escrito: lo que no se prueba esta vez y por qué. Lo que nunca se prueba es lo que fallará el día real.
- Objetivos:
| Servicio | RTO objetivo | RPO objetivo | Dependencias |
|---|---|---|---|
| Plataforma de órdenes | 2 h | 5 min | Base de datos de operaciones, DNS, conectividad con mercados |
| Datos de mercado | 1 h | No aplica | Circuitos del proveedor en el centro alternativo |
| Base de datos de operaciones | 1 h 30 min | 5 min | Réplica síncrona o asíncrona |
| Directorio y DNS | 30 min | 15 min | Controladores de dominio en el centro alternativo |
2. Lo que espera la regulación
En la Unión Europea, el Reglamento DORA (Reglamento (UE) 2022/2554, aplicable desde enero de 2025) pide a las entidades financieras, entre otras cosas:
- Un programa de pruebas de resiliencia operativa digital, con pruebas al menos anuales de los sistemas que soportan funciones críticas o importantes.
- Planes de continuidad y de respuesta y recuperación de las TIC probados de forma periódica, también con escenarios de caída de proveedores.
- Resultados documentados, deficiencias identificadas y su corrección con seguimiento.
- Para algunas entidades, además, pruebas de penetración basadas en amenazas (TLPT) cada cierto tiempo.
Qué aplica exactamente a tu entidad lo determinan las áreas de riesgos y cumplimiento. Para IT, lo práctico es que la prueba deje evidencia: plan, horas, resultados, aceptación y acciones, todo fechado y localizable.
3. Roles y go/no-go
| Rol | Qué hace |
|---|---|
| Director de la prueba | Decide el go/no-go, la vuelta atrás y el cierre |
| Coordinador de IT | Lleva el cronograma y el registro de incidencias en tiempo real |
| Técnicos por servicio | Ejecutan los pasos del plan y anotan las horas reales |
| Probadores del negocio | Validan con operaciones de prueba que el servicio sirve para trabajar |
| Observador de riesgos o auditoría | Comprueba que se sigue el plan y que hay evidencia |
| Comunicación | Avisa a la dirección, a proveedores y, si aplica, al resto de la sede |
Un no-go no es un fracaso: es exactamente para lo que sirve la lista. Si una condición falla, se aplaza o se reduce el alcance, y se registra.
4. El calendario del fin de semana
| Momento | Paso |
|---|---|
| Viernes 18:00 | Congelación de cambios y cierre de la actividad del día |
| Viernes 21:30 | Go/no-go |
| Viernes 22:00 | T0: inicio del escenario (aislamiento del centro principal) |
| Viernes 22:00–00:30 | Arranque de directorio, DNS, bases de datos y aplicaciones en el centro alternativo |
| Sábado 08:00–12:00 | Pruebas del negocio con operaciones de prueba en entornos de mercado de pruebas |
| Sábado 13:00 | Aceptación del negocio y decisión de vuelta |
| Sábado 14:00–20:00 | Vuelta al centro principal y resincronización |
| Domingo | Verificación completa y prueba de humo de lunes |
| Lunes 07:00 | Equipo de guardia en la sede antes de la apertura |
La vuelta es parte de la prueba. Muchas pruebas salen bien hasta el regreso y el lunes la sede abre con una réplica a medias.
5. Medir RTO y RPO de verdad
- RTO: desde T0 hasta que el negocio confirma que el servicio sirve, no hasta que el servidor arranca. Cada técnico anota la hora real de cada paso en el registro; el coordinador las consolida.
- RPO: compara la última operación registrada en el centro principal antes de T0 con la última disponible en el centro alternativo.
sqlcmd -S srv-oms-sql01 -d oms -E -Q "SELECT MAX(exec_time) AS ultima FROM dbo.executions"ultima-----------------------2026-11-13 21:59:47.310 (1 rows affected)sqlcmd -S srv-oms-dr01 -d oms -E -Q "SELECT MAX(exec_time) AS ultima FROM dbo.executions"ultima-----------------------2026-11-13 21:58:12.904 (1 rows affected)La primera consulta se lanza justo antes de T0 y se guarda; la segunda, en el centro alternativo tras el arranque. Aquí la diferencia es de 1 min 35 s, dentro del objetivo de 5 min. Si no hubiera operaciones en ese intervalo, el RPO no se puede medir con esta tabla: genera operaciones de prueba antes de T0.
6. El ticket: "la plataforma arranca en DR pero los traders no ven precios"
Sábado, 08:40. La plataforma de órdenes está arriba en el centro alternativo y el negocio entra, pero las pantallas de precios están vacías.
- La plataforma está conectada a su base de datos y responde: el problema está en la entrada de datos de mercado.
- El proveedor confirma que su feed está activo, pero que solo acepta conexiones desde las IP del centro principal. El cambio de IP del centro alternativo nunca se le pidió.
- Durante la prueba: el proveedor da de alta la IP por su línea de guardia (por eso se le avisó antes) y a las 09:25 hay precios. En el informe, datos de mercado figura con la hora real en que hubo precios y como fuera de objetivo, no como "en objetivo, con un incidente".
- En el registro: incidencia, causa (dependencia de proveedor no documentada en el plan), impacto en el RTO y acción con dueño y fecha: que la IP del centro alternativo quede autorizada de forma permanente y se pruebe cada trimestre.
7. Aceptación, informe y remediación
- Aceptación del negocio: cada probador firma qué ha probado y con qué resultado. Sin esa firma, el servicio no se da por recuperado.
- El informe, en pocos días: alcance, escenario, horas reales, RTO y RPO medidos contra objetivo, incidencias, desviaciones del plan, aceptación y acciones.
- Las acciones van a la herramienta de seguimiento con dueño y fecha, y se revisan en el comité correspondiente hasta cerrarse. La siguiente prueba empieza comprobando que las de la anterior están hechas.
- Actualiza los planes con lo aprendido: un paso que nadie supo hacer es un paso mal escrito.
Siguientes pasos
- La guía de Backup y DR/BCP del Nivel 4 cubre el diseño de copias, réplicas y planes de recuperación.
- La guía de ISO 27001/NIS2/RGPD en IT sitúa la continuidad dentro del marco de cumplimiento.
- La de Veeam Backup cubre la restauración de máquinas y la verificación de copias.
- La de PostgreSQL/MySQL/SQL Server ayuda con la réplica y la comprobación de las bases de datos.
¿Falta algo o en tu entorno es distinto? Escríbeme y lo corrijo.
What you'll get
A recovery test that proves something: that the services supporting critical functions start at the alternate site within the committed time, with the data expected, and that the business can operate with them. And a report that tells it with numbers, with what failed and who fixes it by when. In financial services that test is neither optional nor done "when there's time": it is part of the resilience programme that audit will review and, if it comes to it, the supervisor.
Before you start
- The business impact analysis (BIA) with the critical or important functions and their RTO and RPO targets, approved by the business.
- The recovery plan for each in-scope service, up to date: if the last architecture change isn't in the plan, the test will test a plan that no longer exists.
- Replication to the alternate site working and monitored (storage, databases, backups), with its lag measured.
- Contacts and commitments of the providers involved: carriers, market data vendors, external trading platforms.
1. Scope and scenario
A test without a clear scope ends up as a demonstration of what already works. Write on one page:
- Scenario: for example, "total loss of the primary data centre on a Friday at 22:00". A concrete scenario forces you to decide what goes down and what doesn't.
- Services in scope: order platform, connectivity to markets and counterparties, market data, trades database, the directory and DNS everything else needs.
- Out of scope, in writing: what isn't tested this time and why. What is never tested is what will fail on the real day.
- Targets:
| Service | Target RTO | Target RPO | Dependencies |
|---|---|---|---|
| Order platform | 2 h | 5 min | Trades database, DNS, market connectivity |
| Market data | 1 h | Not applicable | Vendor circuits at the alternate site |
| Trades database | 1 h 30 min | 5 min | Synchronous or asynchronous replica |
| Directory and DNS | 30 min | 15 min | Domain controllers at the alternate site |
2. What regulation expects
In the European Union, the DORA Regulation (Regulation (EU) 2022/2554, applicable since January 2025) asks financial entities, among other things, for:
- A digital operational resilience testing programme, with at least yearly tests of the systems that support critical or important functions.
- ICT business continuity and response and recovery plans tested periodically, including scenarios where providers fail.
- Documented results, identified deficiencies and their remediation with follow-up.
- For some entities, threat-led penetration testing (TLPT) at set intervals as well.
Exactly what applies to your entity is determined by the risk and compliance functions. For IT, the practical point is that the test leaves evidence: plan, times, results, sign-off and actions, all dated and easy to find.
3. Roles and go/no-go
| Role | What they do |
|---|---|
| Test director | Decides the go/no-go, the rollback and the close |
| IT coordinator | Runs the timeline and the issues log in real time |
| Service technicians | Carry out the plan's steps and log the actual times |
| Business testers | Validate with test trades that the service is fit to work with |
| Risk or audit observer | Checks that the plan is followed and evidence exists |
| Communications | Informs management, providers and, where relevant, the rest of the site |
A no-go is not a failure: it's exactly what the checklist is for. If a condition fails, the test is postponed or its scope reduced, and that is recorded.
4. The weekend timeline
| When | Step |
|---|---|
| Friday 18:00 | Change freeze and close of the day's activity |
| Friday 21:30 | Go/no-go |
| Friday 22:00 | T0: scenario starts (primary site isolated) |
| Friday 22:00–00:30 | Directory, DNS, databases and applications brought up at the alternate site |
| Saturday 08:00–12:00 | Business tests with test trades in market test environments |
| Saturday 13:00 | Business sign-off and fail-back decision |
| Saturday 14:00–20:00 | Fail-back to the primary site and resynchronisation |
| Sunday | Full verification and Monday smoke test |
| Monday 07:00 | On-call team on site before the open |
Fail-back is part of the test. Many tests go well until the return, and on Monday the site opens with a half-synchronised replica.
5. Measuring RTO and RPO properly
- RTO: from T0 until the business confirms the service is usable, not until the server boots. Each technician logs the real time of each step; the coordinator consolidates them.
- RPO: compare the last trade recorded at the primary site before T0 with the last one available at the alternate site.
sqlcmd -S srv-oms-sql01 -d oms -E -Q "SELECT MAX(exec_time) AS last_trade FROM dbo.executions"last_trade-----------------------2026-11-13 21:59:47.310 (1 rows affected)sqlcmd -S srv-oms-dr01 -d oms -E -Q "SELECT MAX(exec_time) AS last_trade FROM dbo.executions"last_trade-----------------------2026-11-13 21:58:12.904 (1 rows affected)The first query runs just before T0 and is saved; the second at the alternate site after start-up. Here the difference is 1 min 35 s, within the 5 min target. If there were no trades in that interval, RPO can't be measured with this table: generate test trades before T0.
6. The ticket: "the platform starts in DR but traders see no prices"
Saturday, 08:40. The order platform is up at the alternate site and the business can log in, but the price screens are empty.
- The platform is connected to its database and responds: the problem is the market data input.
- The vendor confirms their feed is live, but it only accepts connections from the primary site's IPs. The alternate site's IP change was never requested.
- During the test: the vendor adds the IP through their on-call line (which is why they were told beforehand) and at 09:25 there are prices. In the report, market data appears with the real time prices arrived and as missing its target, not as "on target, with an incident".
- In the log: the issue, its cause (a vendor dependency not documented in the plan), the impact on RTO and an action with owner and date: the alternate site's IP permanently allowed and tested every quarter.
7. Sign-off, report and remediation
- Business sign-off: each tester signs what they tested and the result. Without that signature, the service is not considered recovered.
- The report, within a few days: scope, scenario, actual times, RTO and RPO measured against target, issues, deviations from the plan, sign-off and actions.
- Actions go into the tracking tool with an owner and a date, and are reviewed at the relevant committee until closed. The next test starts by checking that the previous one's actions are done.
- Update the plans with what you learned: a step nobody knew how to do is a badly written step.
Next steps
- The Level 4 Backup and DR/BCP guide covers the design of backups, replicas and recovery plans.
- The ISO 27001/NIS2/RGPD in IT guide places continuity within the compliance framework.
- The Veeam Backup guide covers restoring machines and verifying backups.
- The PostgreSQL/MySQL/SQL Server guide helps with replicating and checking the databases.
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 →