Skip to main content
Question

Copy job VM is failing with error server.vmdk either was not backed up successfully or restore chain is corrupted

  • April 6, 2026
  • 6 comments
  • 40 views

Copy job VM is failing with error server_flat.vmdk either was not backed up successfully or restore chain is corrupted. Failed to download disk server_flat.vmdk

 

  1. The copy job repo is immutable based and cannot delete the single VM from disk ( copy ) so that sync now option can run.
  1. The retention set is 30 days and forever incremental is enabled. The VM size is huge and trigerring active full in source backup job will make the old .vbk + .vib to delete only when new .vbk + .vib attains 30 days consuming space in local repo ( non-immutable )
  1. Is changing the repo for source backup a feasible option ( would make existing backups to move to new repo ) and then trigger an active full only for the affected VM ?
  1. What are the other options available ?

6 comments

Chris.Childerhose
Forum|alt.badge.img+21

What version of Veeam are you using?  Did you check the logs here - C:\ProgramData\Veeam\Backup?

This may be an issue that is best handled with a support case, as they will be able to check in to why the job is failing.


coolsport00
Forum|alt.badge.img+22
  • Veeam Legend
  • April 6, 2026

Though someone may chime in, imo you have a bit of complexity there ​@Bennet . Nothing crazy, but with immutability enabled on the Copy Repo (as it should be), I think it best to reach out to Veeam Support for the best way to get you sorted, and see what happened to that VM’s backup files.


kciolek
Forum|alt.badge.img+4
  • Influencer
  • April 6, 2026

I would open a case with support. Changing to a different repo would require moving the backups, and not sure it will let you since it’s immutable. 


eblack
Forum|alt.badge.img+2
  • Influencer
  • April 6, 2026

 

  1. Open the support case first.
  2. Run Veeam Backup Validator against the source chain for this VM.
  3. If the source is clean, try the metadata rescan and Forget path on the copy side.
  4. If only the copy chain needs rebuilding, manually trigger an active full backup copy and make sure you have the staging space.
  5. If source corruption is confirmed and your job uses per-machine format, consider splitting this VM to its own job to limit the blast radius.
  6. Repo change is the last resort given the immutability and space implications you already identified.

Forum|alt.badge.img+3
  • Experienced User
  • April 7, 2026

I would open a case with support. Changing to a different repo would require moving the backups, and not sure it will let you since it’s immutable. 

 


  • Author
  • April 9, 2026

Only the copy job repo is immutable and is this happening to copy job backup on a single VM.

Triggering Active full for this VM on source backup should fix this, but will have to wait for 30 days for existing .vbk and .vib files to expire till the new .vbk attains the 30 days ( forever incremental )

 

Possible option is to move the backup for this VM from backups ( disk ) to another backup job that has same copy job repo as before, trigger full backup for this VM alone at source and sync now in copy job.  Kindly advise.