Host-based backup of VMware vSphere VMs.
Post Reply
habibalby
Veteran
Posts: 391
Liked: 32 times
Joined: Jul 18, 2011 9:30 am
Full Name: Hussain Al Sayed
Location: Bahrain
Contact:

The process cannot access the file because it is being used

Post by 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.

Image

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

Image


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

Image

Thanks,
Gostev
Chief Product Officer
Posts: 31460
Liked: 6648 times
Joined: Jan 01, 2006 1:01 am
Location: Baar, Switzerland
Contact:

Re: The process cannot access the file because it is being u

Post by Gostev »

Try installing any free tool (for example Unlocker) to see what process has these files locked.
habibalby
Veteran
Posts: 391
Liked: 32 times
Joined: Jul 18, 2011 9:30 am
Full Name: Hussain Al Sayed
Location: Bahrain
Contact:

Re: The process cannot access the file because it is being u

Post by 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].

Image
Vitaliy S.
VP, Product Management
Posts: 27055
Liked: 2710 times
Joined: Mar 30, 2009 9:13 am
Full Name: Vitaliy Safarov
Contact:

Re: The process cannot access the file because it is being u

Post by 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
Veteran
Posts: 391
Liked: 32 times
Joined: Jul 18, 2011 9:30 am
Full Name: Hussain Al Sayed
Location: Bahrain
Contact:

Re: The process cannot access the file because it is being u

Post by 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 :)

Image
habibalby
Veteran
Posts: 391
Liked: 32 times
Joined: Jul 18, 2011 9:30 am
Full Name: Hussain Al Sayed
Location: Bahrain
Contact:

Re: The process cannot access the file because it is being u

Post by 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;
Image
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.
Post Reply

Who is online

Users browsing this forum: Google [Bot] and 74 guests