Error on Reverse Incremental job

[srebuccicellularline]

The first day of the release of v8 I stupidly decided to proceed with the upgrade version of the same . I did the same thing with version 7 , and I only got advantages.
Since then my file server and the machine that runs the Oracle for SAP no longer able to perform incremental backups reverse .
The error I get is Error : The process can not access the file Because It is being used by another process. Failed to open file [ E: \ VeeamBK \ xxx \ xxx2014-11-11T163940.vbk ] in readonly mode. Agent failed to process method { } Stg.IsObjectExist .
My Case is # 00675852 , but for now we are not able to achieve progress .

It happened to any of you ?

[joergr]

Some backup job running at the time when you performed the update to V8?
Did you already restart the machine (maybe the file is simply locked by windows)?

[srebuccicellularline]

Hello Joergr, I've already restarted the machine and no job where running the time I've upgraded to v8: the Veeam setup is (lucky) intelligent enough to check this.
At the moment I'm trying with another proxy: the current one is a Windows machine on vSphere (so it's using hot-add), the previous (and main one) is the Veeam server (so it could use san mode).
i'll keep my fingers crossed 'till the end and I will update the current thread.

[joergr]

OK, please keep us posted.

Joerg

[srebuccicellularline]

Hello Joerg, it worked. Now, I feel much calmer but this has taught me to avoid updating the first day of availability.

Thanks for the support,

[mloughran]

I am having the same issue, recently upgraded from v7 to v8. I run exclusive reverse incrementals from a dedicated VM install hosted in a VM, with a backup target of a Synology NAS. I have already contacted support and currently have an open case on this, just thought I would put it out there, that I am seeing the same error message.

Support says the wierd thing is, in a multiple VM backup job (I am backing up 5 different VM's on 3 different hosts,) this error usually presents only on the last one, because if they ever have seen this on the first VM, all machines would fail in the job, which is not the case for me. My first VM fails, but the following 5 complete with no errors. Obviously the complete job fails due to 1 VM failing but that is normal.

Just thought I would add to the discussion, my case is either #00674091 or #00677575

I will bring up this thread when I talk with support later today and mention the proxy idea?

[jeremyjee]

yeah, i have the same issue. i was having the issue on an older 7 release so stupidly decided to go straight to 8 as it was available. first vm in job failing, second is running fine. very wierd.

[mloughran]

No update yet, just got my case escalated, will update with any findings this afternoon.

[q1t1]

Exactly the same here...
Upgrade to v8 from v7 and the last VM failed with the same error (the 10 first VMs backuped well).

Case open (#00681320).

Will keep you updated.
Regards.

[mloughran]

Support and I changed the same 5 VM backup job to Regular Incremental. Both initial job and the regular incremental job ran successfully. Waiting on support to diagnose further, but definitely smells like a reverse incremental bug in v8.

Case #: 00676950

[Gostev]

All, since this looks to be impacting a number users, I have asked our devs to prioritize research of this issue. Will update once I hear back. Thanks!

[joergr]

OP said he had the issue with hot-add. After he switched to another server using another mode (in his case SAN) it worked for him. Or vice versa - i did not get that from his answer 100%. @The others (mloughran, q1t1, jeremyjee): Please tell about the backup-mode you are using. Is it by any chance the same in all three scenarios? This would narrow it down.

Best regards,
Joerg

[Gostev]

The issue has been confirmed and requires all 3 conditions to be met:
1. Reversed incremental job.
2. One or more disk excluded from the job explicitly or automatically (due to unsupported type).
3. Parallel processing is disabled.

The easiest way to avoid the issue is to enable parallel processing. We highly recommend that parallel processing is enabled (as there is usually no good reason not to have it enabled). Besides, this is the default setting starting B&R v7 anyway, so it will always get better testing coverage. In fact, this is the second v8 bug by now that is specific to disabled parallel processing.

That said, we are working on a hot fix for those who believe they have a legitimate scenario that requires parallel processing to be disabled. Everyone who has a support case open on this issue will be notified on hot fix availability.

And thanks for everyone's help in troubleshooting this issue.

[q1t1]

As said previously, enabling parallel processing resolves the problem.