La recuperación depende de personas, sistemas, datos y servicios compartidos. Un plan resulta útil cuando esas dependencias se conocen y se ejercitan en condiciones relevantes.
Recuperar significa que el negocio puede trabajar
Cuando me dicen que una restauración ha terminado correctamente, quiero saber qué hemos recuperado. Puede ser un archivo, una máquina o una base de datos. El resultado que necesita el negocio normalmente es una actividad que vuelve a funcionar con datos utilizables y acceso para las personas adecuadas.
Empezaría por describir esa actividad y acordar cómo comprobaremos su recuperación. En una aplicación de pedidos, por ejemplo, puede ser necesario consultar registros, crear una operación y completar sus integraciones. El responsable del servicio debe validar qué recorrido representa su necesidad. Si el criterio de éxito es únicamente que la máquina arranca, podríamos terminar el ejercicio sin probar la función que justificaba la prioridad de recuperación.
Priorizar desde el negocio
Determinar qué servicios deben recuperarse primero y qué interrupción resulta tolerable. Validar las prioridades con los responsables del servicio.
Objetivos que podamos relacionar con el servicio
El tiempo objetivo de recuperación, RTO, indica el plazo de restauración que se pretende alcanzar. El punto objetivo de recuperación, RPO, expresa hasta dónde podemos perder datos en términos de tiempo. Ambos deben responder a las necesidades del servicio y contrastarse con las capacidades reales.
No asumiría que una copia cada cierto intervalo garantiza por sí sola el RPO. Hay que comprobar disponibilidad, integridad y restauración de los datos que necesitamos. Tampoco confundiría tiempo de restauración de una máquina con recuperación del proceso completo. Si los objetivos no pueden cumplirse con la arquitectura actual, debe quedar registrado y decidirse qué capacidad falta o qué compromiso necesita revisar el negocio. Esa conversación es mejor antes de una incidencia.
Restaurar componentes para recuperar el servicio
- Identidad y accesosLas personas y servicios pueden autenticarse.
- DNS y conectividadLas dependencias se localizan y comunican.
- Datos y clavesLa información se restaura y puede utilizarse.
- Aplicación e integracionesEl recorrido de negocio funciona.
El orden de recuperación depende de las relaciones reales entre componentes; no todas las tareas pueden ejecutarse en paralelo.
Mapear dependencias
Incluir identidad, DNS, conectividad, claves, proveedores y personal. Documentar el orden de recuperación y los accesos necesarios.
El orden importa tanto como las copias
Mapearía dependencias técnicas y operativas: identidad, DNS, red, certificados, claves, licencias, proveedores y personal. Algunas pueden recuperarse en paralelo; otras necesitan un orden. Una aplicación puede depender de una base de datos que a su vez requiere claves custodiadas en otro servicio.
También revisaría cómo se accede a la documentación y a las herramientas de recuperación durante el fallo. Si el procedimiento está en el mismo entorno indisponible, necesitamos una alternativa protegida. Los accesos de emergencia deben poder utilizarse sin reproducir la dependencia que intentamos resolver. No basta con que exista una cuenta: hay que saber quién puede recuperarla, desde dónde y qué registro quedará de su utilización. Esa secuencia debe ensayarse, no descubrirse durante la crisis.
Ejemplo: restaurar una aplicación crítica
Una base de datos se restaura correctamente, pero los usuarios no pueden acceder porque la identidad y el DNS siguen indisponibles. La prueba ha demostrado una restauración técnica, no la recuperación del servicio. Un ejercicio útil define qué recorrido de usuario debe funcionar, qué dependencias lo hacen posible y qué evidencia confirma que el negocio puede operar.
Restaurar en un escenario de compromiso
Una interrupción técnica y un compromiso de seguridad no requieren necesariamente la misma respuesta. Si recuperamos un sistema comprometido sin entender qué debemos limpiar o sustituir, podemos reintroducir el problema. El procedimiento necesita coordinación entre recuperación y respuesta al incidente.
Revisaría el entorno donde restauramos, las credenciales necesarias y la evidencia disponible sobre los datos. La comprobación debe incluir integridad y funcionalidad, además de tiempos. Cuando no podemos confirmar algún aspecto, debe quedar visible para quienes deciden cómo reanudar la actividad. También debemos contemplar proveedores y servicios externos: conocer sus compromisos no significa que hayamos probado nuestras integraciones ni la disponibilidad de las personas que deben intervenir en una recuperación conjunta.
Las personas y las decisiones también son dependencias
Un procedimiento puede estar técnicamente bien diseñado y requerir decisiones que nadie sabe quién debe tomar. ¿Quién declara que empezamos la recuperación? ¿Quién prioriza si dos servicios compiten por los mismos recursos? ¿Quién valida que el negocio puede volver a operar? Esas responsabilidades necesitan estar acordadas.
También hay que prever cómo se coordinan los equipos si los canales habituales no están disponibles. Las listas de contacto, las rutas de escalado y el acceso a proveedores deben poder utilizarse en las condiciones del ejercicio. Si solo funciona cuando está presente una persona concreta, tenemos una dependencia que debe reconocerse.
En una prueba incluiría cambios de turno y entrega de información entre responsables. El equipo que recibe el servicio necesita saber qué se ha restaurado, con qué datos y qué limitaciones permanecen. Una recuperación parcial puede permitir alguna actividad y mantener otra bloqueada; esa diferencia debe comunicarse de forma clara.
También prepararía la vuelta al funcionamiento habitual. Recuperar en un entorno alternativo introduce cambios que debemos mantener, revisar o deshacer después. El procedimiento necesita explicar quién controla ese estado y cómo evita que queden accesos temporales o configuraciones de emergencia indefinidamente. La recuperación termina cuando el servicio y su operación quedan en un estado conocido, con las decisiones pendientes identificadas.
Obtener evidencia
Probar restauración y recuperación de servicios, no solo la existencia de copias. Comparar resultados con objetivos y asignar responsables a las brechas.
Cerrar el ciclo de mejora
Cada ejercicio debe terminar con hallazgos asignados y una decisión sobre cuándo volver a comprobarlos. También importa reconocer qué no se probó: un entorno de laboratorio o un volumen reducido de datos puede no representar los tiempos reales. Documentar esos límites evita presentar una evidencia parcial como garantía de recuperación.
Un ejercicio termina cuando cerramos sus hallazgos
Diseñaría pruebas con un alcance explícito, criterios de éxito y responsables. Podemos empezar con ejercicios parciales, pero debemos explicar qué demuestran y qué dejan pendiente. Una restauración con pocos datos o en un entorno distinto puede revelar problemas sin representar los tiempos de producción.
Al terminar, registraría resultado, dependencias inesperadas y tareas de mejora. Cada tarea necesita responsable, prioridad y comprobación posterior. Si volvemos a encontrar el mismo problema y nunca corregimos su causa, estamos repitiendo ejercicios sin mejorar la capacidad. Mediría recuperación de recorridos de negocio, desviación frente a objetivos y cierre verificado de hallazgos. La arquitectura también cambia: una nueva integración o un cambio de identidad puede dejar obsoleto un procedimiento que funcionó en la última prueba.
Referencias para profundizar
Fuentes oficiales para contrastar y ampliar estos conceptos. Este artículo presenta un enfoque práctico; no reproduce los requisitos completos de las referencias.
Los ejemplos son ilustrativos. Las decisiones de implementación deben adaptarse a los requisitos y dependencias de cada organización.