Broken Incremental Backup Chain? Fix It Without Losing Data

Your incremental backup chain is broken. I'll show you how to repair it fast, and how to prevent this headache next time.

Quick answer

Rerun a full backup manually, then delete orphaned incrementals after confirming the new full is good. Use wbadmin delete catalog -backupTarget:E: (adjust drive) if VSS snapshots are corrupted.

Why this happens

I know this error is infuriating. You're staring at a restore wizard that says "incremental backup chain is broken" or "missing full backup point." Your heart sinks because that's your last line of defense. I've been there—twice in one week during a Windows Server 2019 migration project.

The chain breaks when the full backup at the start gets deleted, moved, corrupted, or overwritten. Or when an incremental references a VSS snapshot that's been orphaned. Common culprits: a cleanup job that went rogue, a disk that filled up mid-chain, or someone accidentally purging the oldest backup file. If you're using Veeam, it's often a metadata mismatch between the backup files and the internal database. For Windows Server Backup, it's almost always a VSS snapshot state that's out of sync.

Fix the broken chain

  1. Identify the chain head. Open your backup tool and check the backup set. Look for the full backup (.vbk in Veeam, .vhd or .vhdx in Windows Server Backup). If it's missing, note the timestamp of the last good incremental.
  2. Run a new full backup. Force a synthetic or active full backup. In Veeam, right-click the job and choose "Active Full backup." In Windows Server Backup, run wbadmin start backup -backupTarget:E: -include:C: -allCritical with the -vssFull switch. This creates a new starting point.
  3. Check the new chain. Verify the new full backup completed successfully. Test a restore to a different location if possible. This step matters because you don't want to delete the old chain until you're sure the new one works.
  4. Delete orphaned incrementals. Once the new full backup is verified, delete the old incremental files that depended on the broken full. Veeam: right-click the backup set and choose "Remove from disk." Windows Server Backup: use wbadmin delete backup -backupTarget:E: -version:06/15/2024-12:00 (use the exact version identifier from wbadmin get versions).
  5. Reset VSS state (if needed). If errors persist, run vssadmin list shadows to see orphaned snapshots. Delete them with vssadmin delete shadows /all /quiet. Then restart the Volume Shadow Copy service: net stop vss, net start vss.

Alternative fixes if the main one fails

  • Use Veeam's PowerCLI. Sometimes the GUI won't cooperate. Run Get-VBRBackup | Get-VBRRestorePoint | Where-Object {$_.IsFull -eq $true} | Select-Object -First 1 to find the last valid full. Then force a new chain with Start-VBRJob -Job "YourJobName" -FullBackup.
  • Edit the backup metadata file. For Windows Server Backup, the metadata is in Catalog.xml inside the backup target folder. If you're brave, open it in Notepad++, find the broken chain entry, and delete the block for the failed chain. I've done this twice—it works, but make a backup of the file first.
  • Use a third-party chain repair tool. If you're on Veeam B&R v12, there's an unsupported script on GitHub that rebuilds the chain from orphaned incremental files. Search for "Veeam chain repair script" on the official forums. It's not perfect, but it's saved me once.

Prevention tips

  • Always run a full backup before any major maintenance. Before you update the OS, swap a disk, or patch your backup tool, force a new full.
  • Set a weekly synthetic full. In Veeam, configure your job to run a synthetic full every Sunday. This rebuilds the chain without re-reading all the data from source.
  • Monitor disk space. A full backup drive is the number one cause of broken chains. Set up an alert when the backup target reaches 80% capacity.
  • Test restores quarterly. I do a full restore to a separate VM every three months. It's boring, but it catches metadata drift before you need it.
  • Keep at least two full backup sets. Never let your retention policy delete the oldest full until the new one is confirmed good. Most tools default to keeping only one—change that.

This tripped me up the first time too. But once you understand the chain mechanics—full backup = chain anchor, incrementals = links—it's easier to spot trouble early. And if you ever find yourself staring at that error again, you'll know exactly what to do.

Related Errors in Hardware – Hard Drives
MBR error 1 or GPT header corrupt Disk partition table corrupted – quick fix that actually works 0X00000A66 Fix 0X00000A66 DFS Volume Not Found Error kern.warn kernel: arc_kmem_reap_now ZFS ARC Cache Saturation on Linux – Quick Fixes NAS Drive Bay Shows Failed Light – Quick Fix That Works

Was this solution helpful?

EP
Erropedia Team
Tech Support Editors
The Erropedia editorial team researches and documents real-world tech errors from across Windows, Linux, macOS, networking, databases, cloud platforms, and more. Every solution is reviewed for accuracy and updated as software and systems evolve.