Backup Image File Corrupted Can't Restore – Fix It for Real

Hardware – Hard Drives Intermediate 👁 25 views 📅 Jun 16, 2026

Backup images fail to restore when the file's header or data blocks get corrupted. Here's what actually works, from common to rare.

1. Checksum Mismatch – Most Common Culprit

I'll bet you got an error like “The backup image file is corrupted” or “Data error (cyclic redundancy check).” That's a checksum mismatch. The backup software calculated a hash when it created the file, and now the bytes don't match. It's almost always caused by a bad sector on the drive where the image is stored, or a file transfer that got interrupted.

Last month, a client had a 500GB Macrium Reflect image that failed restore after he copied it over USB 2.0. The copy had a silent bit-flip. The fix? Re-copy the file on a wired connection, then verify the checksum before attempting restore.

What to do:

  1. Check the source drive for errors. Run chkdsk /f X: (replace X with the drive letter). This fixes file system corruption that can cause checksum errors on read.
  2. Use the backup software's built-in verify function. For example, in Veeam Agent, right-click the backup file and select “Verify.” In Windows Backup & Restore, it's under “Recovery” > “Scan for corrupt files.”
  3. If the verify fails, try restoring from a different copy of the image. Always keep at least two copies of critical backups. I tell clients: one on a local NAS, one on an external drive kept off-site.
  4. If you only have one copy, try a third-party tool like DMDE or R-Studio. They can sometimes read around bad sectors. I've recovered images from drives with 20 bad sectors this way.

2. Volume Shadow Copy (VSS) Writer Failure

When the backup was created, the VSS writer responsible for the application (like SQL Server or Exchange) might have failed silently. The backup completes, but the data within the image is inconsistent. You get the “corrupted” error only when you try to restore.

I had a client whose nightly Backup Exec job ran fine for weeks. But the restore failed every time. Turned out the VSS writer for Exchange was crashing during volume snapshot creation. The log showed event ID 13 from VSS.

Fix it:

  1. Check if the VSS service is running. services.msc → “Volume Shadow Copy” should be set to Manual and started.
  2. Run vssadmin list writers in an admin command prompt. Look for any writer in a “Failed” or “Stable” state incorrectly. The correct state for all writers should be “Stable.”
  3. If you see a failed writer, restart the VSS service: net stop VSS then net start VSS. Then run the backup again with a fresh image.
  4. Make sure the VSS writer for your app is healthy. For Hyper-V, run vssadmin list writers | findstr -i Hyper-V. If it's missing, reinstall Hyper-V integration services.

If you already have a corrupted image from a bad VSS writer, you can't fix the image itself. You need to go back to a good backup from before the VSS issue started. That's why I always keep a rolling 7-day retention.

3. File Header Damage – Partial Recovery Possible

Less common but brutal. The header of the backup image file (the first few kilobytes that tell the software how to read the rest) gets corrupted. This can happen if the drive is nearly full and the file system gets fragmented, or if the backup software crashes mid-write.

I've seen this with older Acronis True Image images from 2019. The header was missing the metadata block. The software said “not a valid backup file.”

What to try:

  1. Use the backup software's own repair tools. Acronis has “Validate and Repair” under Tools. Veeam has “Rescan Backup Repository.” Windows Backup & Restore can sometimes rebuild the catalog file (catalog.blob in the backup folder).
  2. If that fails, try a hex editor like HxD. Open the image file and search for the string “Acronis” or “Veeam” or whatever your software uses. If you see recognizable text at offset 0, the header might be intact. If it's all random bytes, it's dead.
  3. Last resort: extract files without restoring the full image. Some tools like 7-Zip can open VHDX files inside a backup image. Or use a virtual machine that can mount the image as a disk. I've done this to pull out one critical SQL database from a corrupted image — took 3 hours but saved the client's job.

Quick-Reference Summary

CauseSymptomsFix
Checksum mismatch“Data error (CRC)”, verify failsRun chkdsk, re-copy file, use DMDE
VSS writer failureBackup completes but restore failsCheck VSS writers, restart service, use older backup
File header damage“Not a valid backup file”Use software repair tool, hex edit, extract files manually

Was this solution helpful?