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 ;-)

Regkey of the Month: November

Changing the order of Guest Processing Methods in Veeam VBR

Why and How (vSphere & Hyper-V)

When protecting virtual machines at scale, the way your backup software communicates with the guest OS matters—especially in secure or isolated environments. In many organizations, VMs live in DMZs, private networks, or tightly firewalled segments where traditional RPC-based communication simply isn’t allowed.

In these cases, backups may fail not because the VM is unreachable, but because the guest-processing traffic is blocked. To overcome this, Veeam offers networkless guest processing methods for both vSphere and Hyper-V that use hypervisor channels instead of direct network access.

Even better—you can change the order in which Veeam attempts these methods, ensuring it always tries the most appropriate connection type first.

In this post, we’ll explore why you might want to change that order and how to configure it for both VMware vSphere and Microsoft Hyper-V environments.

 

Why Change the Guest Processing Connection Order?

By default, Veeam uses the following logic:

1. Try network communication first (RPC / Admin$).

2. If that fails, fall back to a networkless hypervisor-based method.

This works well in open networks, but not in cases such as:

• VMs in DMZ segments
• Isolated networks with zero direct connectivity
• Service provider or multi-tenant environments
• Highly restricted firewalls
• Scenarios where you never want guest network access attempted

In these situations, repeatedly attempting RPC adds needless delays, logging noise, and potential security concerns. For a cleaner and more predictable process, you can instruct Veeam VBR to try:

• VIX first in vSphere

• PowerShell Direct first in Hyper-V

Let’s walk through how.

Networkless Guest Processing in vSphere

In VMware environments, Veeam can use VMware VIX / vSphere Web Services to push runtime components into the VM without requiring network connectivity. This works through VMware Tools and is especially useful for:

• Windows VMs without reachable Admin$ shares

• Firewalled or isolated network segments

• Service provider environments where guest traffic is restricted

Forcing VIX to be Tried First

To make Veeam attempt VIX before RPC, create this registry key on the Veeam Backup & Replication server:

• Path: HKLM\SOFTWARE\Veeam\Veeam Backup and Replication\
• Name: InverseVssProtocolOrder (DWORD (32-bit))
• Value: 0 = Try RPC first, then VIX (default) / 1 = Try VIX first, then RPC

You do not need to restart services—changes apply on the next job run.

This simple adjustment ensures that Veeam uses vSphere’s built-in communication channels first, improving reliability in locked-down environments.

Networkless Guest Processing in Hyper-V

In Hyper-V environments, Veeam uses PowerShell Direct for networkless communication. This method works between the host and Windows guest as long as Integration Services are running—even if the VM has zero network access.

This is extremely helpful for:

• Secure VMs with no NIC
• Isolated Hyper-V clusters
• Environments where firewall rules block all RPC traffic

Forcing PowerShell Direct to Be Tried First

To prioritize PowerShell Direct over RPC, create:

Registry Path:

• Path: HKLM\SOFTWARE\Veeam\Veeam Backup and Replication\
• Name: HvVssPowerShellDirectPriorityOverNetwork (DWORD (32-bit))
• Value: 0 = Try RPC first, then PowerShell Direct (default) / 1 = Try PowerShell Direct first, then RPC

Again, Veeam services do not need to be restarted. 

Conclusion

Changing Veeam’s guest processing connection order is a simple but effective way to streamline backups in isolated or heavily secured environments. Whether you run vSphere or Hyper-V, reordering VIX or PowerShell Direct to be attempted first can significantly improve backup reliability and reduce failed RPC attempts.

For anyone running workloads in DMZs, air-gapped networks, or multi-tenant platforms, this tweak is not just useful—it’s a must-have.