Regkey of the month: February

Full proxy control: EnableSameHostHotaddMode

This setting is a useful tool that helps you optimize and control the Virtual Appliance or HotAdd transport mode. This can be particularly useful in complex or hyper-converged infrastructures (HCI) to take control of how data flows.

 

What is EnableSameHostHotaddMode?

When Veeam uses HotAdd mode, the virtual disks of a source VM are directly attached to a Veeam Backup Proxy that runs as a VM itself. By default, the Veeam scheduler will attempt to find the most suitable proxy based on load and connectivity. Logically this is a proxy on the same underlying host as the machine you're backing up.

The registry key EnableSameHostHotaddMode forces Veeam to preferentially use a proxy running on the same ESXi host as the VM being backed up. This localizes backup traffic within the host, reducing network load and increasing speed. So there's less room for the Veeam scheduler which proxy will take and perform the task.

Why would you use this?

There's logic performed by Veeam to assign the most optimal Proxy resource. Shouldn't we just leave it to that ? The main reason to use this key is to prevent the infamous “VM stun” or temporary unavailability of virtual machines.
 

NFS Datastores (HCI): In environments such as Nutanix or Cisco HyperFlex, which use the NFS protocol, a HotAdd operation where the proxy is on a different host than the VM can cause file locking (LCK files) issues. This can result in a VM becoming unresponsive for several minutes while removing a snapshot from the backup action.
 

Network Optimization: By sending data directly from the host's VMkernel to the local proxy, you avoid having backup data travel across the physical network between hosts.
 

Storage Bottlenecks: In environments with limited bandwidth between hosts, keeping traffic and be able to force this local, helps ensure overall cluster performance.

Creating the key and the different values

To make optimal use of this feature, the first requirement is to install a Veeam Backup Proxy on each ESXi host in the cluster where the VMs to be protected are located. This can be a Linux or Windows based proxy role.

Setting the Registry Key

Configure the following registry key on the Veeam Backup & Replication server:

•  Path: HKLM\SOFTWARE\Veeam\Veeam Backup and Replication
•  Name: EnableSameHostHotaddMode
•  Type: DWORD (32-bit) This key can have different values (0,1 or 2)

Depending on how strictly you want to enforce the rule,  you can set the value on 0,1 or 2
 

0 (Default): Disabled. Veeam uses any available proxy, regardless of whether it is local or remote.

1 (Preference): Veeam prefers the local proxy. If the local proxy is busy, Veeam waits for availability. However, if the local proxy is completely unavailable, Veeam falls back to a HotAdd proxy on another host. Important remak: this can still cause a stun with NFS.

2 (Strict mode): Veeam enforces the use of the local proxy. If the local proxy is busy, Veeam waits. If the proxy is unavailable, Veeam switches to Network Mode (NBD) instead of using a HotAdd proxy on another host. This completely minimizes the risk of snapshot stuns.

Gerneral remark: After modifying or adding the key, the Veeam Backup Service must be restarted, or you must wait 15 minutes for the automatic scan to pick up the change.
 

Real-world examples

Must have for Cisco HyperFlex optimization

In a Cisco HyperFlex environment, it is recommended to set the value to 2. Because HyperFlex datastores operate via NFS, this strict setting prevents Veeam from choosing a proxy on another host that would temporarily take ownership of the VM files via the LCK file, which can cause application interruptions.

Getting maximum performance in a 1GbE cluster

An administrator notices that backups are slow because the 1GbE management network between hosts is becoming overloaded by HotAdd traffic. By placing a proxy on each host and setting the value to 1, most data remains within the host. Only in cases of extreme necessity (if a local proxy fails) does the data still travel over the network, drastically reducing the daily load.

Stability preferred over speed

In an environment with highly sensitive SQL servers on NFS storage, the administrator should choose value 2. When an ESXi host undergoes maintenance and the local proxy is down, the administrator prefers that the backup runs slower via Network Mode (NBD) than to risk the SQL server “freezing” during snapshot removal.

To conclude

The EnableSameHostHotaddMode registry key is an interesting setting for any backup administrator working with NFS-based storage or HCI solutions. Although implementing a proxy on each host requires more management, the benefits of a more stable infrastructure and faster backups. From my perspective more advantages than drawbacks.

 

Regkey of the month: January

Optimizing Veeam SQL Transaction Log Backups with SqlTempLogPath

First of all, happy new year !! Also in 2026 we continue with our regkey of the month series. 

Veeam Backup & Replication performs SQL Server transaction log backups by temporarily staging log data on disk before transferring it to the backup repository. In many environments, this staging location becomes a hidden bottleneck—causing failed jobs, disk-space exhaustion on system drives, or unnecessary performance degradation.

 

In this episode of "regkey of the month", I'll provide you with some more information of the hidden gem: SqlTempLogPath

We will cover internal behavior, real-world use cases, performance considerations, cluster implications, failure modes, and best-practice deployment guidance. 

For Veeam Backup & Replication v12 and later, the configuration of the SQL temp log path is managed using the following specific registry key:

• Path: HKLM\SOFTWARE\Veeam\Veeam Backup and Replication
• Name: SqlTempLogPath (REG_SZ (string))
• Default Value: Not set

SqlTempLogPath controls the temporary disk location where Veeam stores SQL Server transaction log backup files during log backup operations.

These files are staging artifacts—they exist only briefly:

1. SQL Server writes the transaction log backup
2. Veeam processes and transfers it to the backup repository
3. The temporary file is removed

By default, Veeam automatically chooses a location. In many environments, that default behavior is sub-optimal.

Default Behavior, when the key is not set

When SqlTempLogPath is not present, Veeam follows this logic:

1. Enumerates all local volumes on the SQL Server

2. Selects the volume with the largest amount of free space

3. Uses that volume as the staging location

4. Writes the selected path back into the registry

This means the registry value may appear even if you never created it manually.

Implication

If your SQL Server has a large but slow data volume or a system drive that temporarily has the most free space, Veeam may choose a non-optimal staging location that persists indefinitely.

Reasons why you should check this:

C: Drive Exhaustion

Many SQL servers are deployed with:

• Small system partitions
• Strict OS disk usage limits

Transaction log backups can spike unexpectedly and fill the drive, especially on environments with:

• High-write Online Transaction Processing (OLTP) systems
• Systems with delayed log truncation
• Long backup intervals (large build-up of logs)

Check it when you see performance Bottlenecks

SQL log backups are write-intensive and latency-sensitive.

If Veeam stages logs on:

• Slow HDD volumes
• Shared data LUNs
• Heavily contended disks

You may see:

• More time needed for the log backup
• Increased SQL I/O wait times
• Backup jobs overlapping production timeframe

Supported deployments

Know that this regkey can be used in:

Veeam Backup & Replication (VM-level SQL backups), Veeam Agent for Windows (SQL log backups)
Cluster-Aware SQL backups, AlwaysOn Availability Groups

Some personal guidelines:

Choose your path that is:

• Local (not a network share)
• Fast (SSD or high-performance SAN)
• Large enough to absorb log spikes
• Consistent across reboots (no random driveletter assignmentsn typical on USB drives)

Do not use: UNC paths, temporary removable storage (USB drives,...), volumes managed by external cleanup tools. I personal alway try to avoid the C-drive, when full the OS will hang and the whole machine will become unresponsive. 

Interesting to know: 

When the path becomes unavailable or read-only, Veeam will detect this and 'fallback' ont the new most suitable volume. The value of the registry will then be overwritten. To find out which location is used, you can check the logfiles of the job. These logfile is typical located at: 

Regkey of the Month: December

Advanced Object Storage I/O Optimization: Fine-Tuning Veeam Block Generation

Within Veeam Backup & Replication (VBR), achieving effective immutability while maintaining operational efficiency relies heavily on an internal mechanism known as block generation.

What is Block Generation and why is it used?

Block Generation is defined as a time period during which all data blocks contained within backup files—both full and incremental—are assigned the same immutability period.

The core purpose of implementing Block Generation is to reduce the number of requests (API calls) to the object storage repository, thereby saving network traffic and significantly reducing costs associated with cloud providers who charge for these I/O operations (S3 operations).

This mechanism functions as internal background optimization, akin to filesystem housekeeping for immutability blocks,. Since Veeam leverages an incremental forever approach, data objects in the cloud naturally belong to newer restore points over time,. Without Block Generation, Veeam would be forced to update the immutability value daily for the majority of objects (approximately 97% of a full backup) to extend their protection by one day, resulting in excessively I/O intensive and costly operations,. Block Generation serves as a mathematical prediction to set a slightly longer immutability date for blocks expected to be needed longer, thus preventing frequent updates to the immutability value.

The advantage of adding days and why the default values

The advantage of this process is purely operational efficiency: optimizing I/O and reducing cloud costs. 

It is important to understand that block generation does NOT add additional immutable days to your restore points or affect the guaranteed retention configured in the VBR job. 

The proces only marks some blocks as immutable for a longer period to optimize storage I/O in the background. The actual added immutability for a given block ranges between 0 and 30 days, depending on the timing of the backup run and the target object storage.

The block generation setting is applied automatically and does not require explicit configuration during repository setup. The default duration of the block generation period varies based on the underlying object storage type:

• 30 days are automatically added for Amazon S3 object storage (AWS), IBM Cloud object storage, and 11:11 Cloud Object Storage,.
• 10 days are automatically added for all other types of object storage repositories. (eg. Wasabi, Cubixion,...)

Consequently, the "exact" immutable time for a data block is the configured immutability time plus the block generation days, depending on the service provider. For instance, a 30-day immutability period would result in the data blocks initially having an immutability set for 30 days plus 10 days of block generation.

Influencing this behavior via a registry key

Although Veeam strongly advises against modifying this internal optimization mechanism,, the default block generation period can be influenced using a specific registry value.

For Veeam Backup & Replication v12 and later, the configuration is managed using the following specific registry key:

• Path: HKLM\SOFTWARE\Veeam\Veeam Backup and Replication
• Name: ObjectStorageImmutabilityGenerationDays (DWORD (32-bit))
• Value: the desired number of days, starting at 1

Note that setting the value to 0 is useless, as 1 is the lowest value that makes sense. 

Important: modifying this key does not require a reboot of the VBR server or a restart of any services to take effect. The previous key name, SOBRCapacityImmutabilityGenerationDays (used in VBR v11), is now invalid in VBR v12.

What is the effect wen this registry key is modified ?

New Blocks/Chains: New data blocks written to the object storage will utilize the newly defined, reduced block generation value for calculating their immutability expiration date.

Existing Backup Chains: Veeam is capable of extending the immutability expiration for all data blocks across the entire backup chain (including both active and inactive parts) and assigning them to a new generation to maintain backup consistency,. However, if blocks were previously marked with a longer immutability period based on the old, higher block generation setting, they will remain marked according to the original, longer period and will only expire when that specific date is reached.

Use Case and Associated Risks

A typical motivation for wishing to adjust the block generation days stems from a misconception that this value unnecessarily extends the actual immutable retention period specified in the job settings,. Veeam confirms that block generation is strictly an internal optimization that prevents the need to update a huge amount of objects daily, not a method to extend restore point availability.

Use Case for Reduction

A justifiable, but highly niche, use case for lowering this value might apply to a a big enterprise or service provider utilizing private, on-premises S3-compatible storage where no monetary API call charges are incurred. In this environment, minimizing the block generation value might be seen as a way to slightly tighten the lifecycle management and align the object expiration more closely with the configured immutability window, despite eliminating the primary I/O benefit. 

Significant risks of this reduction

Veeam strongly advises against manipulating this key because the inherent risks generally outweigh any perceived benefits.

Reducing  ObjectStorageImmutabilityGenerationDays dramatically increases the number of necessary API calls/IO operations,. If this change is applied to an environment using a public cloud provider (like AWS or Azure) that charges per S3 operation, the primary consequence is an immediate and significant surge in API costs. Furthermore, this intensified frequency of IO operations could potentially overload the object storage or result in the cloud provider implementing throttling, leading to unpredictable side-effects impacting backup and retention processing. Be carefull with applying this to not overload your local object storage with an API-call storm. See alsy my previous post on optimizing lightweight Object Storage API load.

In essence, tampering with block generation undermines the sophisticated background optimizations Veeam designed to reduce IO demand and save operational expenditure, whether in the cloud or on-premises. So you've been warned ;-)