vTPM NBD vs. direct SAN

[Max_IT]

Moderator split from post453819.html#p453819

Hi,
This relates to vTPM / which forces encryption / which then prevents Veeam being able to use storage snapshots and in our case 25GbE access to the san. We are now pulling these backups over the vmware management network (1GbE)

We are struggling now we have moved some large (5TB database servers) to Server 2022. 2022 and W11 both require a vTPM(OS requirement) issued from VC. This has blown out our backups to no end with the nightly (synthetic full) now taking about 8 hours (up from 15 mins on the non encrypted 2012) and an active full being close to 15 hours (up from 58mins on 2012) .

Does Veeam have a solution for this longer term as this is going to get more and more unmanageable as we move to VMs that require vTPM.

[HannesK]

Hello,
and welcome to the forums.

Only HotAdd and NBD are supported with encrypted VMs. That's a VMware requirement and we cannot work around that.

Best regards,
Hannes
PS: I have a Windows 2022 without vTPM in my lab.

[Origin 2000]

Windows 2022 doesnt need a vTPM.

[myamada288]

Hi
We are experiencing the same challenge in our environment.

We understand that Veeam previously explained that only HotAdd and NBD transport modes are supported for encrypted VMs due to VMware requirements. However, the industry situation has changed significantly since then.

With the growing adoption of Windows 11, Windows Server 2022, and Windows Server 2025, vTPM is becoming a standard security requirement rather than a special use case. As a result, more and more VMs are being encrypted by default.

For large production workloads, the inability to use Direct SAN Access or storage snapshot based processing can significantly increase backup windows and infrastructure load.

We would greatly appreciate if Veeam could continue working with VMware and investigate future enhancements that would improve backup performance for encrypted VMs.

The impact of this limitation is becoming increasingly significant as organizations adopt modern OS and security standards.

[david.domask]

Hi myamada288, welcome to the forums.

Noted on the request, but as noted previously this is a limitation on how the VDDK library works with encrypted virtual machines. Current design of VDDK requires that the proxy be encrypted as well, and for DirectSAN usually the proxy is physical, so not sure that this would be feasible with current VDDK design. It would be best to pursue the request with VMware as well, as it would be a pretty substantial effort from their side I suppose.

Question though, is HotAdd not performant in your environment? Hotadd is often quite competitive / out-performs DirectSAN access; there is a bit of a myth that DirectSAN is always fastest, but that has not been the case for a long time, so I recommend testing if you haven't already as HotAdd very likely can meet your backup window needs. Remember that hotadd scales horizontally, not vertically, that is, add more hotadd proxies instead of making one monolithic hotadd proxy.

[myamada288]

Thank you for your explanation and for the HotAdd recommendation.

We understand that this limitation originates from the current VDDK design and that any solution would likely require cooperation with VMware/Broadcom.

However, HotAdd is not a practical alternative in our environment.

As shared in my previous post in July, our Veeam environments currently protect approximately 300 VMs respectively. In addition, the largest virtual machine contains approximately 150 TB of storage.

Our backup proxy servers are deployed on dedicated physical servers connected directly to the SAN infrastructure. Due to the size of the workloads and our backup architecture, Direct SAN Access remains a critical transport mode for meeting our backup window requirements.

While HotAdd may perform well in many environments, we do not expect it to provide comparable performance in our specific use case, particularly for very large encrypted virtual machines.

We understand that this is currently a VDDK limitation. However, with vTPM becoming increasingly common for Windows 11 and Windows Server 2025 workloads, we expect more enterprise customers to encounter the same challenge.

Therefore, we would greatly appreciate it if Veeam could continue discussions with VMware/Broadcom and evaluate whether support for encrypted virtual machines with Direct SAN Access could become possible in the future.

Thank you again for considering this request.

[david.domask]

Understood on your request myamada288, we won't be able to make any promises here however.

On this though:

While HotAdd may perform well in many environments, we do not expect it to provide comparable performance in our specific use case, particularly for very large encrypted virtual machines.

Do I understand correctly that you have not tested it? I would still test it; as noted, HotAdd can very much so be performant compared to DirectSAN / BfSS. What kind of speeds are you getting per-disk on the 150 TB VM and with what transport mode?

[HannesK]

Hello,
do you have the option for backup from storage snapshot (BfSS)? I'm asking because we made some improvements for that scenario in V13

And agree with David: DirectSAN is rarely faster than HotAdd (assuming that network is not the bottleneck).

Best regards
Hannes

[myamada288]

Thank you for the additional comments and meaningful suggestions.

To clarify our environment, HotAdd is currently not an available option for us because backup proxies is deployed as dedicated physical servers connected directly to the SAN infrastructure. Our backup architecture was designed around Direct SAN Access from the beginning.

Regarding Backup from Storage Snapshots (BfSS), we use IBM FlashSystem storage and the feature is technically available in our environment. However, due to storage capacity considerations and the way the current system was designed, BfSS is not a practical option for us. Our current backup architecture was intentionally optimized for storage efficiency, and changing that design is not feasible at this stage.

Our environment was refreshed only last year, and we expect to continue using the current architecture for another 4-5 years before the next major refresh cycle. During that period, we expect the number of vTPM-enabled and encrypted VMs to increase as modern security requirements become more widely adopted.
For this reason, we would be very interested in seeing support for Direct SAN Access (or a similarly efficient SAN-based transport method) for encrypted VMs in the future.
Sincerely regards.
Regarding the 150 TB VM, it is not currently encrypted, so it is not yet impacted by this limitation. However, it is expected to become a vTPM candidate in the future.
We do have other vTPM-enabled VMs that are currently being processed through network-based transport due to encryption. I will gather some actual performance data from those workloads and share the results in a follow-up post.

[david.domask]

Hi myamada288,

Understood, however, as noted previously it's a VMware limitation, so the change will need to come from VMware.

I'm also not quite sure how storage considerations come into play by switching to BfSS -- can you explain a bit more? Changing the transport mode only affects how we fetch the data, it does not impact the backup chains.

As we really cannot comment on future changes from VMware, I advise consider implementing additional hotadd proxies for only the large VMs, and also testing with BfSS, as either solution ought work.

(Note: Regarding NBD, keep in mind that NBD has limits on max transfer per-disk, so depending on how many disks the VMs have, NBD may be feasible but there is an expected cap on performance)

[myamada288]

Thank you for your suggestions.

After reviewing our environment, I would like to provide some additional information:

HotAdd is not an option in our environment, as our Veeam proxy servers are deployed on physical servers rather than virtual machines.

Backup from Storage Snapshots (BfSS/RfSS) is technically supported by our IBM FlashSystem storage. However, due to the very large storage capacity involved and our current design, which was optimized for storage efficiency, implementing BfSS is not feasible in the existing environment. Changing this design is also not possible at this time.

Our backup environment was refreshed only last year, and the next infrastructure refresh is not expected for another 4-5 years. Therefore, we need to continue operating within the constraints of the current architecture.

Given these limitations, encrypted VMs are currently forced to use NBD transport, which results in significantly lower backup performance compared to Direct SAN Access.

For this reason, we would appreciate it if Veeam could re-evaluate the possibility of supporting Direct SAN Access for encrypted VMs in the future, or consider alternative approaches that would allow customers with large-scale environments to avoid the current performance limitations.　　
Given these limitations, we would appreciate it if Veeam could consider this enhancement in the future. Thank you for taking the time to review this feedback.
Sincerely regards