Processing 'xxx' Error: Storage 'xxx' is locked by...

[VladV]

Whenever a restore job or surebackup job is running against a VM that will be processed for backing up or for replication the following error occurs: Processing 'xxx' Error: Storage 'xxx' is locked by running session 'xxx'

I understand that this is a normal behavior, but what I don't understand is why is it necessary to have the following stages executed before this check:
7/9/2014 10:37:09 AM :: Inventoring guest system
7/9/2014 10:37:11 AM :: Preparing guest for hot backup
7/9/2014 10:37:14 AM :: Creating snapshot
7/9/2014 10:37:16 AM :: Releasing guest
7/9/2014 10:37:22 AM :: Removing VM snapshot

It would be better to first check that the machine to be processed is not locked and only then proceed with snapshoting. Otherwise over the course of 4 attempts the production VM will undergo 4 snapshots and 4 commits just to find out that it cannot actually backup/replicate that VM.

Is this possible?

Regards

[Vitaliy S.]

Hi Vlad,

I believe it was more optimal to make this check prior proceeding to VM data transfer, because there are VMs that can take significant time from inventoring and preparing guests stages to actual data transfer, for example highly transnational applications are not very quick to prepare themselves for hot backup (given that VSS option is enabled). However, your suggestion also does make sense.

Thanks for the feedback!

[VladV]

I believe it was more optimal to make this check prior proceeding to VM data transfer, because there are VMs that can take significant time from inventoring and preparing guests stages to actual data transfer

I may have understood wrong but why wait for inventorying and preparing guest tasks to complete (which sometimes, as you said, can take a long time) just to find out that the VM is locked for FLR or Surebackup when you could check before this lengthy process and avoid losing time and production machine disturbance?

It will be helpful if in future versions, if this behavior can be altered to check availability before proceeding.

LE: I think this is true only for Surereplica and operations which involve opening replicas (even FLR from replica seems to block replication jobs).

Regards

[Vitaliy S.]

Yes, that's expected for VM replicas, since replication job is always accessing the latest restore point and then creates additional restore points in the snapshot tree. As to the order of procedures, then my point was that FLR operation could be already finished by the time Veeam backup server tries to create a snapshot. Anyway, thanks for the valid feedback.