What’s the issue?
A backup chain is the sequence of full, differential, and transaction log backups that SQL Server uses to restore a database to a specific point in time. The chain depends on each backup having a known location and a clean relationship to the backups before and after it, so the restore process can locate the right files in the right order.A split backup chain occurs when backup files for the same database are being written to multiple locations, with no single destination containing the complete sequence. This can result from multiple backup processes running in parallel (such as a maintenance plan and a third-party tool), ad hoc backups taken without the COPY_ONLY option, or scheduled backups that have been changed to a new location without retiring the old configuration.
This finding identifies databases where recent backup history shows backup files being written to multiple distinct locations.
Why is this a problem?
A split backup chain complicates the restore process significantly. To restore to a specific point in time, the team must identify which backups exist, where each one is located, and how they relate to each other in the chain. Under time pressure during an outage, this discovery work adds delay and increases the chance of mistakes that further extend the recovery time.The condition also creates risk that the chain itself is broken. An ad hoc full backup taken without COPY_ONLY resets the differential base and changes the relationship between subsequent differential and log backups. If the team is not aware that the backup occurred or where the file was written, subsequent restores may fail in ways that are hard to diagnose, or may succeed but with a different recovery point than expected.
Split chains often indicate that multiple teams or tools are managing backups for the same database without coordination. Application teams sometimes run their own backup scripts, third-party tools may be configured at the storage layer without DBA involvement, and ad hoc operations may be performed during deployments or troubleshooting without consideration of the impact on the chain.
The condition is also worth attention because it complicates compliance and disaster recovery review. Verification that recovery objectives can be met depends on a clear, well-understood backup chain, and a split chain makes it harder to confirm that the necessary backup files exist in the expected places at the expected intervals.
What should you do about this?
Review backup history for affected databases by querying @Mode = 3 in sp_CheckBackup and identifying the distinct destinations where recent backups have been written. Confirm with the team which destinations are intentional and which are unexpected, since the expected destinations are usually obvious to the DBA team while ad hoc and third-party destinations are often the surprise.Identify and address the source of unexpected backups. If a third-party tool is taking backups without coordination, work with the tool’s owner to either incorporate it into the standard backup strategy or configure it to use the COPY_ONLY option so it does not affect the chain. If application teams are running ad hoc backup scripts, establish that all production backups go through the standard process and require COPY_ONLY for any one-off backups.
Reestablish a clean backup chain by taking a fresh full backup to the standard destination, after which subsequent backups proceed normally from that baseline. Document the destination, the schedule, and the expected sequence of files so the recovery procedure is unambiguous.