- Posts: 23
- Liked: never
- Joined: Oct 28, 2015 9:36 pm
- Full Name: Joe Brancaleone
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?
- Veeam Software
- Posts: 4458
- Liked: 560 times
- Joined: Sep 01, 2014 11:46 am
- Location: Austria
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.
Users browsing this forum: Bing [Bot], Google [Bot] and 31 guests