Priority file restores blocked by Items being locked from running session

[joebranca]

I am noticing that either the Veeam admin running FLR in the Veeam console, or users via BEM get an error when attempting to mount backup data for file recoveries. Such as "Some backup files are locked" (in Veeam B&R recovery console) or "Item is locked by running session <Job name>" (BEM).

This happens if the backup job is still running its merge operation at the end of the previous night's backup job. Is this expected behavior? If so, what do we do for high priority file restores if some of these jobs' merge operations are taking up most of the following day to complete?

Edit: if it is relevant, one of the jobs in question has about 14 Windows VMs, with a total of just under 3TB source data. It writes to a WIndows 2016 storage server scale out repo with 3 repo volumes, and configured to write per-VM backup files. Do any of these factor into the amount of time the merge operation takes, if our only solution is to shrink the merge window?

[HannesK]

Hello,
yes, that's expected behavior. The workaround is to use a backup-mode that avoids long locking of the chain. And using ReFS for faster merges.

Best regards,
Hannes