The process cannot access the file because it is being used

[habibalby]

Hi,

Case ID:5196782

The process cannot access the file because it is being used by another process, after I reboot the Repository Server, everything becomes normal till next job starts. This it seems a well-known issue with 6.1 and Repositories... I have encountered it many times after I have upgraded it from 6.0 to 6.1, the only solution I found that rebooting the Repository server to kill the process and re-try the job it went through.



Here's another screen shot from the same job on same Repository Target.




Here it's after I rebooted the Repository Server, and Retry the job again, it started working.



Thanks,

[Gostev]

Try installing any free tool (for example Unlocker) to see what process has these files locked.

[habibalby]

Hello,

Error on Repository from one job while another job already being writing to the same Repository. How come?

Code: Select all

 Failed to save backup meta to 'E:\Backups\Critical VMs-2\Critical VMs-2.vbm'
[v-BAKProxy01.esx.local] Failed to save file content.
The remote procedure call failed
RPC function call failed. Function name: [DoRpcWithBinary]. Target machine: [10.10.10.92].

[Vitaliy S.]

Hussain, please continue working with our support team with all technical issues you may have. From your screenshot it is not possible to understand what's happening and what your configuration is. Thanks!

[habibalby]

case ID already there and waiting their reply...

After the Critical VMs-4 finished, and second Retry of Critical VMs-2 the job went through

[habibalby]

So far no errors, below I’m summarizing the changes I have done to and the error disappeared.

Old Setup with errors “file being used by another process”;

Veeam Backup Server was having three interfaces, one 172.16.30.66 where it communicate to vSphere Management Network, one it communicate to iSCSI Initiator on 10.10.10.66 and one Production 192.168.10.60 where it is joined to the production domain.

Proxies was added to the Veeam via 10.10.10.x network for sake of segregating the network traffic. Also repositories were added via 10.10.10.x network.

In this configuration, it seems the Veeam Server communicate with vCenter via the vSphere Management Network, and assigning the job to one of the proxy which is added to veeam server via 10.10.10.x network.. Repository added to the veeam via the vSphere Management Network.. Now, here I think the dilemma where the error being generated. Veeam Pulling VM info within the job from different interfaces, proxy communicate to veeam via different interfaces and job being off-loaded to disk via different interfaces. Plus, the iSCSI Initiator connecting to the Repository Target via same interfaces where it’s added to the Veeam Backup Server.

After the changed as per the attached diagram;

Veeam Backup Server has two interfaces 172.16.30.66 and Production where it’s joined to the production domain on 192.168.10.60. vCenter added to Veeam via 172.16.30.0 network as it’s set on a separate management interfaces.

Proxies and Repositories added to Veeam via the vSphere Management Network where Veeam communicate with vCenter via same Network. Repositories accessing the Repositories LUNs only via the iSCSI Network on 10.10.10.x.

Proxies set as a HotAdd mode and Jobs set as Automatically. All jobs running successfully now without any error and faster via HotAdd Mode.