In addition to my previous blog post, I have explored further innovations in the new Veeam Backup for M365 v8 Technical Preview 2. The environment remains unchanged, I am using a CDX tenant as the source data and a lab environment hosted in Azure.
Configuration of a Proxy Pool:
In total, I am adding four Windows servers as proxy servers to the environment. Following Veeam’s recommendation, I am using DNS names listed in the hosts file of the systems (see previous post).
After successfully adding the four Windows proxies, a pool can be created. Here, various existing proxies are simply added to a pool:
No further settings are possible; the software handles this in the background.
Configuration of an Immutable Repository:
With the new version, it is now possible to separate the retention period of the backups from the immutability period:
As already known from VBR, a backup job can now, for example, secure data for 30 days, but the data is protected with immutability for only 14 days. In this example, an S3 repository from Wasabi was used.
Configuration of a Backup Job:
The backup job is created as usual, and it is now possible to target a backup repository through a proxy pool:
Performance Tests:
I backed up the CDX tenant through two sequential full backup jobs, once using a single proxy and once using the proxy pool:
All settings and configurations of the proxies (virtual servers) are identical, and the job configuration is the same in both cases.
Performance Single Proxy:
Performance Proxy Pool:
In both cases, the source (CDX tenant) is identified as the bottleneck.
Conclusion: Currently, no performance multiplication can be observed; however, I will repeat the tests with another, alternative tenant and provide the results later.
„Flapping“ – One day later:
One day after the aforementioned tests, I restarted the temporarily shut down environment to conduct further tests. The jobs no longer run as the following error message is displayed:
The CDX tenant is fully online, and all passwords are valid. Since the repositories are Wasabi buckets, they are also online and accessible, including from the respective Veeam server. The Wasabi credentials have also been verified.
The three backup repositories I have now set up for the tests repeatedly „flap“ from online to offline, although a rescan runs successfully, indicating that the configuration is valid.
Conclusion: This behavior has been reported to Veeam for further error analysis.