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.