What’s the issue?
Always On Availability Groups have an AUTOMATED_BACKUP_PREFERENCE setting that indicates which replica should service automated backup jobs for databases in the group. The available values are PRIMARY, SECONDARY_ONLY, SECONDARY (prefer secondary), and NONE (any replica), and the default when the AG is created through the wizard is SECONDARY.
This finding identifies AGs configured with a backup preference other than PRIMARY. The setting itself does not enforce where backups run; backup jobs evaluate it through the function sys.fn_hadr_backup_is_preferred_replica, which they then honor to decide whether to execute or skip.
The preferred backup location is a meaningful design decision that affects backup completeness, recovery point objectives, and licensing.
Why is this a problem?
Backups taken on a secondary replica have important limitations. Differential backups are not supported on secondaries, and full backups must be taken as COPY_ONLY, which means they cannot serve as the base for a differential restore chain. If your recovery strategy depends on differentials, the backups taken on a secondary replica do not support that strategy and a primary based full backup is still required.
Backups on a secondary also depend on the replica being healthy and current. If synchronization falls behind on the secondary running backups, the resulting backups represent older data than the primary, and your recovery point can silently drift further than expected without producing any failure alerts. The job appears successful, but it does not meet the actual recovery objective.
Licensing also factors in. Backups on a secondary require that secondary instance to be licensed, even when its sole role is to offload backups, so the cost benefit of offloading depends on the existing license posture. In environments where the secondary is licensed only for failover under software assurance, taking active backups there may exceed the passive use rights and create a compliance issue.
For these reasons, PRIMARY preference is the simplest, most predictable option. Backups always run on the primary regardless of failover, full and differential support is preserved, and licensing is straightforward since the primary is always actively licensed.
What should you do about this?
Review with the team whether the current setting was a deliberate decision or accepted as the wizard default.
If primary based backups are required for your recovery strategy, change the setting using ALTER AVAILABILITY GROUP [AGName] SET (AUTOMATED_BACKUP_PREFERENCE = PRIMARY);. The change takes effect immediately. Confirm that backup jobs are configured to use sys.fn_hadr_backup_is_preferred_replica so they honor the preference, and that the jobs are deployed on every replica with consistent definitions.
If offloading backups to a secondary is the intended strategy, document the rationale and confirm the supporting requirements: the secondary must be licensed appropriately, the synchronization state must be monitored to prevent silent recovery point drift, and the backup approach must accommodate the limitations on differentials and copy only fulls. Note that starting with SQL Server 2025, full and differential backups are supported on secondary replicas, which changes some of these tradeoffs for instances on that version or later.