How Copy-Only Backups Were Hiding Your Real SQL Server Recovery Chain
One of the most common sources of backup confusion I see, whether during routine health checks, Performance Tuning projects, or late-night recovery calls, is how copy-only backups from VM-level snapshot tools completely clutter and obscure the real SQL Server backup chain.
For years the Backup Status Report in Database Health Monitor showed every single backup record that existed in msdb, including the frequent copy-only full backups created by Veeam, Rubrik, Cohesity, Azure VM backup, AWS snapshots, and similar tools. Those copy-only backups do not break the native differential or log chain, but they make it almost impossible to see the chain that actually matters. Many DBAs would open the report, see a full backups that were only minutes old, and never realize that their true recoverable full backup was actually twelve or twenty-four hours old.
The problem gets worse when VM-level protection runs every fifteen or thirty minutes. Suddenly the backup history is flooded with dozens of copy-only entries every day, pushing the real full, differential, and log backups far down the list and out of immediate view.
The real-world impact can be severe. Restoring from a VM snapshot is almost always the slowest and most disruptive option. It requires bringing an entire virtual machine back to a previous point in time, which can mean tens of minutes or even hours of downtime just to correct a single mistaken UPDATE statement. A proper native SQL Server backup chain, on the other hand, lets you restore the last good full backup, apply the latest differential if one exists, and then roll forward with transaction logs to the exact moment before the error occurred, often with only seconds or minutes of actual data loss and almost no application downtime.
That is why we added the new Hide Copy-Only Backups toggle to the Backup Status Report in the latest release of Database Health Monitor. When the toggle is enabled, which it is by default, the report immediately filters out every copy-only backup and shows only the true native chain: the most recent real full backup, the most recent valid differential based on that full, and the current active log backup sequence. Copy-only backups are moved to a separate collapsible section so you can still verify they are happening, but they no longer hide the backups you would actually use in a real recovery scenario.
The difference is dramatic. Instead of scanning through pages of entries to find the last real full backup, you now see it at the top of the report along with clear indicators of chain health and recovery-point age. Warnings appear automatically if the native full backup is getting stale or if the log chain has stopped, even when copy-only snapshots are running perfectly on schedule.
I remember one client where a broken log backup job had been failing silently for four days. Because their VM snapshots were running every hour, the old Backup Status Report always showed a fresh full backup and nobody noticed the problem until they actually needed to restore. The new version would have highlighted the broken log chain on day one and saved them from a very expensive weekend.
If you run both native SQL Server backups and any kind of VM-level protection, download the latest Database Health Monitor from http://DatabaseHealth.com and open the Backup Status Report. Turn on Hide Copy-Only Backups and see instantly whether your real recovery chain is healthy.
And if you would like backup validation to happen automatically every day, along with rapid response when something does go wrong, take a look at our Managed Services for SQL Server at Stedman Solutions: https://stedmansolutions.com/managed-services/
Knowing the truth about your backups is the first step to sleeping better at night.