SQL Server Backups on Secondary Replicas: Best Practice or Bad Idea?

Note: this post covers backup behaviors prior to SQL Server 2025…

With Availability Groups, there’s long been a common theme in the database community:

“Offload your backups to a secondary replica — it saves load on the primary.”

It sounds great in theory. And I know people who’ve done it successfully… and others who thought they were doing it. But the real question is — should you?

Backup Types available on Secondary Replicas

Let’s start with what’s actually possible.

On secondary replicas, you can perform:

• COPY_ONLY full backups, and
• Regular transaction log backups (non–copy-only).

You cannot take:

• Differential backups
• Full backups
• Or, concurrent backups of the same database across replicas.

That last point surprises many DBAs.

If a full backup is running on one replica, you can’t take a log backup of that same database on another replica at the same time.

That’s because secondaries are read-only, and the backup process can’t update the msdb backup history tables or the database’s backup LSN metadata.

For organizations relying on differential backups, this can be a deal-breaker — because diffs must be taken on the primary replica (where write access exists).

Controlling where you backups run

When you configure Availability Groups, the wizard lets you choose where backups should run.

Sounds great, right? Unfortunately, this setting is often misunderstood.

The truth:

That setting does nothing automatically, unless your backup jobs explicitly use it.

To honor the backup preference, your job must call the function:

SELECT sys.fn_hadr_backup_is_preferred_replica(‘YourDatabaseName’);

and act on the result.

Many DBAs assume checking the box in the AG Wizard was enough, only to later discover all backups still ran on the primary because their custom jobs ignored this function.

Even some third-party backup tools don’t fully honor the preference setting. So, if you’re using anything outside SQL Maintenance Plans, verify your jobs are replica-aware.

Log backups and Secondary Replicas

Another often-overlooked point:

Regardless of which replica takes the log backup, it becomes part of the same log chain across all replicas.

That’s both a blessing and a curse.

The good news:

• If you take log backups on a secondary, the primary knows about them and can truncate its transaction log accordingly.

The risk:

• Lose any of those log backups, and you’ve broken your chain.

I once saw a 3rd-party backup tool that ran “differential” jobs on a secondary replica.

Because diffs aren’t possible there, the tool quietly substituted log backups instead — adding unexpected log backups to the chain.

When a restore was later needed, that single “extra” log file became critical to recovery. But, no one knew it existed.

Always trace your backup history across replicas before assuming your chain is intact.

Integrity Checks

You might ask — “What do integrity checks have to do with backup locations?”

A lot, actually.

If you’re running DBCC CHECKDB on your primary but taking backups from your secondary, you’re assuming both databases are identical and uncorrupted.

That’s not guaranteed.

Imagine this:

You run checks only on the primary for months.

Meanwhile, the secondary develops undetected corruption.

Then one day, a table is accidentally dropped on the primary.

Because the database is in an AG, the table vanishes everywhere — and your only restore point is a corrupted backup from the secondary.

The lesson:

If you run backups from a replica, make sure you also run CHECKDB on that replica. In fact, you really should be running integrity checks on all replicas, regardless. None-the-less, be aware of this dependency when deciding where your backups live.

Backup Preference Options

Assuming you’ve built replica-aware backup jobs that call the system function, which preference should you choose?

You have four options:

• Prefer Secondary — use secondaries if available, else fall back to primary
• Secondary Only — use secondaries exclusively (dangerous)
• Primary — always use the primary
• Any Replica — allow any

“Secondary Only” is the riskiest. If all secondaries are offline, no backups will run.

At minimum, use Prefer Secondary, which provides fallback protection.

Remember: this setting applies per Availability Group, not per database, something that occasionally surprises teams with multi-database groups.

So, should you take backups on your secondary replicas?

In my opinion: No — not for your primary, business-critical backups.

Here’s why:

Backups on secondaries come with conditions:

• The replica must be connected to the primary.
• The database must be in SYNCHRONIZED or SYNCHRONIZING state. If either is false, the backup fails.

Add replication latency into the mix, and you must also add that delay to your RPO.

If your AG is 5 minutes behind and you restore a “15-minute-old” backup, you’re really restoring data from 20 minutes ago.

And yes, synchronization lag can still happen even in synchronous commit mode.

Network congestion, storage latency, or maintenance activity can delay redo.

Now imagine your weekly full backups run overnight, at the same time you patch and reboot the secondary.

Your backups fail quietly.

You keep only two weeks on disk.

When disaster hits, your last valid backup is gone.

That’s a career-defining problem.

---

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