Author Archives: Brendan McCaffrey

It surprises me how many people treat “disaster recovery” and “backup & recovery” as interchangeable terms. But backups are not disaster recovery, and disaster recovery is not a backup strategy. Confusing the two creates a false sense of security that often becomes visible the moment something goes wrong. The goal of this post is to offer clarity on what separates these concepts, so you can design a strategy that actually protects your business, not just your data.

What Disaster Recovery Really Is

Disaster recovery (DR) is the capability to restore business operations after a major outage, as quickly as possible. It’s about continuity, not just data. DR covers the entire stack: infrastructure, networking, applications, services, dependencies, and yes, data. It typically involves a functional version of these components in a remote location. A well-defined DR plan articulates how quickly systems must be recovered (RTO), how much data loss is acceptable (RPO), and the sequence in which components must come back online. DR is not just infrastructure, but also orchestration. It’s people, processes, automation, communication plans, and testing. You can have perfect backups and still have a failed disaster recovery effort if none of this is in place. In SQL Server, we commonly design Availability Groups where data is replicated from site A to site B, ensuring the current data set in DR is as close to real-time as Production as possible, in preparation for an unplanned DR cutover.

What Backups Are Actually For

Backups serve a very different purpose. They protect your data, not your operational continuity. A backup is a point-in-time copy that allows you to restore a database. They help you recover from corruption, accidental deletion, ransomware (maybe), and internal mistakes. Backups answer questions like “Can we get the data back?” and “To which point in time?”. But they do not answer “Can our business continue running?”. Backups are essential, but they are a safety net, not a continuity plan. Without DR, backups simply give you something to restore while you remain offline. Backups are typically most valuable when someone runs that DELETE statement without a WHERE clause (happens more than you you’d like to believe), or you discovered corruption in a database.

The Key Differences (and Why They Matter)

The easiest way to understand the difference is this: backups rewind; disaster recovery moves forward. Backups help you return to a previous state, while DR helps you resume operations after a major disruption. You can restore data without ever achieving uptime, and you can fail over to a secondary site without having clean, restorable data. DR focuses on speed and continuity; backups focus on retention and recovery points. Backups alone cannot solve for an entire data center going offline, and DR alone cannot protect you from corruption or data-loss scenarios. Mature organizations design both, because one without the other is a half-built strategy.

Summary

Disaster recovery and backup & recovery are complementary, not interchangeable. DR protects the business; backups protect the data. Both are required if you want real resilience. If you’ve only tested restores, you don’t have a DR plan. If you’ve only tested failover, you don’t have a data-protection strategy. The organizations that survive outages with minimal impact are the ones that treat DR and backups as two distinct disciplines working together. Make the distinction clear, design intentionally, and your business will be far better prepared when the unexpected happens.

Why Being “The Expert” Can Kill Your Growth, Influence, and Career

In tech, especially in the database world, we celebrate expertise. We respect the person who knows every wait type, every DMV, every undocumented trace flag. But there’s a danger hidden in becoming too comfortable being “the smartest person in the room”.

I’ve seen it in others. I’ve caught it in myself, at times.

And it’s one of the fastest ways to stall your career, damage your influence, and slowly transform into what every team dreads:

The grumpy DBA in the corner who wonders why no one listens anymore.

Here’s why you should avoid that trap, and how to do it.

When You’re the Smartest Person in the Room, You Stop Growing

Growth comes from friction:

• Someone challenging your assumptions
• Someone showing you a tool you’ve never used
• Someone explaining a pattern you haven’t seen
• Someone exposing blind spots you didn’t know existed

If you’re always the one teaching, correcting, proving a point, or worse, trying to prove someone wrong, you’re not learning.

And in a field changing as fast as data engineering, SQL Server, and cloud platforms, the moment you stop learning is the moment your value starts dropping.

Comfort feels good. But comfort kills careers.

When You’re Always Right, People Stop Listening

This part hurts, but it’s true: If you always have the answer, eventually people stop asking their questions.

Not because you’re wrong. But because you make them feel:

• Inferior
• Judged
• Uncomfortable
• Shutdown
• Interrupted

Think about the smartest engineer you’ve ever known, who constantly corrects people mid-sentence.

• Do you enjoy brainstorming with them?
• Do you feel heard?
• Do you want to collaborate?

Competence builds credibility. Humility builds influence.

If you want people to listen to you, collaborate with you, and trust you, you need to make space for others to shine.

Being the Only Expert Makes You “The Bottleneck”, Not the Hero.

Many DBAs learn this lesson the hard way. You’re proud no one else can troubleshoot broken replication, or tune a problematic query, or rebuild a broken AG. You feel irreplaceable.

Then you wake up one day and realize: If you’re irreplaceable, you’re also not promotable.

You’ve boxed yourself into a corner, and the business sees you as a single-function asset rather than a scalable leader.

Worse, you’ve trained the entire team to need you instead of to learn from you. That’s how smart experts become bitter, exhausted, and stuck.

The “Grumpy DBA” Is Usually Someone Who Never Stretched Beyond Their Expertise

The stereotype exists for a reason.

• The person muttering in the back of the meeting…
• The one ranting about how no one understands indexing…
• The one convinced that “management doesn’t listen”…
• The one who refuses to learn anything cloud-related…
• The one whose career hasn’t moved in 10+ years…

That person is often genuinely brilliant.

• But brilliance without humility becomes isolation.
• Isolation becomes frustration.
• Frustration becomes bitterness.

And bitterness is career poison.

So What Should You Do Instead?

Here’s how to avoid becoming the smartest stuck person in the room:

1. Put yourself in rooms where you’re not the expert

Go to user groups, conferences, new communities, architecture sessions, or cross-functional teams where you feel outclassed.

That discomfort is a sign of growth.

2. Ask more questions than you answer

Curiosity builds connection.

Questions create collaboration.

But always being the one with the Answers can shut it down.

Your goal isn’t to prove you’re smart. It’s to help others rise with you.

3. Build successors, not dependencies

If your team can operate without you, that’s leadership — not replacement.

4. Learn outside your lane

Cloud. Platform Engineering. Python. Security frameworks. Data governance. Observability.

These skills multiply your value.

Final Thoughts

Being smart isn’t the problem.

Believing and acting as if you are the smartest is.

• When you’re the only expert, you limit your growth.
• When you’re always right, you lose influence.
• When you isolate yourself by expertise, you become stuck.

And when you’re stuck long enough, you become the stereotypical “grumpy DBA” wondering why your career never moved.

• Put yourself in bigger rooms.
• Be curious.
• Grow with others.

And never let your expertise become the ceiling over your career.

Opening Thoughts

I had a great time attending the PASS Data Community Summit for the first time last month. It was incredible meeting so many of you face-to-face. I’m looking forward to attending more meetups and conferences in 2026.

My New Posts From Last Month

Why Email Is Outdated: Embrace Modern Workplace Tools

Stop Wasting Money on SQL Server Cores — Reduce Licensing Costs the Smart Way

Top Content I Read Last Month

Query Exercise Answer: Generating Big TempDB Spills — Brent Ozar

Local AI Models for SQL Server – A Complete Guide — Pinal Dave

“Rebuilding Indexes and Updating Statistics”: The DBA’s Panic Button — Amy Abel

Tools or Scripts Worth Checking Out

Brent Ozar’s First Responder Kit

Ola Hallengren’s SQL Server Maintenance Solution

dbatools (PowerShell Module for SQL Server Automation)

Tip for New DBAs

Successful backups do not translate to successful restores. If you’re not testing your backups, you don’t have backups.

Thanks for following along! If this was helpful, please share it with others who might benefit.

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…

I made a blog post recently called Hard Work Isn’t Enough. Add Value or Get Stuck. If you haven’t read that yet, I suggest you go check that out first.

Minimizing CPU core counts is a perfect example of how to add value, and is arguably one of the easiest ways to do so.

I run this exercise in my environments about every six months, typically right before true-up time and again at mid-year, just to make sure we haven’t drifted too far.

How expensive is SQL Server licensing?

Very expensive.

If you’re running Enterprise Edition, you’re going to pay around $7,561.50 per core. Core licenses are sold in 2-core packs, and there’s a 4-core minimum per server. If you need more cores, you must add them in 2-core increments, as you cannot split a license pack across multiple servers.

Note: Pricing varies depending on licensing program (EA, CSP, Select Plus).

That puts the minimum cost of an Enterprise SQL Server VM at:

$7,561.50 × 4 cores = $30,246 (and that’s before Software Assurance)

Want to run that VM in an HA or DR configuration? SA is required if you want to run your HA/DR replicas as free passive nodes – up to one passive HA replicas, one passive DR replica, and one passive Azure replica.

Note: If a replica performs readable queries or takes backups, it no longer counts as passive and must be fully licensed. This is one reason I don’t recommend running backups on your secondary replicas — but I digress. If you want to know the other reason, read: SQL Server Backups on Secondary Replicas: Best Practice or Bad Idea?

How much is Software Assurance?

Software Assurance typically runs around 25% of the licensing cost per year.

So if you paid $30,246 to license a 4-core SQL Server, expect to pay:

$7,561.50 per year for SA.

Yes — annually.

So, how can I reduce this cost?

The 4-core example was just to illustrate the math. In the real world, it’s not uncommon to find SQL Servers running with 16, 32, 64, or more cores. You can see now how expensive these could get.

But how do you decide if you actually need all of those cores?

Look at CPU trends over the past 33+ days.

You want at least 33 days because many workloads have monthly processing cycles, and shorter windows may give you a false sense of stability.

You’re looking for peak CPU usage, not averages.

Averages are misleading — because when that monthly job kicks off and you don’t have enough cores, things can come crashing to a halt fast.

What I typically find the first time I run this analysis:

• Most SQL Servers peak at **40–50% CPU**
• I once saw a SQL VM with **64 cores** using only 30% at peak

But don’t go straight to the floor.

If you have 8 cores and peak at 45%:

• Don’t drop directly to 4
• Drop to 6
• Monitor performance
• Adjust again if needed

Keep in mind that reducing vCPUs on any VM always requires a reboot, so schedule the change during a maintenance window.

This approach avoids risk while saving real money.

Ideal CPU targets

• Short bursts: 80–90%
• Sustained peaks: 60–70%
• Off-hours: 20–30%

If you’re consistently below these thresholds, you’re likely over-allocated.

What next?

With all the money you just saved, go invest in a great database monitoring solution.

It will pay for itself after just a single right-sizing exercise.

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