Un corte eléctrico prolongado, una falla de almacenamiento, un ataque de ransomware o un incendio pueden detener las operaciones de cualquier empresa. Tener copias de seguridad es indispensable, pero no basta: cuando ocurre el problema, alguien debe saber qué restaurar primero, dónde, con qué equipos y en qué orden. Eso es lo que define un plan de recuperación ante desastres (DRP, por sus siglas en inglés). En esta guía le proponemos una forma práctica de empezar, sin necesidad de un proyecto enorme.
1. Identifique qué es crítico para el negocio
El primer paso no es técnico, sino de negocio. Reúna a las áreas principales y pregunte qué procesos no pueden detenerse y qué sistemas los soportan.
- Haga un inventario de aplicaciones y servidores: facturación, ERP, correo, bases de datos, archivos compartidos, sistemas de producción.
- Clasifíquelos por impacto: qué ocurre si cada uno deja de funcionar una hora, un día o una semana.
- Registre las dependencias: una aplicación puede necesitar su base de datos, el servicio de directorio, el DNS y una conexión a internet para funcionar.
2. Defina cuánto tiempo y cuántos datos puede perder
Dos conceptos ordenan todo el plan y conviene acordarlos por escrito con la gerencia:
- RTO (tiempo objetivo de recuperación): el tiempo máximo aceptable para que un sistema vuelva a estar disponible.
- RPO (punto objetivo de recuperación): la cantidad máxima de información que la empresa acepta perder, medida en tiempo desde el último respaldo válido.
Un sistema con un RPO de pocos minutos necesitará replicación o respaldos muy frecuentes; uno que tolera perder la información de un día puede respaldarse cada noche. Estos objetivos permiten justificar la inversión en infraestructura de forma realista y evitan gastar de más en sistemas que no lo requieren.
3. Elija dónde y cómo se recuperará
Con los objetivos claros, decida la estrategia para cada grupo de sistemas:
- Restauración desde backup en el mismo sitio, adecuada para sistemas con tiempos de recuperación más holgados.
- Sitio alterno con servidores de reserva, propios o alquilados, listos para recibir las copias.
- Replicación de máquinas virtuales hacia otro servidor o centro de datos, que reduce de forma importante el tiempo de recuperación.
- Servicios en la nube como destino de respaldo o de recuperación, revisando con cuidado el ancho de banda disponible para restaurar.
Verifique también que existan repuestos o contratos de soporte para el hardware crítico: de nada sirve un buen respaldo si no hay un servidor disponible donde restaurarlo.
4. Documente, asigne responsables y pruebe
Un plan que solo existe en la cabeza de una persona no es un plan. Documente los procedimientos paso a paso y guárdelos también fuera de los sistemas que podrían fallar.
- Incluya contactos actualizados del equipo interno, proveedores y soporte de fabricantes.
- Defina quién declara la emergencia y quién comunica la situación a clientes y colaboradores.
- Mantenga las credenciales de emergencia en un lugar seguro y accesible para los responsables.
- Programe pruebas periódicas de restauración: empiece por recuperar un servidor y avance hacia simulacros más completos.
- Actualice el plan cada vez que cambie la infraestructura, se incorpore un sistema nuevo o una prueba revele fallas.
Un plan vivo, no un documento archivado
La recuperación ante desastres no se resuelve con una sola compra ni con un documento que se guarda en un cajón. Es un proceso que se construye por etapas: entender qué es crítico, fijar objetivos realistas, elegir la infraestructura adecuada y comprobar con pruebas que todo funciona. Empezar por los sistemas más importantes ya marca una gran diferencia el día que algo sale mal.
Imagen: «Wikimedia Foundation Servers-8055 08», de Victorgrigas, publicada en Wikimedia Commons bajo licencia CC BY-SA 3.0. Imagen recortada y con créditos añadidos.