11/03/2026
by Marlon Ribunal
0 comments

The Proof of the Backup Is in the Pudding

Sometimes, a simple comment on LinkedIn gives you an idea worth writing about.

After sharing my thoughts on SQL Server native backups using Ola Hallengren’s Maintenance Solution, Mark Gribler left a comment that caught my attention:

“The proof of a backup is a restore” (apologies to puddings)!!

I had to smile at that one.

It’s a clever play on the old saying, “The proof of the pudding is in the eating.” And the more I thought about it, the more I realized how perfectly it describes what a good SQL Server backup strategy should be.

You can have a backup job that runs every night, reports success, sends you an email notification, and gives you a nice green checkmark on your monitoring dashboard. But until you have successfully restored that backup, what exactly have you proven?

Mark’s comment gave me the idea for this blog post.

My original LinkedIn post questioned why some people consider native SQL Server backups old-fashioned, particularly when there are plenty of modern third-party backup products available today.

Apparently, I touched a nerve or two.

The discussion brought some interesting responses. Quite a few DBAs shared their confidence in Ola’s solution, while others shared less favorable experiences with third-party backup products.

But regardless of which side of the discussion you belong to, I think we can agree on one thing:

A backup is only as good as your ability to restore it.

A successful backup is only half the story

As DBAs, we spend a lot of time making sure backups are running as scheduled. We configure full, differential, and transaction log backups. We monitor job history, check backup sizes, review failures, and make sure backup files are being written to their intended destinations.

All of that is important.

But there is another question we should be asking:

Have we actually restored those backups?

A backup job reporting success doesn’t automatically mean you have a working recovery strategy.

The backup file might be inaccessible when you need it. The storage location might be unavailable. You might discover that the backup chain is incomplete, or that the process of restoring the database takes considerably longer than expected.

And then there’s the possibility that nobody has actually tested the recovery procedure.

Imagine being in the middle of a production incident, with management asking how long it will take to bring the database back online, only to discover that the backup process you’ve trusted for months has never been tested through an actual restore.

That’s a situation I’d rather avoid.

Why I still like Ola Hallengren’s Maintenance Solution

I’ve been a fan of Ola Hallengren’s Maintenance Solution for a long time, particularly its backup component.

It is mature, well-established, widely used, and does what it is supposed to do.

One thing I appreciate about it is its simplicity. Ola’s backup solution provides a consistent and configurable way of executing SQL Server’s native backup commands. It handles the scheduling, backup file naming, retention, cleanup, and other operational details that DBAs need to manage.

Underneath it, SQL Server is still doing the actual backup work.

The resulting backup is a native SQL Server backup. You don’t need Ola’s Maintenance Solution installed to restore a database backed up through it. You can use SQL Server Management Studio, T-SQL, or other supported restore methods.

For example:

EXECUTE dbo.DatabaseBackup
    @Databases = 'MyDatabase',
    @Directory = 'D:\SQLBackups',
    @BackupType = 'FULL',
    @Verify = 'Y',
    @Compress = 'Y',
    @CheckSum = 'Y',
    @LogToTable = 'Y';

And when it comes to restoring:

RESTORE DATABASE [MyDatabase]
FROM DISK = 'D:\SQLBackups\MyDatabase.bak'
WITH CHECKSUM, STATS = 10;

Of course, these are simplified examples. A real recovery procedure needs to account for the backup chain, recovery model, file locations, database state, and other requirements.

But that’s part of what I like about this approach. The backup and restore process uses capabilities that are already part of SQL Server.

There is no additional backup engine that I need to understand before I can recover a database.

I’m not saying Ola’s solution is the only way to back up SQL Server. I’m saying it is a proven and practical option that continues to serve its purpose very well.

Do we really need another layer of complexity?

This is where I become a little more cautious about third-party backup products.

Don’t get me wrong. There are legitimate reasons to use them.

Organizations may have centralized backup requirements, enterprise retention policies, offsite replication, immutable storage, reporting, or backup management across different platforms. A third-party product may address requirements that go beyond simply backing up SQL Server databases.

That’s perfectly reasonable.

However, I sometimes wonder whether we introduce more complexity than necessary when choosing a backup product.

Some products integrate deeply with SQL Server, while others introduce their own management layers, agents, processes, and recovery dependencies.

The concern isn’t necessarily how the backup is taken. It’s what happens when you need to restore it.

Do you need the same third-party software to perform the restore? Does it require a particular version of the product? What happens if the backup server is unavailable? What if the product license has expired, or the organization no longer has access to the software?

Can you restore a database without having to go through several layers of infrastructure and dependencies?

These are questions worth asking before committing to a backup product.

I’ve seen discussions from DBAs who have experienced limitations with third-party backup solutions, particularly when it comes to restoring databases or performing more specific recovery operations.

And that’s something worth considering.

SQL Server has several recovery capabilities, including point-in-time recovery, file and filegroup restores, and page restores where supported. Your backup strategy and chosen tools should support the recovery scenarios your environment actually requires.

Having a product that can report successful backups across hundreds of servers is useful. Having one that can reliably get your databases back when things go wrong is far more important.

Old doesn’t necessarily mean ineffective

Another thing that came out of the LinkedIn discussion was the recurring perception that native SQL Server backups are somehow outdated.

I don’t quite understand that argument.

Just because something has been around for a long time doesn’t mean it has stopped being effective.

SQL Server’s native backup and restore capabilities have been around for decades. Microsoft continues to support and improve them. Ola Hallengren’s Maintenance Solution has also been around for years, and it continues to be maintained and used by DBAs around the world.

Why replace something that works simply because something newer is available?

I’m all for modern tools and technologies. They have their place, and I don’t think we should dismiss them just because they come from a third party.

But newer doesn’t automatically mean better. More features don’t necessarily mean a better recovery process. And a more sophisticated backup dashboard doesn’t guarantee that your database can be restored.

Sometimes, a straightforward and well-understood approach is exactly what you need.

Test your backups. Actually restore them.

If there’s one thing I’d like DBAs to take away from this discussion, it’s that backup monitoring should not stop at checking whether a job completed successfully.

We should also have a process for regularly testing restores.

A few things I’d want to see in a SQL Server backup and recovery routine:

  • Regular restore testing. Restore production backups to an isolated environment. Don’t just assume that a successful backup job means everything is fine.
  • Backup integrity checks. Use backup checksums and appropriate verification procedures. RESTORE VERIFYONLY can provide an additional check, but it is not a substitute for performing an actual restore.
  • Recovery time validation. Know how long it takes to restore your databases. A technically successful restore that takes 20 hours when the business expects recovery within two hours is still a problem.
  • Point-in-time recovery testing. Make sure your full, differential, and transaction log backups work together as expected.
  • Documented recovery procedures. Know where the backups are, what dependencies are involved, and who can perform the restore.

I would also include system databases and other instance-level dependencies in the overall disaster recovery plan. Restoring a user database is one thing. Recovering an entire SQL Server environment is another.

The important thing is to make recovery testing part of the routine, not something you figure out for the first time during an emergency.

I don’t have anything against third-party backup products. If they solve a real business requirement and provide a reliable recovery process, by all means, use them.

But I wouldn’t dismiss native SQL Server backups or Ola Hallengren’s Maintenance Solution simply because they aren’t the latest products on the market.

For me, the objective is straightforward: have a backup strategy that is reliable, understandable, maintainable, and, most importantly, restorable.

A successful backup job is good news. A successful restore is proof that your backup strategy actually works.

So the next time your backup job reports success, don’t just celebrate the green checkmark.

Restore it. Test it. Prove it.

Because the proof of the backup is in the pudding!

And in our world, the pudding is the restore.

And thanks to Mark Gibler for the inspiration. I think he put it better than I could have: the proof of a backup is a restore.

10/29/2026
by Marlon Ribunal
0 comments

SQL Server Problems You Can Reproduce, Measure and Fix: A Free Demo Library

A note on how this was made: I built these demos and explainers with the help of AI. Every script runs against real SQL Server instances, checks its own predictions, and is re-run by continuous integration on SQL Server 2019, 2022 and 2025, so the numbers here come from those runs.

Most SQL Server advice arrives as a rule: don’t use NOLOCK, rebuild indexes over 30% fragmentation, make every string nvarchar(max) because storage is the same anyway. Some of those rules are right, some are half right, and a few are wrong in ways that only show up under load.

I wanted to stop repeating rules and start showing evidence. So I built SQL Server Demos: a free, open-source library of runnable demos. Each one reproduces a real production problem on purpose, measures every common fix, and checks its own predictions. Every topic also has a short explainer here on the blog, in the SQL Server Demos library.

What’s in the library

The demos are organised around the symptom you’re seeing, not the feature name, because that’s how problems arrive in production:

The full list is on the library page.

A few things the demos measured

The point of running the demos rather than reading about them is that the numbers sometimes disagree with the folklore:

  • NOLOCK read a balance that never existed. The writer rolled back, and the reader had already returned the uncommitted value. RCSI returned the last committed value with no wait at all. (RCSI and snapshot isolation)
  • A 99.97% fragmented index did exactly the same reads as a clean one, to the page. Half-empty pages, at 0.12% fragmentation, doubled the reads. (index fragmentation)
  • varchar(4000) holding 17-character names was granted 1.4 GB of memory for a sort that used 24 MB. varchar(50) was granted 68 MB. (memory grants)
  • Page 1,000 with OFFSET ... FETCH took 159,530 reads. Keyset paging took 217, on every page. (pagination)
  • IF EXISTS ... INSERT produced 598 primary key violations in 800 upserts under concurrency. UPDLOCK, SERIALIZABLE produced none. (upsert race conditions)
  • On SQL Server 2025, the classic catch-all search dropped from 3,001,752 reads to 16,286 at compatibility level 170, but two optional parameters can still reuse a bad plan. (optional parameter plans)

How the demos are built

Every topic follows the same shape, so once you’ve run one you can run them all:

  1. 01-setup.sql builds the data, usually in a database of its own.
  2. 02-demo.sql runs the whole demonstration unattended and captures its own evidence.
  3. 03-cleanup.sql puts back anything setup changed and drops everything.

Each demo ends with a result set listing anything that didn’t behave as predicted. Continuous integration runs every topic on SQL Server 2019, 2022 and 2025 on every push, so a passing run means the behaviour described really happened on that version, not just that the script finished.

They’re also written to be safe on a shared instance. Nothing flushes the whole plan cache or clears instance-wide wait stats, and setup records every setting it changes so cleanup can restore it. They’re still demos, though: run them on a scratch instance. A docker-compose.yml in the repo starts SQL Server 2019, 2022 and 2025 side by side.

Each explainer is a one-page answer

The explainers are short reference pages, not essays. Each one covers:

  • What you’ll see: the symptom, in the words you’d search for
  • Why it happens
  • What to do, and what doesn’t help
  • Check your server: a read-only query to run on your own instance
  • Run it yourself: a link to the demo on GitHub

Every page also has a short link, such as marlonribunal.com/go/parameter-sniffing, to paste into a ticket or a chat.

Try it

If the library helps you, a star on GitHub or a share with your team helps other people find it.

Frequently asked questions

Are the SQL Server demos free?

Yes. The scripts are MIT-licensed on GitHub, and the explainers are free to read.

Which SQL Server versions do the demos support?

Continuous integration runs every demo on SQL Server 2019, 2022 and 2025. Demos for newer features report SKIPPED on older versions instead of failing. Azure SQL Database and Managed Instance haven’t been tested.

Can I run the demos on a production server?

No. Several demos change database settings by design. Run them on a scratch instance; the repo’s docker-compose.yml starts one in a minute.

Do I need a sample database?

Only the parameter sniffing demo needs WideWorldImporters. The others create their own data.

10/23/2026
by Marlon Ribunal
0 comments

Book Review: Microsoft 365 Copilot and Agent Administration Fundamentals

I don’t currently manage Microsoft 365 Copilot in an enterprise environment, but it is one of those technologies that I want to understand better. As AI becomes part of the tools organizations use every day, there is more to learn than just how to use Copilot.

Someone has to manage access, understand licensing, protect company data, and make sure these tools are being used appropriately. And if I ever find myself responsible for that side of things, I want to have a good foundation to start with.

That is where Steve Miles’ Microsoft 365 Copilot and Agent Administration Fundamentals, published by Packt, comes in.

The book covers quite a bit of ground, starting with the fundamentals of Microsoft 365 administration before moving into security, data protection, Copilot, and AI agents. It also prepares readers for the Microsoft AB-900 certification exam.

Understanding What Happens Behind the Scenes

One thing I appreciate about the book is that it starts with the basics. Before getting into Copilot administration, you need to understand the Microsoft 365 environment in which it operates. This includes identity, licensing, permissions, and the different services that make up Microsoft 365.

Some of these topics may already be familiar to IT professionals who work with Microsoft 365 regularly. For others, particularly those coming from a different area of IT, having these concepts explained in one place can be useful.

The security and data protection chapters are especially relevant. Copilot works with organizational data, so understanding how permissions affect what users can access is important. The discussions around Microsoft Purview, data governance, and oversharing in SharePoint help explain why deploying AI tools in an organization requires more thought than simply enabling a feature and giving users access.

This is probably one of the areas I find most interesting. We often talk about what AI can do, but there is another side to the conversation. What information can it access? Are existing permissions appropriate? What happens when sensitive information is exposed to people who should not have access to it? These are questions administrators need to consider before rolling out these tools.

Copilot and Agents Administration

The later chapters get into the administration of Copilot and agents, including licensing, usage monitoring, billing, access control, approval processes, and lifecycle management.

I like that the book covers these operational considerations alongside the features themselves. Understanding what Copilot and agents can do is one thing. Knowing how to manage them within an organization is another.

The sections on creating, testing, approving, and monitoring agents are particularly useful for anyone looking to understand how these tools fit into an organization’s existing environment. There is also value in learning how licensing and access restrictions affect what users can actually do.

Of course, reading about these administrative tasks is different from performing them in a live tenant. I would still want to get hands-on experience with the relevant admin centers and settings to reinforce what I have learned. But having the concepts laid out first gives me a much better starting point.

A Useful Learning Resource

Another thing I appreciate about technical books is having the material organized into chapters that I can revisit when needed. Online documentation is valuable, especially when looking for current configuration details, but sometimes I want a structured path through a subject before diving into individual features.

The book includes chapter summaries, key terms, Microsoft Learn references, and review questions. These are useful for reinforcing the material and preparing for the AB-900 exam. The exam-oriented approach also gives readers a way to check their understanding as they progress.

One limitation worth mentioning is that this is a fundamentals book. Readers looking for extensive, real-world deployment walkthroughs or advanced troubleshooting scenarios may need to supplement it with hands-on practice and Microsoft’s documentation. Given the breadth of topics covered, there is only so much detail that can fit into a single book.

Still, I think that is a reasonable trade-off for a resource intended to establish a foundation across Microsoft 365, security, Copilot, and agents.

Final Thoughts

Microsoft 365 Copilot and Agent Administration Fundamentals by Steve Miles is a useful addition to the technical bookshelf, especially for IT professionals who want to expand their knowledge beyond the technologies they currently manage.

I may not be administering Copilot in an enterprise environment today, but I can see the value of understanding what goes into managing it properly. If that responsibility comes my way in the future, I will have a starting point and a better idea of what I need to learn next.

And even if you are already working with Microsoft 365, the book offers a structured way to review the fundamentals and connect them to the administration of Copilot and AI agents.

That alone makes it a worthwhile read for anyone looking to get a better grasp of this part of the Microsoft ecosystem.

Verified by MonsterInsights