Las historias más desagradables con Exchange suelen empezar igual — «todo funcionaba, y luego…» — y a continuación viene una lista de detalles dramáticos: un nodo caído, registros llenos, un RAID en bucle de reinicio, que «alguien» desactivó las copias de seguridad, y sin embargo «ayer todavía entraban correos». La buena noticia es que los escenarios de desastre en entornos Exchange Server llevan tiempo estudiados y son previsibles. Si se definen por adelantado los objetivos de tiempo y volumen de recuperación, se elige una arquitectura resistente y se implementan copias de seguridad y monitorización, hasta un «mal día» puede convertirse en un procedimiento rutinario según la guía: sin pánico, con pérdidas mínimas y un resultado predecible.
Por qué empezar por los objetivos y el mapa del sistema
Antes que el hardware, las licencias e incluso antes de elegir la edición, conviene responder con honestidad a dos preguntas pragmáticas: ¿cuál es el tiempo de inactividad aceptable (RTO) y qué volumen de datos perdidos es tolerable (RPO)? Esos dos números disciplinan la arquitectura futura. Si el correo es crítico y el RTO tiende a minutos, hará falta alta disponibilidad, redundancia a nivel de servidores y almacenamiento, y procesos que funcionen de noche y en festivos. Si el RPO es cero, hay que planear copias con retardo, copias de seguridad fiables y mecanismos para reconstruir rápidamente los datos tras un arranque de emergencia.
A continuación — inventario. ¿Qué departamentos usan el correo y cómo? ¿Dónde están los cuellos de botella por volumen de tráfico, qué requisitos hay de archivado y retención legal? ¿Qué importancia tienen las carpetas públicas, qué integraciones dependen de SMTP y qué pasaría si se callaran unas horas? Un mapa de servicios permite priorizar componentes —esos se pondrán en marcha primero.
Arquitectura de alta disponibilidad
El pilar de Exchange para la tolerancia a fallos es el Grupo de Disponibilidad de Bases de Datos (DAG). Las bases de buzones se replican entre varios nodos y la copia activa puede cambiar automáticamente en caso de fallo. Es importante no solo activar el DAG, sino diseñarlo bien: distribuir roles, separar la red de replicación del tráfico de cliente, decidir dónde alojar el archivo testigo y definir la estrategia de conmutación automática.
En despliegues en un solo centro de datos conviene ubicar el archivo testigo fuera del clúster —así es menos probable perder el quórum por un desastre local. En dos ubicaciones hay que calcular la dinámica del quórum ante fallos parciales, fijar las preferencias de activación de bases y probar el comportamiento del clúster ante la partición entre sitios. No olvide las copias con retardo —réplicas aplazadas varias horas o días ayudan a sobrevivir a una corrupción lógica de datos, cuando las transacciones dañadas aún no han alcanzado todas las copias.
Balanceo de copias y selección de la mejor copia
Al conmutar, Exchange usa un algoritmo para elegir la «mejor» copia teniendo en cuenta métricas de retraso en los registros, colas de replicación y estado del soporte. No es magia: métricas correctas y alertas claras permiten ver de antemano que una copia pasiva se retrasa de forma crónica y tomar medidas antes del incidente. Auditar regularmente las preferencias de activación y los bloqueos automáticos en nodos evita sorpresas a la hora «h».
La práctica muestra que un máximo razonable de bases por servidor no es «lo que aguante», sino lo que usted puede trasladar, recrear y restaurar operativamente sin prolongar el downtime. En ediciones estándar, donde el límite de bases es menor, la planificación es todavía más importante: segmente departamentos, buzones VIP, archivos y servicios para que la caída de una base no derribe toda la oficina.
Diseño de las bases de datos
Es tentador pensar en «una base grande». Pero en cuanto acumula masa crítica, un solo fallo se vuelve catastrófico. Divida la carga en varias bases: separe buzones activos de archivos pesados, sitúe buzones de servicio y conectores de integración por fuera. Este enfoque funciona como fusible: si una base falla, las demás siguen operando.
Controle la relación entre tamaño de la base, velocidad de discos y ventana de mantenimiento. Una base grande tarda más en verificarse, en repararse y en recrearse. Varias medianas se recuperan más rápido en paralelo. Y no olvide almacenar los registros de transacciones en un volumen separado con monitorización de espacio libre —los registros llenos cortan la replicación en el peor momento.
Copias de seguridad
Exchange vive de los registros de transacciones. Cuando se hace una copia coherente con la aplicación, el Servicio de Instantáneas de Volumen (VSS) permite que los registros se apliquen y se truncen de forma segura. Si la «copia de seguridad» no entiende Exchange y solo copia archivos, los registros crecerán sin control: el disco se llenará, los servicios pararán y los usuarios se lo harán saber. Por eso el requisito nº1: use soluciones compatibles que soporten VSS y la especificidad de Exchange, no «cualquier copiador conveniente».
La clásica elección es la siguiente. Una copia completa —instantánea de todo el servidor con datos y sistema— es lenta y pesada, pero ofrece un punto de restauración simple. La incremental captura solo los cambios y es rápida, pero la restauración requiere la cadena desde la última completa y todos los incrementos posteriores. La diferencial es un compromiso: cada diferencial se refiere solo a la última completa, pero crece con la antigüedad de esa completa. Existe también la «copy backup», que no toca los registros: es útil para copias calientes antes de actualizaciones sin alterar el calendario.
Un poco de paranoia
Un esquema fiable contempla al menos tres copias de datos en dos tipos de soportes, una fuera de la instalación. Copias locales diarias en un almacenamiento separado reducen el RTO: levantar rápido significa volver a la vida rápido. Las copias fuera de sitio protegen contra incendios, ransomware y errores humanos. Piense además en inmutabilidad: almacenamiento de objetos con bloqueo contra borrado, bibliotecas de cintas con «volver al pasado», descargas periódicas aisladas sin acceso de red permanente.
Y sobre los registros: activar el «registro circular» para ahorrar espacio es tentador, pero impide recuperaciones punto en el tiempo. Si el RPO no es «me da igual», es mejor resolver la capacidad y truncar los registros mediante copias coherentes que recurrir al registro circular.
Elegir y acordar la estrategia de backup
La técnica por la técnica no sirve —discuta el calendario, puntos de recuperación y plazos de retención con negocio y cumplimiento. A algunos les importa conservar cortes anuales; a otros, tener puntos frecuentes diarios y retención semanal. Acorde esos parámetros, documentelos y verifique que el software elegido soporta su versión de Exchange y Windows y comprende DAG y la topología lógica.
La política de medios es otro capítulo. Copias diarias rápidas cerca, semanales y mensuales en otra ubicación, y anuales en un soporte de larga duración. Confirme periódicamente que las claves y contraseñas de copias cifradas y las instrucciones para el caso de «el administrador no está localizable» existen y están disponibles para quien deba restaurar el sistema por la noche.
Monitorización: ver el problema antes que los usuarios lo noten
Un administrador pasivo es un administrador infeliz. Active monitorización de rendimiento (CPU, RAM, discos, colas RPC, retrasos de entrega), de registros de eventos y del estado de las bases. Alertas sencillas por aumento de colas, «registros atascados» y retraso de replicación suelen ahorrar horas de inactividad. Transacciones sintéticas automáticas (entradas de prueba, envío de correo, acceso a OWA) dan confianza de que el servicio no solo está «arrancado», sino que realmente atiende a usuarios.
No tema escribir pequeños scripts de PowerShell que realicen comprobaciones repetitivas, recopilen estadísticas y envíen informes. Mantenga también a mano los scripts oficiales de comprobación de salud y actualizaciones regulares —es más fácil prevenir que luego explicar por qué el parche «se quedó en el buzón».
Documentación y simulacros de recuperación
La frase «todo está en la cabeza de Juan» es lo peor de cualquier plan de recuperación. Haga un runbook vivo y actualizable: dónde están los servidores, cómo se llaman las cuentas de servicio, dónde están los certificados, qué comandos lanzan RecoverServer, dónde se guardan las contraseñas de las copias y quién toma la decisión de conmutación por fallo (conmutación de emergencia). Una vez al año haga un simulacro completo: levante una máquina virtual limpia, despliegue la OS desnuda, restaure roles, conecte bases y compruebe el acceso.
Prácticas mensuales pequeñas también resultan muy útiles: tome un PST aleatorio, pruebe exportar/importar, restaure algunos correos desde un punto, levante una base de prueba desde el backup y haga un montaje aislado. Estos ejercicios afinan la coreografía del equipo y sacan a la luz huecos donde en una emergencia real no habrá tiempo para pensar.
La catástrofe no siempre es «hardware» —a menudo empieza por una cuenta comprometida, un OWA vulnerable o un malware que cifra los volúmenes con bases. Las reglas mínimas son sencillas: parches a tiempo, privilegios mínimos para cuentas de servicio, segmentación de red, autenticación multifactor, EDR (detección y respuesta en endpoints), control de acceso a las copias y su aislamiento del dominio. Cuanto más difícil sea para un atacante acceder a sus copias, más posibilidades habrá de que la recuperación sea viable.
No olvide la parte hardware: firmware de controladoras, estado de arreglos, monitorización de temperatura y alimentación. Parece una nimiedad, pero son precisamente esas cosas las que suelen fallar un viernes por la tarde.
Escenarios típicos de recuperación y cómo abordarlos
No todos los incidentes son igual de destructivos. Es útil tener «fichas» preparadas con instrucciones paso a paso —desde casos leves hasta «cae el sitio».
- Corrupción de una base. Desmontar la base, comprobar su estado e intentar una recuperación suave (soft recovery) aplicando los registros faltantes. Si no funciona —montar una copia pasiva actual, mover los buzones, recrear la copia dañada desde la sana y dejar que la replicación actualice el resto. Si no hay copias —restaurar desde backup en un entorno aislado y aplicar una recuperación con buzones temporales para que los usuarios sigan trabajando.
- Fallo de un servidor en el DAG. Mover las bases activas a nodos vecinos, verificar accesos de cliente y asegurarse de que Autodiscover y SMTP responden. Luego —RecoverServer: OS limpia, mismos nombres, mismas IP, ejecutar
Setup.exe /Mode:RecoverServery realizar la postconfiguración. Tras la vuelta, reubicar bases y alinear roles. - Pérdida de un sitio. En una arquitectura multisede cambiar a la segunda ubicación según el plan predefinido: activar las copias, cambiar registros externos, subir el testigo, ajustar preferencias de activación y notificar servicios y usuarios. Aquí marca la diferencia la automatización preparada y un playbook DNS actualizado.
Recuperación con buzones temporales: para que el correo no se detenga
Es la técnica de dar a los usuarios bases «vacías» con rapidez para que sigan enviando y recibiendo mientras los datos originales se restauran desde backup. El procedimiento es simple: crear una base vacía, conectar los buzones y devolver la operatividad al negocio. Paralelamente, en una sandbox a partir del backup se levantan las bases antiguas, se extraen los datos históricos y se van integrando con la base activa. El usuario ve su correo actual, y los mensajes antiguos aparecen a medida que se restauran —sin una parada total.
En términos prácticos es como la rueda de repuesto: el vehículo circula mientras la rueda normal está en el taller. Lo importante es no confundir direcciones de exportación/importación y evitar duplicados en la fusión final.
Recuperación sin backup: qué es posible y qué no conviene intentar
Exchange ofrece herramientas de bajo nivel, pero requieren cautela. El «soft recovery» reproduce registros perdidos y suele salvar la situación. La «hard recovery» con reparación forzada de la base (ESEUTIL /P) puede obrar milagros, pero a costa de pérdidas y de consecuencias imprevisibles —debe reservarse como último recurso, tras copiar la base dañada y con el consentimiento consciente de «sí, aceptamos perder parte de los datos».
A menudo ayuda la restauración lógica sin tocar archivos: Dumpster/Recoverable Items, Single Item Recovery, retención por litigio y los registros de auditoría permiten recuperar correos borrados sin intervenir la base. Si hay copias con retardo, reproducir los registros hasta el momento anterior al fallo ofrece la opción de retroceder en el tiempo sin perder mensajes recientes gracias a la función Safety Net.
Automatización, pipelines y control de versiones de la configuración
La fragilidad de las acciones manuales se ve con claridad en las emergencias. Plantillas de PowerShell para desplegar roles, parámetros de transporte, políticas de retención y conectores ahorran horas de «clics en la GUI» y reducen el riesgo de error. El código de infraestructura (scripts, playbooks, archivo de configuración del DAG) conviene guardarlo en un sistema de control de versiones —es un seguro contra el «¿qué cambiamos el mes pasado?». La integración con sistemas de gestión de configuración permite aplicar rápidamente ajustes idénticos en un nodo nuevo tras RecoverServer.
Otra buena práctica son las «listas de verificación para personas». Marcar un punto y seguir. En la prisa, esto evita olvidos de registros DNS, certificados no vinculados o puertos cerrados en el firewall.
Herramientas de recuperación: cómo elegir y qué esperar
Cuando la tarea es extraer datos de una base dañada u «huérfana» y el servidor no está accesible, ayudan herramientas especializadas capaces de abrir EDB, analizar la estructura, extraer buzones, archivos y carpetas públicas y exportarlos a PST o directamente al entorno en producción. Los requisitos son sencillos: compatibilidad con su versión de Exchange y el formato de bases, manejo correcto de codificaciones, exportación selectiva, registro de operaciones y validación en un entorno de pruebas antes de la migración en producción.
Sea cual sea el software elegido, trátelo como un instrumento quirúrgico: primero haga una copia de la base original, luego trabaje en aislamiento y solo después de verificar los resultados traslade datos a los usuarios. Las promesas de «arreglar todo con un clic» suelen chocar con la complejidad de una EDB, así que una evaluación sobria y un piloto en una base de prueba ahorrarán nervios y tiempo.
Errores frecuentes de los que luego se arrepienten
- Una única base grande «porque es más fácil» —si se corrompe, se pierde un departamento entero.
- Copias «de backup» que no entienden Exchange, tras las cuales los registros no se truncan y los discos se llenan.
- Falta de ensayos de DR —las instrucciones existen, pero nadie las ha usado y la mitad está obsoleta.
- Guardar las claves de cifrado de las copias en el mismo servidor que el ransomware puede cifrar.
- Dependencias no documentadas: conectores externos, retransmisores, registros DNS, certificados.
- Héroes ocasionales en lugar de automatización —una persona sabe cómo hacerlo, pero justo está de vacaciones.
Plan breve paso a paso para un «mal día»
- Evaluación: qué falló, qué bases/nodos/servicios están afectados, cuál es la magnitud.
- Estabilización: detener la degradación —liberar espacio, romper replicación defectuosa, apagar el nodo problemático.
- Comunicación: notificar a interesados, indicar previsión de RTO y prioridades de recuperación.
- Elegir escenario: failover en el DAG, recuperación con buzones temporales o restauración desde backup en aislamiento.
- Trabajo técnico: conmutación, RecoverServer, reubicación de bases, verificación de accesos de cliente.
- Verificación: prueba de inicio de sesión, envío/recepción, acceso a OWA/ActiveSync, entrega de correo externo.
- Retrospectiva: qué falló, qué alertas no saltaron, qué mejorar en arquitectura y procesos.
Conclusión: la resiliencia no es una casilla, es una costumbre
Una arquitectura pensada con DAG y copias con retardo, segmentación cuidadosa de bases, copias coherentes y probadas, monitorización atenta, ejercicios regulares y un conjunto sensato de herramientas para extracción puntual de datos convierten una «catástrofe» en un procedimiento de trabajo. No hay magia: solo disciplina, documentación y un poco de escepticismo prevencionista sobre las propias configuraciones. Cuanto antes formule sus objetivos de RTO/RPO, menos improvisación habrá en el momento crítico. Y cuanto más practiquen, más tranquilo dormirá el equipo —y con él sus usuarios.
