In order to fix this I would suggest running an active full backup.  That will create a new chain and be in sync again.  This is usually the only way to fix this.

Thanks Chris, I will give that a try and report back

hahahahaha….. ​@RazorJ58 ..THANK YOU for posting this!  Why? Because I had the SAME exact issue happen to me literally last week, but not with a Copy Job...it was with one of my Backup Jobs. The issue I had was with 1 particular VM in only 1 of my Backup Jobs (thankfully). The metadata file (.vbm file) was at 0KB. In other words, it was corrupt. To get rid of this error, I had to remove the problem VM from the Job, then the Job and the rest of the other VMs in it backed up fine with no error. I couldn’t keep the VM and do an Active Full of just that VM either. The Job still errored out. Weird. After a successful Job ran after removing the VM, I then tried to re-add the VM to see if things would just clear out, but it didn’t. The whole Job again had the same error, so I had to keep the VM out. 

I’m pretty sure I know how my issue happened. I was reconfiguring storage switches and intentionally disconnected the switch for like 30secs during my Backup Job run. (note: I forgot I had 1 Job running...oops) For one VM in this Job, doing this disconnect ended up corrupting the backup of it, specifically, the metadata file of the 1 VM. I worked with Support, but couldn’t get this resolved. I did as you attempted...Repo rescan, but alas did nothing; again, it’s because my .vbm file was corrupt, so a rescan won’t fix that. My Job uses immutability, so I couldn’t delete the problem VM in my Job, so I had to remove it from the Job as I shared above and my Job then ran ok. I’ll get to delete the corrupt backup chain of this VM tomorrow. What I am going to try and do is delete the backup chain tomorrow, then re-add the VM back to the Job and see if it then backs up successfully. 

My guess is something similar happened for your Copy Job. Can you see your Copy Job metadata file (.vbm) and see if it shows as 0KB, or if it’s like 1.4KB or something like that. If there’s some size, it should be fine...but my guess is it’s not. If you remove just the VM in this Copy Job, my guess is the Copy Job will run ok like my Backup Job did.

You may want to reach out to Support to see if they can help you somehow even though they couldn’t help me.

Thanks for the heads up Coolsport00

The Offsite repository is maintained by my Clients internal IT person,  so I am checking with him re file sizes etc...I am pretty sure it is using immutability as well.

Sounds like I am in for some fun

Yeah....no fun. I was thankful it was just for 1 VM at least. Looks like the same for you by the error you shared? Did you try an Active Full like Chris suggested? Didn't work for me, but at least worth a try. 

Yes one VM only, liaising with Client to kick off the Active Full a bit later today

BTW... ​@RazorJ58 today I removed all my backup files and the metadata file from my Job, re-added the VM to my Job, & the backup ran successfully. 

Okay...Looks like I got to use my “Get out of Jail” free card….

We moved the rogue zero byte vbm file and re-ran the job, it came up with a warning first time through and then successful after that.

Thanks ​@Chris.Childerhose & ​@coolsport00  for your responses very useful info for any future issues.

I don’t spend a lot of time working with Veeam so it is great to know there many experienced and helpful users in the community

Regards

Razorj58

Glad to hear you fixed the issue ​@RazorJ58 be sure to mark the post that best helped you answer your question or led you to the answer even that happens to be your own post.

Nice! Glad you got it sorted. 

Had a Linux Repo have a small hiccup during a copy job.  0B .vbm folder similar to this.

Tried a rescan, and many other things without success until the following.

Rename that 0B .vbm file to filename_old
Rescan the Repository after renaming the .vbm file,

Run the job again.

It’s actually a very easy fix once you rename the file. 

Hi All,

Bumping this thread as I have very similar problem with stalled connection to an ISCSI repo holding offsite disk copy jobs only. The Veeam Database has zero byte file names. However if you manually look at the target repository those files do not physically exist in the Repo.  Rescanning does not remove them the database. It announces it is skipping 13 files and nothing changes. Even disabling the job doesn’t change that. Opening a ticket with Veeam now.

interestingly before I opened a new case I reviewed an old one and think I have found an added complication. We use a Scale Out Backup Repository (SOBR) and split our increments and our fulls across to seperate iSCSI extents. I needed to scan the SOBR not the individual repositories to see the missing files and their location. My Bad, forgot the obvious. Once I did that I could see the missing files and their locations. Deleted the physical bad files and rescanned the SOBR. Now I had the forget option. Forgot all unavailable backups. Rescanned SOBR and now no new files found but skipped 10 across both ScaleOut1 and ScaleOut2 (1 skipped on SO1 and 9 skipped on SO2). renabled the Backup Copy job and it started running the missed pair of VMs but still same VBM not synced on one  but the other is moving now because it is a full. Need to fire off an Active Full on the backup of the corrupted chain I expect. Trying that now.

Yeah usually when you encounter missing files doing an active full creates a new chain to work with and solves the issue.