Context
An Always On availability group's backup preference describes where backups should run. The scheduled jobs must actually consult that preference and execute on an eligible instance. Otherwise a topology change can leave backups duplicated or absent even though the database remains available. Treat backup placement as an operating workflow rather than a checkbox.
Prerequisites
Record SQL Server versions on every replica, availability-group topology, backup types, job definitions, service identities, and artifact destinations. Confirm that a recovery operator can find backups from every possible producing instance. Version support matters: current Microsoft documentation adds full and differential backups on secondary replicas for SQL Server 2025, while earlier releases have different secondary-backup restrictions. Review mixed-version conditions during upgrades separately.
Connect preference to execution
- Inventory every backup job for each availability database on each candidate instance. Compare schedules, enabled state, destination paths, and ownership. A job present on one instance does not automatically move when the primary role moves. Identify third-party backup tooling that may implement its own placement logic before introducing duplicate native jobs.
- Review preference and priority settings against the intended failure scenarios. Then inspect how the job uses the supported preferred-replica check, such as
sys.fn_hadr_backup_is_preferred_replica. A read-only check for an authorized example database isSELECT sys.fn_hadr_backup_is_preferred_replica(N'ExampleDatabase');. Replace the illustrative name and interpret the result within that job's documented control flow. - Verify that the chosen backup type is supported on the actual replica and release. Do not apply the SQL Server 2025 secondary full-and-differential capability to older servers. Check replica synchronization and connectivity prerequisites as well as capacity. Distributed availability groups have additional placement restrictions, so map the actual topology rather than treating every secondary as equivalent.
- Rehearse job behavior after a controlled failover in staging. Confirm that one intended producer runs, skipped jobs report a clear reason, and all produced artifacts reach the recovery inventory. Validate service-account permissions and encryption material on the new producer. A job's local success does not prove that a recovery server can read its files.
Diagnostic table
| Observation | Likely gap | Next check |
|---|---|---|
| No backup after failover | Job missing or disabled | Candidate-instance job inventory |
| Multiple unexpected producers | Preference ignored | Actual job branching logic |
| Secondary rejects backup type | Version or topology restriction | Installed release support matrix |
| Job succeeds, recovery cannot find file | Artifact routing incomplete | Shared inventory and access |
Illustrative scenario
A primary role moves to another instance, but the backup job exists only on the original server and assumes that instance always owns the workload. Database traffic continues, while the backup schedule silently stops producing the intended files. The team deploys version-aware jobs to eligible instances, makes their preference decision visible, and tests the entire workflow after another staging failover.
Correct and verify
Repair job distribution or routing through the approved deployment mechanism. Check backup headers, sequence coverage, and storage access from the recovery environment. Restore a representative set outside the production availability group; do not attempt an exploratory restore onto a participating database. Include an artifact produced after failover in the acceptance test.
Operating procedure
Monitor the age of the latest usable backup centrally, rather than relying only on local job status. Record producer instance, database identity, backup type, and destination with each artifact. Review jobs after adding replicas or upgrading versions. Rehearse preference evaluation during failover so availability changes cannot quietly become protection gaps.
Explore Clouvenix backup disaster recovery for implementation and operational handover.