Backups on Secondary Replicas in SQL Server 2025: What’s New, What’s Better, and What Still Worries Me

Backups on Secondary Replicas in SQL Server 2025: What’s New, What’s Better, and What Still Worries Me

Back in 2022, I wrote a post called SQL Server Backups on Secondary Replicas: Best Practice or Bad Idea? At the time, the limitations were clear: backups on secondaries were restricted, operationally risky, and often misunderstood.

Three years later, SQL Server 2025 has expanded what you can do on a secondary replica. Some of these changes are genuinely great. But the question I keep getting is:

Does SQL Server 2025 finally make backups on secondary replicas a best practice?

Let’s break it down.

What’s New in SQL Server 2025

SQL Server 2025 introduces long-requested enhancements to backup capabilities on secondary replicas. Specifically:

• Regular Full backups
• Differential backups
• Transaction Log backups (as before)
• ZSTD backup compression (new in 2025)
  

This is a major improvement over previous versions, where secondaries were limited to copy-only full backups and log backups only.

Microsoft’s goal is clear: Offload more backup workload to secondaries and reduce overhead on primaries.

But as always with Availability Groups, the story is more complicated.

The Big Tradeoff: Performance vs. Reliability

• Yes, your backups run faster on a secondary replica.
• Yes, you avoid CPU, I/O, and memory pressure on the primary.

But here’s the hidden risk: When you back up from a secondary, you are now depending on replication health for your backup chain to be valid.

And I have seen far too many production environments where:

• A database is silently removed from the AG
• Secondary lag spikes for minutes or hours
• A replica goes Not Synchronizing during the backup window
• Backups succeed… but the data on the secondary was behind
  

Even in synchronous commit, replication is not perfect. SQL Server can still introduce synchronization delay silently to avoid slowing down transactions on the primary.

Backups must be predictable, not eventually consistent.

If my business continuity depends on a process, I don’t want that process introducing unnecessary points of failure.

Restore Chains in SQL Server 2025 (The Part Nobody Talks About)

With SQL Server 2025 supporting full + diff + log backups on secondaries, DBAs naturally ask:

Does a diff backup taken on a secondary depend on a full backup taken on a primary?

Yes. SQL Server maintains a unified backup chain across replicas.

But that doesn’t mean restore operations become simpler. Your restore sequence might look like:

• Full backup (secondary)
• Differential backup (primary)
• Log backups (mixed across replicas)
  

SQL Server can handle that. But, your recovery playbook may not.

AG backups across nodes increase restore complexity.

So Why Would Anyone Back Up on a Secondary?

The two real benefits are:

• Performance.
• Licensing optimization

But both of these come with tradeoffs. Primary in backup reliability. In high-availability architectures, I believe every synchronous replica should be sized to handle 100% of the production workload at any moment. If the primary cannot absorb the backup load, that points to a capacity-planning gap.

If your system is truly hammered during backup windows and you can’t add CPU, storage throughput, or improve compression, then running backups on a secondary can help. But you still need to weigh the performance benefits against:

• Replication risk
• Operational complexity
• Restore-path complications

Have these new secondary backup types supported in SQL Server 2025 changed my Opinion?

Short Answer: No.

I still prefer:

• Reliability > cleverness
• Simplicity > complexity
• Consistency > theoretical best performance

My advice today is the same as in 2022:

You can back up on secondary replicas. But you probably shouldn’t, unless you fully understand the risk, and complexity, and are prepared to accept the potential consequences.

My Recommended Backup Approach (Even in 2025)

I prefer to run Ola Hallengren’s Maintenance Solution for AG-aware backups on all replicas. But, since all of these backup jobs are AG-aware, they automatically target taking the backup on whichever replica is currently primary, or on non-AG databases as normal.

After Failover

Backup jobs continue running without change.

The new primary becomes the active backup source automatically.

No process changes required.

Most importantly:

Every database, in AG or not, is always backed up by the same job.

This prevents the terrifying scenario: “A database fell out of the AG and no one noticed… so it wasn’t backed up.”

SQL Server 2025 gives you more backup options…

But, it does not remove your responsibility to choose responsibly.

Now, I know what you’re going to say: “But we’ve been running backups on our secondary replicas without any issues.” And I’m sure you, as well as many other DBAs, have done this successfully, at least up till now. But that doesn’t change the fact that it still introduces another point of failure into the backup process. Smaller shops, accidental DBAs, or even your own team after you move on may not be prepared to manage that complexity.

We should all be architecting solutions that will easily outlast our tenure, not ones that only work because the current DBA understands the edge cases.

---

If you like what you’ve read, please subscribe so you don’t miss my latest posts…