¿Qué es un plan de recuperación ante desastres?
Un plan de recuperación ante desastres es un conjunto documentado de procedimientos para restablecer los servicios tecnológicos tras una interrupción importante. Abarca infraestructura, aplicaciones, datos, redes, sistemas de identidad, sistemas de backup, ubicaciones de recuperación, responsabilidades técnicas y el retorno a la operativa normal.
El NIST define un plan de recuperación ante desastres como un plan formal por escrito para recuperar sistemas de información en una instalación alternativa tras un fallo grave de hardware, fallo de software o destrucción de instalaciones. Los planes modernos también contemplan la recuperación en infraestructuras en la nube, un segundo centro de datos, hardware de sustitución o una plataforma local reconstruida.
El documento debe ser lo suficientemente específico como para que otra persona cualificada pueda seguirlo cuando el administrador habitual, el edificio, la red o el sistema de gestión no estén disponibles.
Recuperación ante desastres frente a backup
Una empresa puede disponer de copias de seguridad completas y aun así carecer de infraestructura de sustitución, credenciales de recuperación, configuración de red, información sobre dependencias, prioridades de recuperación o autoridad para tomar decisiones. Las copias de seguridad son un elemento esencial de la recuperación ante desastres, pero son solo una parte del plan.
Recuperación ante desastres frente a continuidad del negocio
La recuperación ante desastres se centra principalmente en restaurar la tecnología. La continuidad del negocio se orienta a mantener operativas las funciones esenciales de la organización durante una interrupción mediante procedimientos alternativos manuales, espacios de trabajo alternativos, personal de guardia, acuerdos con proveedores y comunicación con clientes. El plan de recuperación ante desastres debe respaldar el plan de continuidad global.
Comenzar con un análisis de impacto en el negocio
Un plan de recuperación ante desastres no debe tratar todos los sistemas con la misma urgencia. Un análisis de impacto en el negocio (BIA) identifica las funciones empresariales esenciales, los sistemas que las sustentan, el impacto de las caídas y la pérdida de datos, las dependencias, los tiempos de recuperación aceptables y el personal y proveedores necesarios.
Las directrices del NIST sitúan el análisis de impacto en el negocio en las etapas iniciales de la planificación de contingencias, ya que ayuda a determinar los requisitos de los sistemas, las prioridades y las estrategias de recuperación.
Para cada carga de trabajo, pregúntate: ¿qué proceso se detiene si este sistema falla? ¿En qué momento la interrupción se vuelve grave? ¿Qué otros servicios dependen de él? ¿Qué funcionalidad mínima debe restablecerse primero?
¿Qué incidentes debe cubrir el plan?
Un plan eficaz se diseña tanto en función de las capacidades perdidas como de desastres concretos con nombre propio. En lugar de redactar un plan independiente para cada eventualidad imaginable, crea procedimientos de recuperación para capacidades que puedan desaparecer: computación de producción no disponible, almacenamiento principal inaccesible, credenciales habituales no confiables, backups locales inutilizables o sede principal inaccesible.
El intervalo máximo aceptable entre el último punto de recuperación utilizable y la interrupción, expresado como pérdida de datos admisible en el tiempo.
El tiempo máximo aceptable entre la interrupción y el restablecimiento de un servicio utilizable, expresado como tiempo de inactividad admisible.
AWS recomienda definir el RPO y el RTO para cada carga de trabajo en función del impacto empresarial y el riesgo, seleccionando después una estrategia de recuperación capaz de alcanzar esos objetivos.
Niveles de recuperación y dependencias
Los niveles de recuperación simplifican la planificación agrupando sistemas con requisitos similares.
Los niveles de recuperación deben reflejar tanto las dependencias como la importancia empresarial. Un servidor DNS o de identidad con poca visibilidad puede necesitar recuperarse antes que una aplicación de cara al público.
Mapear las dependencias del servicio
Las aplicaciones rara vez funcionan de forma aislada. Crea un mapa de dependencias para cada servicio crítico que contemple identidad, DNS, enrutamiento de red, almacenamiento, bases de datos, secretos, certificados y API externas. Si la base de datos se recupera antes que el DNS y la identidad, el servicio seguirá sin estar disponible. La secuencia de recuperación debe respetar estas relaciones.
Roles, autoridad y criterios de activación
El plan debe definir roles en lugar de depender únicamente de personas concretas.
Cada rol debe contar con un contacto principal, un sustituto, atribuciones claras, accesos requeridos y una ruta de escalado. No des por hecho que el administrador habitual del sistema estará siempre localizable.
Definir los criterios de activación
Especifica cuándo la gestión ordinaria de un incidente pasa a considerarse recuperación ante desastres: cuando la interrupción prevista supera el RTO aprobado, cuando la infraestructura de producción no se puede restaurar con normalidad, cuando la sede principal no está disponible o cuando un ataque de ransomware afecta a producción. Define asimismo quién tiene autoridad para activar el plan. Evita formulaciones ambiguas como «activar cuando sea necesario».
Elección de una estrategia de recuperación
La estrategia de recuperación debe adecuarse al RPO, al RTO, al nivel de riesgo y al presupuesto de cada carga de trabajo.
AWS describe las estrategias de backup y restauración, pilot light, warm standby y multisede como enfoques con niveles de preparación progresivamente mayores y diferentes características de coste, complejidad, RPO y RTO. Ninguna arquitectura garantiza la recuperación sin pruebas periódicas.
Entorno de recuperación, credenciales y documentación
Diseñar el entorno de recuperación
Documenta dónde se restaurarán las cargas de trabajo: hardware de reserva, otro clúster, un centro de datos secundario, virtualización alojada o nube pública. Para el entorno de recuperación, documenta los recursos de computación y almacenamiento disponibles, rangos de red, conectividad, reglas de firewall, método de autenticación, estrategia de DNS y límites de capacidad. Una sede de recuperación que no puede ejecutar la carga de trabajo crítica con la capacidad mínima requerida no constituye un sitio de recuperación viable.
Proteger las credenciales de recuperación
El entorno habitual de identidades puede estar no disponible o comprometido durante un desastre. Protege las cuentas de administración de backup, cuentas de emergencia en la nube, credenciales de hipervisores, claves de cifrado e información de recuperación del gestor de contraseñas. Almacénalas fuera de los sistemas que están destinadas a recuperar, utilizando cuentas independientes y autenticación multifactor.
Proteger la documentación de recuperación
La única copia del plan de recuperación ante desastres no debe guardarse en el servidor de archivos de producción. Mantén copias controladas en más de una ubicación para que el plan siga estando accesible cuando la red principal esté caída, el inicio de sesión único falle o la cuenta habitual de administración esté bloqueada.
Crear runbooks de recuperación
El plan principal aporta la coordinación general; un runbook proporciona instrucciones técnicas pormenorizadas para una tarea de recuperación concreta, como restaurar el servidor de backup, reconstruir el clúster, recuperar la identidad o restaurar el DNS. Cada runbook debe detallar propósito, condiciones previas, accesos requeridos, pasos ordenados, comprobaciones de validación, duración estimada, pasos de reversión y puntos de escalado.
Un plan práctico de recuperación ante desastres para Proxmox
Consideremos un entorno con tres nodos Proxmox VE, almacenamiento ZFS local o compartido, un servidor Proxmox Backup Server local, una copia remota de backup y máquinas virtuales de identidad, base de datos, aplicaciones y servidor de archivos. Una secuencia de prioridad de recuperación recomendada:
CISA recomienda mantener copias de seguridad offline cifradas, probarlas en escenarios de recuperación ante desastres y restaurar los servicios críticos conforme a planes priorizados, evitando la reinfección de los sistemas limpios.
Los backups de PBS proporcionan los datos de máquinas virtuales y contenedores. El plan de recuperación ante desastres proporciona el resto del proceso. Consulta la guía de Proxmox Backup Server para profundizar en la parte de backup.
Recuperación mínima viable y retorno a la normalidad
El objetivo inicial de recuperación no tiene por qué ser siempre la operativa habitual al completo. Define un servicio mínimo viable. Por ejemplo, una tienda online puede requerir inicialmente autenticación de clientes, catálogo de productos, tramitación de pedidos y procesamiento de pagos, funcionando temporalmente sin analíticas, recomendaciones o informes históricos. Restaurar una versión reducida del servicio permite acortar el RTO efectivo.
Comunicación durante la recuperación
La restauración técnica y la comunicación deben desarrollarse en paralelo. Define canales internos de información, un método de aviso a empleados, una página de estado para clientes y contactos de escalado con proveedores. Utiliza marcas de tiempo y distingue claramente entre información contrastada y suposiciones.
Retorno a la operativa normal
La recuperación no concluye cuando la aplicación vuelve a estar accesible. Confirma la coherencia de los datos, monitoriza el rendimiento, reconecta integraciones, rota las credenciales de emergencia y restablece el tráfico gradualmente. Si el servicio se recuperó en una sede alternativa, planifica el regreso al entorno preferente. Este proceso se denomina failback y debe probarse y aprobarse con antelación en lugar de improvisarse.
Pruebas del plan
Las pruebas deben avanzar desde revisiones teóricas hasta simulacros técnicos: revisión documental, ejercicios de mesa, recuperación de componentes, recuperación en paralelo, ejercicio de failover y simulacro de recuperación completa.
AWS recomienda probar con regularidad la implementación de recuperación ante desastres y la conmutación por error para verificar que los entornos de recuperación funcionan adecuadamente y que se cumplen el RPO y el RTO.
Plantilla de plan de recuperación ante desastres
Un documento de plan completo debe estructurarse en diez apartados: control documental, propósito y alcance, criterios de activación, objetivos de recuperación, inventario de sistemas, mapa de dependencias, estrategia de recuperación, roles y contactos, procedimientos de recuperación, y pruebas y mantenimiento.
Errores frecuentes en la planificación de disaster recovery
Una solución de backup no puede decidir prioridades de recuperación, comunicación, toma de decisiones o validación de aplicaciones. Documenta el proceso completo.
Las aplicaciones pueden fallar si la identidad, el DNS, el almacenamiento o las bases de datos no están disponibles previamente. Mapea las dependencias.
Los objetivos que nunca se han medido son meras suposiciones. Realiza pruebas de recuperación cronometradas.
El plan puede desaparecer durante el mismo incidente que pretendía gestionar. Conserva copias protegidas e independientes.
Esa persona puede no estar localizable. Asigna sustitutos para cada rol y documenta los procedimientos con claridad.
Los backups cifrados y los sistemas en la nube pueden resultar inaccesibles sin claves y cuentas protegidas. Prueba el acceso de emergencia.
Recuperar todos los sistemas a la vez genera saturación y desperdicia recursos limitados. Emplea niveles de recuperación.
Un servicio esencial reducido puede restablecerse mucho antes que el entorno completo. Documenta ambos objetivos.
La restauración de una máquina virtual no evalúa la toma de decisiones, las dependencias, la comunicación ni el orden de arranque. Ejecuta simulacros más amplios.
La infraestructura, el personal, los proveedores y las aplicaciones evolucionan. Revisa el plan tras cambios significativos y después de cada simulacro.
Los sistemas temporales de recuperación pueden volverse permanentes por dejadez. Documenta y prueba el retorno ordenado a la normalidad.
Un servidor que arranca puede albergar datos incoherentes o carecer de controles de seguridad adecuados. Utiliza criterios de validación acordados.
Lista de comprobación del plan de recuperación ante desastres
0 / 34Preguntas frecuentes
Un plan de recuperación ante desastres es un proceso documentado para restablecer servicios tecnológicos, aplicaciones, datos e infraestructura de soporte tras una interrupción importante.
Debe incluir alcance, criterios de activación, prioridades de recuperación, RPO, RTO, inventario de sistemas, dependencias, roles, ubicaciones de backups, infraestructura de recuperación, runbooks técnicos, comunicación, validación, pruebas y failback.
No. Un plan de backup explica cómo se crean y protegen las copias de los datos. Un plan de recuperación ante desastres explica cómo se restaurarán y devolverán al funcionamiento los servicios completos.
La recuperación ante desastres se centra principalmente en restablecer la tecnología. La continuidad del negocio abarca el proceso más amplio de mantener operativas las funciones esenciales de la organización durante una interrupción.
Un responsable designado debe coordinar su mantenimiento, pero los encargados de las cargas de trabajo, los equipos técnicos, seguridad, dirección, comunicaciones y representantes del negocio deben colaborar.
Revisa la documentación periódicamente, prueba los componentes técnicos a lo largo del año, organiza ejercicios de mesa de forma periódica y ejecuta un simulacro de recuperación más amplio según la criticidad de la carga de trabajo y el riesgo empresarial.
El RPO define la pérdida de datos aceptable medida en tiempo. El RTO define el tiempo de inactividad aceptable antes de que el servicio deba volver a ser utilizable.
No. La alta disponibilidad puede mitigar interrupciones causadas por fallos concretos de componentes, pero no protege frente a corrupción, ransomware, errores de administración, pérdida de la sede o eliminaciones replicadas.
Un runbook contiene instrucciones técnicas detalladas para una tarea de recuperación específica, incluidos requisitos previos, credenciales, comandos, validación, tiempos estimados, reversión y escalado.
Es el conjunto mínimo de funciones necesarias para reanudar un servicio esencial. Las funciones y capacidades adicionales pueden restablecerse una vez que el servicio básico esté operativo.
Protege los backups de máquinas virtuales y contenedores en infraestructura independiente, mantén una copia externa o protegida, documenta la configuración del clúster de reemplazo, prioriza las VM fundamentales, protege las claves de cifrado y prueba la restauración en hardware alternativo.
Sí. El plan debe abordar credenciales no confiables, backups locales inaccesibles, selección de un punto de recuperación limpio, restauración en aislamiento, restablecimiento de credenciales, validación y reconexión controlada.
Conserva copias controladas en múltiples ubicaciones, incluida al menos una que permanezca accesible cuando la red de producción, la plataforma de identidad o las oficinas no estén disponibles.
Documenta el fallo, identifica la causa, asigna acciones correctivas, actualiza el plan o la arquitectura y programa una nueva prueba de validación.
Diseña un plan que otra persona pueda ejecutar
Un plan de recuperación ante desastres debe disipar la incertidumbre en los momentos más críticos de una interrupción. Debe fijar prioridades de recuperación, proteger las credenciales necesarias, clarificar dependencias, ofrecer procedimientos probados y proporcionar una secuencia de actuación precisa a las personas autorizadas.
Comienza por el servicio más importante. Define su RPO y RTO, mapea sus dependencias, identifica la copia de backup utilizable, selecciona la ubicación de recuperación, redacta el runbook, restaura el servicio en un entorno de prueba aislado y mide el resultado. Corrige después cada una de las suposiciones que hayan fallado.