Backup Status in Database Health Monitor Just Got a Major Overhaul

How Copy-Only Backups Were Hiding Your Real SQL Server Recovery Chain (And Why We Finally Fixed It)

Over the past decade of doing health checks, Performance Tuning engagements, emergency recovery calls, and even the occasional “please tell me we have a good backup” midnight panic, one issue shows up more often than almost anything else: total confusion caused by copy-only backups created by VM-level snapshot tools.

For years the Backup Status Report inside Database Health Monitor did exactly what every other tool does: it pulled every row from msdb.backupset and displayed them in chronological order. That meant Veeam, Rubrik, Cohesity, Commvault, Azure VM backup, AWS snapshots, and every other third-party tool that takes copy-only full backups would flood the list with entries every 15–60 minutes. The result? The real native SQL Server backup chain — the one you would actually use to restore a single table or roll forward after a bad UPDATE — was buried many pages down, and most DBAs never even scrolled far enough to see it.

I cannot count the number of times a DBA has opened the report, seen a full backup timestamped eight minutes ago, declared “backups are fine,” and closed the window — completely unaware that the eight-minute-old backup was a copy-only snapshot and their last real full backup that supports differentials and log restores was actually 26 hours old.

Why does this matter so much? Because the restore experience is night-and-day different. Restoring from a VM snapshot usually means spinning up or reverting an entire virtual machine, taking the application offline for thirty minutes to several hours just to undo one human error. A proper native chain (full + optional differential + transaction logs) lets you restore in-place, often in minutes, with only seconds of data loss and virtually no application downtime. In almost every real incident I’ve worked on, the native chain is the one that saves the day — but only if it actually exists and is healthy.

That is exactly why, in the latest release of Database Health Monitor, we added the Hide Copy-Only Backups feature. One simple toggle (on by default) instantly removes every copy-only full backup from the main view. What remains is the true recovery chain: the most recent genuine full backup, the latest differential that is based on that full, and the current unbroken sequence of transaction log backups. Copy-only backups are not deleted or ignored — they are collapsed into their own expandable section at the bottom of the report so you can still confirm your VM-level protection is running, but they no longer hide the backups that matter in a real crisis.

The visual improvement is immediate. The timeline across the top now shows only the native chain. Large, clear indicators tell you the exact age of your real recovery point objective right now. Bright warning banners appear the moment a native full backup ages past your threshold or the log chain stops — even if copy-only snapshots are still firing every fifteen minutes like clockwork.

We also added a few supporting details in the same update: flags for backups taken with CHECKSUM or COMPRESSION, warnings when log backups mysteriously stop after a copy-only full runs (a surprisingly common silent failure), and a clean, auditor-friendly export that contains only the native chain.

I’ll never forget one client who had been running hourly VM snapshots for months while their nightly log backup job had been failing for five straight days because of a credential expiration. The old report always showed fresh full backups, so nobody noticed. When they finally needed to restore a deleted table, the shock was painful. The new Hide Copy-Only view would have turned that report banner red on day one and saved an entire weekend of heroics.

If you have even one server that uses both native SQL Server backups and any kind of VM-level or third-party snapshot protection, do yourself a favor: download the latest Database Health Monitor from http://DatabaseHealth.com, open the Backup Status Report, and enable Hide Copy-Only Backups. Thirty seconds of your time will tell you — accurately — whether your real recovery chain is actually healthy.

And if you would rather have those checks happen automatically every single day, with alerts and expert eyes on the results, take a look at our Managed Services for SQL Server at Stedman Solutions: https://stedmansolutions.com/managed-services/

Because nothing ruins a quiet evening faster than discovering, in the middle of an outage, that the backups you trusted were never the ones you thought they were.