
One of the most widely used platforms for delivering remote management, backup, and disaster recovery services is Veeam Cloud Connect paired with Veeam Service Provider Console, which together let service providers offer multiple data protection options. There is also Veeam Cloud Connect for Enterprise, which lets large organizations deliver these services internally to fit their business needs. In this post we will walk through a simple configuration change that improves throughput on the receiving side.
Initial Steps#
As always, you should start with the official documentation and check for new releases, such as the latest version of Veeam Service Provider Console, which is now at version 6. To download the ISO, sign in at Veeam.com and request it. The links below point to the release notes for the latest version, along with the product manuals:
- Release Notes Veeam Service Provider Console v6: https://www.veeam.com/vspc_6_0_release_notes_rn.pdf
- Manual Veeam Service Provider Console v6: https://helpcenter.veeam.com/docs/vac/provider_user/about.html?ver=60
- Manual Veeam Cloud Connect: https://helpcenter.veeam.com/docs/backup/cloud/cloud_overview.html?ver=110
Here we will look at a registry-level configuration, with a before-and-after comparison, on an environment running Veeam Cloud Connect and Veeam Service Provider Console on top of VMware v7.0U2, connected over the Internet in my lab.
Test Environment#
The setup is deliberately simple: I installed and configured a single virtual machine, in other words an All-In-One deployment, with the following versions:
- Veeam Cloud Connect v11
- Veeam Service Provider Console v6
- Veeam Backup & Replication 11a (tenant for VM backup)
Virtual machine resources for the VCC and VSPC AIO ( never use this for production)
- 8 vCPU
- 12 GB RAM
- OS disk 150 GB
- Repo disk ReFS 500 GB
Because this is an AIO configuration (for lab use), every role is deployed on the same console: Cloud Gateway, repository, and so on.
It is also worth stressing that this registry-level change applies equally to environments running Veeam Cloud Connect / vCloud Director and/or the vCloud Director plugin that provides access to the self-service portal from Veeam Enterprise Manager. It of course applies to Veeam Cloud Connect for Enterprise as well. In my case I only have 2 ESXi hosts and a vCenter.
Tests Before the Change#
In this step we will run two tests, taking Full backups of a single virtual machine and of multiple virtual machines, both pointing directly at the Veeam Cloud Connect repository managed through Veeam Service Provider Console.
The backup job configuration in my local Veeam Backup & Replication environment is left at its defaults; the only change is the repository, which in this case is the Veeam Cloud Connect one we configured earlier:


We then run the backups using the Active Full method for both jobs and wait for them to finish.

Job statistics for the multiple-virtual-machine backup

And if we look at the Veeam Cloud Connect console, we can see the statistics for the single-machine job:

And the statistics for the multiple-virtual-machine job:

Backup Task Review#
Based on the statistics above, we have the following:
| Job Name | Status | Start Time | End Time | Data Sent | Data Received | Processing Rate |
|---|---|---|---|---|---|---|
| DC → VCSP (Active Full) | Success | 07-10-2021 20:23 | 07-10-2021 20:30 | 34.4 KB | 7.8 GB | 60 MB/s |
| Multiple VMs → VCSP (Active Full) | Success | 07-10-2021 22:22 | 07-10-2021 22:50 | 227.4 KB | 49.6 GB | 69 MB/s |
For the single virtual machine, the Full backup took roughly 7 minutes at a “Processing Rate” of 60 MB/s. For the multiple-machine job, the Full backup took roughly 28 minutes at a “Processing Rate” of 69 MB/s:
| Job | Duration | Processing Rate |
|---|---|---|
| DC → VCSP (Active Full) | 6.44 minutes | 60 MB/s |
| Multiple VMs → VCSP (Active Full) | 28 minutes | 69 MB/s |
So, with the default Veeam Cloud Connect settings and moving the data over the Internet, roughly 57.4 GB in total, everything works correctly.
Registry Key Configuration#
At this stage we will look at how space quotas are allocated while a backup is being sent to a cloud repository in Veeam Cloud Connect. This also applies to backups running over vCloud Director with VCC.
Here is how the quota allocation behaves: VeeamAgent.exe reserves 512MB every 10 to 15 seconds to store data, and if that allocation is exceeded, it tries to reserve more space and writes “Storage size quota exceeded. Waiting for quota increase” to the log, which can create a bottleneck when data is transferred quickly.
For the kind of use cases and environments described above, there is a registry key you can add to change the logic of this mechanism. It must be applied under:
HKEY_LOCAL_MACHINE\SOFTWARE\Veeam\Veeam Backup and Replication
```text
And we add the **DWORD** value:
```text
CloudConnectQuotaAllocationModeThis registry key has 3 possible options:
- 0 = Default value and behavior of 512MB every 10 seconds.
- 1 = VeeamAgent.exe requests the space it needs without waiting the 10 seconds.
- 2 = Uses a combination of the two values above.
For our case we will set the key to 1, which looks like the following on the Veeam Cloud Connect server or the Veeam VBR server you are using with vCloud Director:

Then simply restart the " Veeam Backup Service" on the server that hosts the Veeam Cloud Connect or Veeam VBR with vCloud Director services.

Results#
After restarting the service and running the jobs again, forcing an Active Full for each of them, we can see the following:
A single virtual machine

Multiple virtual machines:

Statistics from the Veeam Cloud Connect console:


Reviewing the data after the change, the summary looks like this:
| Job Name | Status | Start Time | End Time | Data Sent | Data Received | Processing Rate |
|---|---|---|---|---|---|---|
| DC → VCSP (Active Full) | Success | 07-10-2021 21:47 | 07-10-2021 21:51 | 29.2 KB | 7.8 GB | 170 MB/s |
| Multiple VMs → VCSP (Active Full) | Success | 07-10-2021 22:58 | 07-10-2021 23:11 | 206.1 KB | 49.6 GB | 175 MB/s |
And the detail:
| Job | Duration | Processing Rate |
|---|---|---|
| DC → VCSP (Active Full) | 4.12 minutes | 170 MB/s |
| Multiple VMs → VCSP (Active Full) | 13 minutes | 175 MB/s |
Time and Processing Differences#
So, looking at the run and file-transfer times as well as the processing rate after applying the registry key, we saw a very noticeable performance improvement. For example:
- The initial “Processing Rate” for a single virtual machine before the change was 60 MB/s, and after applying the key it rose to 170 MB/s
- The initial “Processing Rate” for multiple virtual machines before the change was 69 MB/s, and after applying the key it rose to 175 MB/s
- The Full backup duration for a single virtual machine before the change was 6.44 minutes, and after applying the key it dropped to 4.12 minutes
- The Full backup duration for multiple virtual machines before the change was 28 minutes, and after applying the key it dropped to 13 minutes
In this case we saw throughput increase 2 to 3 times, and it could go even higher with dedicated infrastructure and an architecture purpose-built for this type of service.
Conclusion#
As we have seen, applying this registry key improves backup performance to repositories in Veeam Cloud Connect or with the vCloud Director integration. As always, it is well worth reviewing the use case for each environment you touch, particularly those with fast upload speeds or internal solutions.



