Direct SAN is expected to be 2-4x slower than our own HotAdd processing at backup and a magnitude slower on restore.
The reason for this is that for Direct SAN we as backup vendor do not understand the disk format and so we need to use the VMware VDDK kit for reading. It performs the task in a syncronous way with a queue depth of 1. So there is not much the storage controller can optimize. With HotAdd mode we completely go around the VMware libraries and read natively from the storage with a higher queue depth. Which allows the storage to optimize the backup speed (specifically when under more load or random IO processing is needed for incremental backup).
For VMware the backup the "Local 1MB" block size is the optimal one in case of performance vs. storage space for incrementals.
The reason for this is that for Direct SAN we as backup vendor do not understand the disk format and so we need to use the VMware VDDK kit for reading. It performs the task in a syncronous way with a queue depth of 1. So there is not much the storage controller can optimize. With HotAdd mode we completely go around the VMware libraries and read natively from the storage with a higher queue depth. Which allows the storage to optimize the backup speed (specifically when under more load or random IO processing is needed for incremental backup).
For VMware the backup the "Local 1MB" block size is the optimal one in case of performance vs. storage space for incrementals.
Statistics: Posted by Andreas Neufert — May 20, 2026 2:01 pm
