About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not a lab validation of the procedures. Check the stated versions and your own recovery requirements before making changes.
An Always On availability group keeps copies of a set of databases on several SQL Server instances. One instance, the primary replica, takes the writes; the others, secondary replicas, receive them. A natural question follows: if there are several copies, why back up on the busy one?
SQL Server lets you take backups on a secondary instead. That is useful, but it changes the backup design in ways that are easy to miss. Backups can now come from more than one server, the setting that chooses the server is advisory, and the record of what was backed up is spread across replicas.
This article sets out what Microsoft documents and turns it into questions for a restore.
Why back up on a secondary at all
Microsoft's article on backup on secondary replicas puts the reason plainly: Backup operations can put significant strain on I/O and CPU (with backup compression). Moving that work to a secondary leaves the primary's resources for the production workload.
The same page adds an important note: RESTORE statements aren't allowed on either the primary or secondary databases of an availability group. In our reading, this means a restore is a separate exercise from the availability group itself. The group protects against a server failing; it does not undo a bad change, which every replica receives. Backups remain the protection against that.
What a secondary can and cannot back up
Before SQL Server 2025, the list of backups a secondary can take is short, and the details matter. Microsoft’s backup-configuration guide says a secondary need not be readable to offload backups to it, with an exception for managed backups; health and primary connectivity requirements still apply.
Full backups must be copy-only. Microsoft states that to perform a full database backup on a secondary replica, you must take a copy-only backup, because copy-only backups don't affect the log chain or clear the differential bitmap. The copy-only backups article explains what that means: A copy-only full backup can't serve as a differential base and doesn't affect the existing differential base.
Differential backups are not supported on secondaries in those versions. If differentials are part of the plan, they run on the primary, and their base is a full backup taken there, not a copy-only full taken on a secondary.
Log backups are regular log backups. The secondary-replicas page says that BACKUP LOG on a secondary supports only regular log backups, not copy-only ones, and that a consistent log chain is ensured across log backups taken on any of the replicas, whether primary or secondary and whatever their commit mode.
The secondary must be healthy. A secondary must be able to communicate with the primary replica, and must be synchronised or synchronising.
No concurrent backups across replicas. Microsoft notes that running a log backup on the primary while a full backup runs on a secondary is not currently supported.
A side effect worth knowing
The page also describes a subtle interaction. While a copy-only backup runs on a secondary, it prevents log truncation on that secondary for the duration of the backup. If the primary truncates its log past a point the secondary still needs, the secondary can report error 9019, and Microsoft explains that synchronisation for that secondary then fails until the copy-only backup completes. For a synchronous-commit secondary, it adds that write workloads on the primary replica might be blocked until the log can harden on the secondary.
In our reading, this means a long full backup on a synchronous secondary is not completely free for the primary. Timing large fulls away from peak writes is worth considering.
Distributed availability groups
For distributed availability groups, Microsoft says backups can run on secondaries in the same availability group as the active primary, or on the primary replica of a secondary availability group, but not on a secondary replica inside a secondary availability group.
SQL Server 2025 widens the choice
The same page has a newer section that applies to SQL Server 2025 and later: Starting with SQL Server 2025 (17.x), in addition to existing copy-only and transaction log backups, you can also perform full, and differential backups on any secondary replica.
In our reading, this removes the main reason for keeping full and differential backups on the primary, for groups whose replicas all run SQL Server 2025. In a group still being upgraded, the older limits are the safe assumption until every replica that might run the backup is on the newer version. We have not tested how mixed-version groups behave and make no claim about it.
The backup preference is advice, not a rule
Microsoft's page Configure backups on secondary replicas of an Always On availability group describes two settings: an automated backup preference for the group and a backup priority for each replica.
The preference has four options:
- Prefer Secondary: backups should occur on a secondary, except when the primary is the only replica online. Microsoft notes This is the default option.
- Secondary only: backups should never be performed on the primary. If the primary replica is the only replica online, the backup should not occur.
- Primary: backups always on the primary, which Microsoft describes as useful when you need features, such as differentials on older versions, that secondaries do not support. When log shipping prepares secondary databases, Microsoft says to keep this preference until every secondary is prepared and joined.
- Any Replica: backup jobs ignore the replica's role, and may weigh other factors such as priority and state.
Backup priority is a number from 0 to 100 for each replica, where 1 is lowest and 100 is highest. A priority of 0 excludes the replica from backup candidacy; the default is 50. The dialog also provides Exclude Replica for a replica that should never be selected. Microsoft's PowerShell guidance describes it as the value used to decide which replica should service an automated backup request, with the highest priority chosen. The follow-up section refers to replicas whose priority is greater than zero as the candidates for running backup jobs.
The most important sentence on the page is in a warning box: There is no enforcement of the automated backup preference setting. Microsoft continues that its interpretation depends on the logic, if any, scripted into backup jobs, and that the automated backup preference setting has no impact on ad hoc backups.
How the preference is meant to be used
Microsoft's intended pattern is that a backup job is created for every availability database on every server instance that is a candidate for running backups. Each job asks the function sys.fn_hadr_backup_is_preferred_replica whether its own server is currently preferred. Microsoft explains that each job looks at the same data, so only one of the scheduled jobs actually proceeds to the backup stage.
Two details of that function are worth knowing:
- For a database that isn't in an availability group, it always returns 1, meaning "yes, back up here".
- For a database that doesn't exist, the answer changed between versions. Microsoft states that from SQL Server 2019 CU20 and SQL Server 2022 CU2 it returns 0, and that In earlier versions, the function returns 1.
In our reading, the second point is a trap for older builds: a misspelt or renamed database name could make a job believe it is the preferred replica and attempt a backup that then fails, rather than skipping quietly.
Failover changes the answer
The preferred replica is not fixed. When a failover happens, the old primary may become a secondary and a secondary becomes the primary, so the function's answer on each server can change from one run to the next without any change to the jobs. In our reading, that is the point of the design, and also why the backup record has to follow the database rather than the server: after a failover, the next log backup in the chain may be written by a different server from the one that wrote the previous one.
What goes wrong in practice
Taken together, our reading is that the following situations are possible by design:
- A backup tool, or a person, that does not ask the function will back up wherever it runs, regardless of the preference.
- A replica with no backup job never backs up, even when it becomes the preferred one after a failover.
- With Secondary only, if every secondary is offline, no backup runs. Microsoft documents this behaviour; it is a deliberate trade-off that should be monitored.
- Two tools each backing up on a different replica can both succeed, leaving two partial views of the chain.
Where the backup history lives
Microsoft's article on backup history and header information states that A complete history of all SQL Server backup and restore operations on a server instance is stored in the msdb database. It advises: back up msdb frequently.
The phrase "on a server instance" is the key for availability groups. In our reading, each replica's msdb records the backups that replica took. When log backups move between replicas, which the preference is designed to allow, no single server's history shows the whole chain. A restore tool that builds its plan from one server's history may miss files taken on another.
This matters most in the situation backups exist for. If the primary is lost and a restore is needed on a new server, the history needed to plan it is spread over the surviving replicas and, possibly, the server that was lost.
Design questions for a restore
From the points above, these are our recommendations for an availability group backup design:
- Write down the preference and priorities, and confirm every backup tool and job honours them. Remember that the setting enforces nothing.
- Put a backup job on every candidate replica, so backups continue after a failover.
- Use a consistently discoverable protected backup location for every replica with a naming scheme that identifies the database, backup type and source replica.
- Keep a backup record outside any one server, so the full log chain can be reconstructed without the primary's msdb.
- Know where your differential base is. Before SQL Server 2025, differentials run on the primary and depend on a full taken there, not on a copy-only full from a secondary.
- Avoid overlapping tools. Two products, or a product and a native job, backing up the same database on different replicas spread files from the single database log chain across multiple locations.
- Monitor for no backups at all, especially with Secondary only, where an outage of the secondaries stops backups by design.
- Test a restore to a server outside the group, using only the shared backup location and the external record, then add the restored database back to the group as a separate, documented step.
Check the failover case in the backup design
A preference-aware job reporting success can mean it correctly skipped this replica. Monitoring must therefore establish that another eligible replica actually produced the required backup, not merely that every scheduled job ended without an error. Record the database, chosen replica, backup set and output location for each completed run. After a failover, confirm the newly eligible server has the same destination access and encryption dependencies.
A shared location simplifies discovery but can itself be a failure domain. Keep the retained backup sets protected independently of the availability-group hosts, and preserve all files needed for a selected restore point. The log remains one logical chain across replicas; two independent tools can split possession of its files without creating two safely interchangeable chains. A rehearsal should include a log sequence written on more than one replica and prove that the recovery inventory finds every required file.
Risks and limits of this article
- Based on Microsoft documentation as read on 11 November 2026. Behaviour can change between versions and cumulative updates.
- We did not test mixed-version groups, distributed groups or SQL Server 2025's new secondary backups.
- The statements about history being spread across replicas, and about the consequences of tools ignoring the preference, are our reading of Microsoft's documentation, not quoted behaviour.
- No backups, restores or scripts were run for this article. Microsoft's example code is deliberately not reproduced.
Sources
Writer research: 11 November 2026. Independently reopened for review: 13 November 2026.
- Microsoft Learn: Offload backups to secondary availability group replica
- Microsoft Learn: Configure backups on secondary replicas of an Always On availability group
- Microsoft Learn: sys.fn_hadr_backup_is_preferred_replica (Transact-SQL)
- Microsoft Learn: Copy-only backups
- Microsoft Learn: Backup history and header information
This article was originally published on .