One of my customers replaced the old Veeam environment with new gear. The HW was pretty simple designed:
- two HPE ProLiant
- per server two HPE D3610 enclosures with 6 TB disks
- ~ 5km between backup server and backup copy destination
One server was designed to act as the Veeam backup server and repository, and the second server was designed to act as the backup copy destination. Both servers were running Windows Server 2019 Standard. We planned to use Windows Deduplication and ReFS, but it turned out that we have to adjust the filesystem size to get Windows Dedup working. Windows Dedup supports filesystems up to 64 TB. Due to the 24x 6 TB disks, we had to create to logical volumes to stay under 64 TB usable capacity.
I created one Scale-Out Backup Repository per server and configured my backup jobs. At this point things got worse…
The backup ran fine, but as soon as the copy kicked in, the copy job failed. Error “No scale-out repository extents are available”.
Huh? Everything was fine. If no backup were running, the copy ran fine. Setting limits (throughput or concurrent tasks) doesn’t fixed it. So I opened a case at Veeam.
We had to take debug logs to come to a solution.
The support advised us to set a registry key:
Key: HKLM\SOFTWARE\Veeam\Veeam Backup and Replication\
Value Name: SobrForceExtentSpaceUpdate
Value Type: DWORD
Value Data: 1
After a restart of the Veeam services, the backup and copy job ran fine. No further issues.
This key is described in Veeam KB2282. The option was introduced with Backup & Replication 9.5 U2. The customer is running the v10.0.1.4854. The key forces Veeam to update free space information with the real values, and it subtracts the estimated sizes of all the tasks currently going to the selected extent.