Llevamos años con Always On sobre la mesa, vendiéndolo como la solución de alta disponibilidad y recuperación ante desastres por excelencia en entornos SQL Server. Cuando alguien monta un Availability Group por primera vez, suele pensar que ya tiene resuelta la alta disponibilidad, la recuperación ante desastres, los backups, el estrés y la hipoteca. Y no es mentira, pero tampoco es magia. Quienes lo gestionamos sabemos que montar un AG (Availability Group) es fácil en demos, pero bastante más delicado en producción. Always On resuelve cosas, sí, pero también introduce otras que hay que entender, especialmente cuando hablamos de estrategias de backup.
Y es que, hasta ahora, hacer backups en réplicas secundarias era poco más que un “parche”. Con SQL Server 2025, Microsoft ha introducido una mejora que, aunque llega tarde, se agradece: la posibilidad de hacer backups completos, diferenciales y de logs directamente sobre una réplica secundaria. Vamos a ver qué cambia exactamente y cómo podemos (por fin) diseñar estrategias de backup decentes en entornos Always On.
¿Dónde se hacen los backups en un Availability Group?
Empecemos con lo básico, que no es tan obvio como parece. En un AG, todas las réplicas tienen una copia de la base de datos, pero no todas son iguales ni sirven para todo. A la hora de hacer backups, SQL Server nos permite controlar el comportamiento a través de dos configuraciones clave:
AUTOMATED_BACKUP_PREFERENCE: una propiedad del Availability Group que indica en qué réplica se deben lanzar los backups automáticos (es decir, los lanzados mediante SQL Server Agent, Maintenance Plans, etc.). Esta propiedad puede tomar los valores:
- PRIMARY: sólo se hacen backups en la réplica primaria.
- SECONDARY_ONLY: sólo se hacen en las réplicas secundarias.
- SECONDARY: se prefiere una secundaria, pero se usa la primaria si no hay otra disponible.
- NONE: no hay preferencia definida, el agente decide.
BACKUP_PRIORITY: una propiedad individual de cada réplica que define su peso relativo a la hora de ser elegida para realizar los backups, si hay varias candidatas disponibles según la preferencia anterior.
Con estas dos configuraciones combinadas, SQL Server decide en qué réplica ejecutar los backups cuando se utilizan herramientas automatizadas. Pero ojo: si ejecutas el backup manualmente (T-SQL, PowerShell, etc.), se lanza en la réplica donde estés conectado. Lo de la preferencia solo aplica en los automatismos.
Tipos de backups permitidos hasta SQL Server 2022
Ahora bien, no todos los tipos de backup están permitidos en todas las réplicas. Hasta SQL Server 2022 (incluido), las reglas eran bastante limitantes.
Los backups completos (FULL) sólo están permitidos en la réplica primaria, salvo que sean COPY_ONLY, en cuyo caso sí se pueden hacer en réplicas secundarias. Los backups diferenciales (DIFFERENTIAL) tienen el mismo “problema”, únicamente se pueden hacer en la primaria. Por el contrario, los backups de log (TRANSACTION LOG) si se pueden hacer en cualquier réplica (primaria o secundaria), siempre que esté en estado sincronizado o aceptable. Y son válidos como parte de la cadena de recuperación.
En resumen, solo los logs son realmente “migrables” a réplicas secundarias de forma productiva. El resto, si no es COPY_ONLY, requiere pasar por la primaria. Y como ya sabemos, los COPY_ONLY no afectan a la cadena de backups, por lo que no sirven como parte del plan de recuperación principal.
Este escenario genera el clásico problema, la carga de los backups importantes (full y diff) sigue recayendo en la réplica primaria, justo la que está ejecutando cargas de producción críticas. Y claro, luego vienen los lloros por I/O, CPU y ventanas de mantenimiento.
¿Qué cambiará en los backups de AG con SQL Server 2025?
Aquí llega la buena noticia. A partir de SQL Server 2025 (en preview), Microsoft amplía por fin el soporte de backups en réplicas secundarias. Y esta vez de verdad: Ya se podrán hacer backups FULL, DIFFERENTIAL y LOG en réplicas secundarias. Y no en modo COPY_ONLY, sino como parte activa de la cadena de recuperación.
Esto significa que podremos rediseñar completamente nuestra estrategia de backups en entornos Always On. Por ejemplo, podremos mover el backup completo diario a una secundaria, programar los diferenciales en otra y dejar los logs en una tercera. Todo sin tocar la primaria.
Y lo mejor es que no habrá que cambiar nada en la configuración actual del AG. Si ya tenemos configurado AUTOMATED_BACKUP_PREFERENCE = SECONDARY_ONLY y hemos definido prioridades con BACKUP_PRIORITY, esas mismas reglas se aplicarán también a full y diferenciales. Lo único que cambia es lo que SQL Server permitirá hacer técnicamente en cada réplica.
Cómo configurarlo (y cómo comprobarlo)
La configuración es la misma de siempre, para ver el valor actual de la preferencia de backups del AG podemos usar:
SELECT automated_backup_preference_desc FROM sys.availability_groups;Para ver la prioridad de backup por réplica:
SELECT replica_server_name, backup_priority FROM sys.availability_replicas;Y, si necesitas modificar la preferencia:
ALTER AVAILABILITY GROUP [NombreDelAG]
SET (AUTOMATED_BACKUP_PREFERENCE = SECONDARY_ONLY);Y podrás seguir usando la vista sys.dm_hadr_backup_is_preferred_replica para determinar en tiempo real cuál es la réplica preferida según la configuración actual. Ideal para integrarlo en scripts de backup personalizados.
Consideraciones importantes y limitaciones
Como todo cambio de este tipo, hay que tener claro qué implica antes de correr a modificar tus scripts. La réplica secundaria debe estar sincronizada y en estado ONLINE. No sirve una réplica desactualizada o en SUSPENDED. Por supuesto, el backup de log seguirá necesitando una cadena coherente. Como hasta ahora, puedes hacer logs desde réplicas secundarias, pero asegúrate de que tu estrategia de restauración tiene en cuenta su procedencia.
El restaurado no cambiará, si haces un FULL en una secundaria, un DIFF en otra y LOGs en una tercera, tendrás que restaurarlos todos en orden, desde sus respectivas ubicaciones. Esto requiere un buen control del sistema de almacenamiento y del catálogo de backups.
Por último, el rendimiento de las réplicas secundarias importa. No pienses que es buena idea mandar todos los backups a una secundaria con discos lentos y CPU de museo. Es posible, sí. Recomendable, no.
¿Cómo adaptar tu estrategia de backups?
Con esta mejora, por fin podremos plantear una estrategia de backups moderna para Always On, que de verdad aproveche la arquitectura del AG. Algunas ideas:
- Mueve los FULL y DIFF a réplicas secundarias bien dimensionadas.
- Mantén los LOGs distribuidos según disponibilidad, pero con control estricto del histórico.
- Diseña tus planes de mantenimiento con tolerancia a failover: si una réplica cae, otra puede asumir su rol.
Eso sí, no pierdas de vista que toda esta flexibilidad requiere más disciplina. El seguimiento de los backups, la monitorización y la política de retención deben estar muy claros. Porque ahora no hay excusas: puedes repartir la carga, pero también puedes complicarte la vida si no lo haces bien.
Conclusión
SQL Server 2025 traerá una mejora largamente esperada. Por fin podremos hacer backups completos y diferenciales en réplicas secundarias, de forma nativa y como parte del plan de recuperación. No es un parche ni una opción limitada, es un cambio real en cómo el motor entiende las responsabilidades de cada réplica.
Y si aún haces todos los backups desde la primaria, empieza a preguntarte por qué. Porque a partir de ahora, no es que se vaya a poder evitar: es que deberías.
Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de LinkedIn y un canal de YouTube a los que te puede unir. ¡Hasta la próxima!
