Regkey of the Month: September

Fine-Tuning Performance for On-Prem Object Storage

Beyond the GUI: The Art of Veeam Fine-Tuning

While Veeam Backup & Replication (VBR) is renowned for its robust and intuitive graphical user interface (GUI), true mastery of the platform goes beyond the standard configuration wizards. 

The difference between a functional Veeam deployment and a truly optimized one frequently lies in the judicious application of advanced settings, many of which are only accessible via the Windows registry. 

One such area of critical importance in modern data protection is the use of Scale-Out Backup Repositories (SOBR) with a Capacity Tier for offloading backup data to low-cost object storage. 
The SOBR architecture is a cornerstone of Veeam's strategy for efficient, long-term data retention, offering a seamless way to leverage both on-premises performance storage and external cloudstorage solutiuon and/or local object storage. However, the performance dynamics of this feature are not uniform across all environments. Public cloud providers, such as Amazon S3, are engineered for massive parallelism and can handle thousands of concurrent connections. In contrast, on-premises S3-compatible appliances, while powerful, operate on finite hardware resources. We've experienced this ourselves with experimenting and tuning devices who offer local S3 compatible storage.

The default Veeam configuration is optimized to take full advantage of the public cloud's scalability, but this can inadvertently overwhelm certain on-prem systems, leading to performance bottlenecks and job failures.

 

A registry key that is vital for stabilizing and optimizing VBR in these hybrid environments: S3ConcurrentTaskLimit. 

This key provides an essential mechanism to throttle S3 interactions, ensuring that the backup infrastructure remains performant and stable, even when interfacing with systems that have different resource limitations than those found in the public cloud.

Demystifying the S3ConcurrentTaskLimit Registry Key

The S3ConcurrentTaskLimit is a powerful, but not widely documented, configuration parameter within Veeam Backup & Replication. Its function is to control the maximum number of simultaneous S3 connections that a single Veeam worker process can open to an object storage repository. This is not a global setting for the entire Veeam server but a specific throttle that governs the behavior of each individual task.

 

The key is a DWORD (32-bit) value located in the primary Veeam registry path on the backup server: 

• Path: HKEY_LOCAL_MACHINE\SOFTWARE\Veeam\Veeam Backup and Replication  
• Name: S3ConcurrentTaskLimit (DWORD)  
• Default Value: 64 (decimal) 

It is crucial to understand that this key is designed as a control mechanism to reduce performance in specific scenarios, not to blindly increase it. The default value of 64 is a high-water mark, a reflection of the architecture's design to leverage the near-infinite scalability of public cloud providers. 

 

This key's purpose is to prevent a backup infrastructure from overpowering an object storage device that cannot handle the default level of parallel load. 

 

A common misunderstanding arises from the name of the key itself. A user might assume that S3ConcurrentTaskLimit limits the number of offload tasks, but its effect is multiplicative. 

The total number of parallel S3 operations is a product of two variables: the number of available repository task slots and the value of this registry key. 

 

The calculation is expressed as:

 

AvailableRepositoryTaskSlots × S3ConcurrentTaskLimi t= Max used S3 operations in parallel

 

For example, with a default value of 64, an offload job with eight available repository tasks could theoretically initiate up to 512 parallel S3 connections (8 x 64 = 512). 

 

This is a high level of parallelism that public cloud services are built to handle, but it can be a recipe for disaster for on-premises systems with limited CPU and I/O resources.

 

Using the key to overcome On-Prem Object Storage Bottlenecks

The most compelling use case for the S3ConcurrentTaskLimit registry key is in environments where a Veeam SOBR with a Capacity Tier is configured to use an on-premises S3-compatible storage appliance. The problem often manifests when an administrator attempts to offload a large volume of data, such as a major synthetic full backup or a new, extensive backup chain.

When a Veeam offload job initiates, it attempts to use as many concurrent S3 connections as the default S3ConcurrentTaskLimit allows, multiplied by the number of available repository tasks. 

In an on-premises scenario, this sudden, high-intensity workload can quickly exhaust the storage appliance's processing capacity. The appliance's CPU utilization may spike to 95% or more, leading to a cascading failure of symptoms: offload jobs run at a fraction of their expected speed, data transfer rates plummet, and in some cases, the jobs may time out and fail entirely. We had this experience on QNAP QuObjects that drowned the complete system altough an AMD Ryzen CPU was present in the NAS.

The role of the S3ConcurrentTaskLimit is to prevent this overload. By reducing the value from the default 64 to a more conservative number, such as 8 or 16, the administrator can effectively cap the number of concurrent S3 connections per worker process. 

This change throttles the offload operation, allowing the on-premises storage appliance to process data at a stable and predictable pace without becoming overwhelmed. By providing this parameter, Veeam acknowledges the diversity of IT infrastructures and offers a tailored solution to a specific and common pain point.

Remarks

Reboot the machine after setting the registry key to another value.

Use for On-Premises Object Storage: This registry key is a vital asset when using an S3-compatible storage appliance on-premises that exhibits high CPU utilization, connection timeouts, or degraded performance during large-scale offload or restore operations.

 

Do Not Use for Public Cloud Storage: Public cloud providers like AWS S3 or Azure Blob are engineered for high concurrency and massive parallelism. Applying this key in such environments would unnecessarily limit performance and could degrade offload and restore speeds without providing any stability benefits.

Always Verify: After making any registry changes, it is essential to monitor job logs and performance metrics on both the Veeam server and the storage appliance to confirm that the changes have had the desired effect. The *.gate.log files are an invaluable resource for this verification process.

To verify the change, you can checks the .gate.log file associated with the SOBR offload job, located at %programdata%/Veeam/Backup/SOBR_Offload_name-of-sobr/VMname/*.gate.log and confirm that the new S3ConcurrentTaskLimit value is reflected in the logs

 

 

Regkey of the Month: August

Controlling the SQL Log Backup Temp Folder

By default, Veeam picks the local disk with the most free space (often C:) and uses a folder like \Veeam\Backup\SqlLogBackup or C:\ProgramData\Veeam\Endpoint\SqlLogBackup to store the native log backup files before copying them to the backup repository

These files are Veeam’s own “.BAK” format (not native SQL .BAK) and are deleted after shipping. However, on heavily-loaded SQL servers this can quickly fill the drive. To prevent this, Veeam provides a registry setting named SqlTempLogPath that lets administrators manually specify an alternate folder for the log backups. 

Understanding and using this key ensures log backups don’t crash your SQL server due to a full disk.

The SqlTempLogPath registry value (a REG_SZ string) tells Veeam where to stage SQL transaction log backups on the SQL Server itself. 

Its behavior varies by scenario:

Image-level (VM) backup by Veeam B&R

On the first run of a transaction log child job, Veeam scans all volumes on the SQL VM, picks the one with most free space, and writes that path into the SqlTempLogPath value. To override this default, create or update the registry entry on the SQL host

• Path: HKEY_LOCAL_MACHINE\SOFTWARE\Veeam\Veeam Backup and Replication  
• Name: SqlTempLogPath (String)  
• Value: <full desired folder path>  (no trailing “\”) 

For example, to point logs to D:\SqlLogs you could run (as Administrator) the following PowerShell command:

        New-ItemProperty -Path "HKLM:\SOFTWARE\Veeam\Veeam Backup and Replication" `
        -Name "SqlTempLogPath" -Value "D:\SqlLogs" -PropertyType String

Veeam Agent (Standalone or managed) backups

For machine-level backups using Veeam Agent on Windows, the default temp folder is %ProgramData%\Veeam\Endpoint\SqlLogBackup\. You can override this by setting:

• Path: HKEY_LOCAL_MACHINE\SOFTWARE\Veeam\Veeam EndPoint Backup  
• Name: SqlTempLogPath (String)  
• Value: <desired folder path>  (no trailing backslash)

This registry key goes on the SQL server (the machine running the Agent backup job). (If the job is managed by VBR, the VBR-style path under HKLM\SOFTWARE\Veeam\Veeam Backup and Replication is also acceptable.) 

If the SqlTempLogPath is set under the Endpoint Backup key and later becomes invalid, the log backup will fail with an error like “Cannot create folder… Invalid folder path” and the missing intervals will be flagged. 

Unlike the VM case, Veeam Agent does not automatically re-pick a drive in that situation; you must correct or remove the key and restart the job.

Cluster-aware backups

For SQL Server on a failover cluster managed by Veeam Agent (VBR-managed AG/FCI), Veeam first checks if the HKLM\SOFTWARE\Veeam\Veeam Backup and Replication key exists. 

If it does not, Veeam uses a fixed default folder (C:\ProgramData\Veeam\Backup\SqlLogBackup) on whichever node is active. 

If the key exists but SqlTempLogPath is missing or invalid, Veeam picks the largest drive and then records it in SqlTempLogPath for that node. 

To manually set a cluster node’s path, create SqlTempLogPath under HKLM\SOFTWARE\Veeam\Veeam Backup and Replication on each node (no trailing slashes). 

Note that if you point the path to a cluster disk, a failover might render it invalid: Veeam will then choose a new path and update the registry.

Important

Restart the job 

After creating or changing SqlTempLogPath, disable and re-enable (or restart) the SQL backup job. This forces Veeam’s log-shipping process to reload the new setting.

Disk space sizing

Plan ahead – you need enough space to hold the largest log backup between full backups. If you do frequent log backups, the needed temp space is roughly the size of one full backup cycle’s worth of logs (for example, if you back up every 20 minutes and keep a weekly full, you might need tens of GB). The more frequent log jobs = smaller native log chunks

Permissions

Ensure the chosen path is writable by the Veeam services (usually the local System or VeeamService account). Otherwise Veeam will fail to write the logs.

Conclusion

The SqlTempLogPath registry key is a powerful knob for Veeam administrators who need to control where SQL transaction log backups are staged. By default, Veeam chooses the largest local volume, which can be problematic on busy SQL servers. Manually setting SqlTempLogPath lets you relocate the temp files to any local drive or folder with adequate space.

Regkey of the month: JULY

It's already the third episode and summer is coming, so we're generous and bring you a combo of 2 interesting regkeys for Veeam Backup and Replication.

VTHScanEmail & VTHScanExclusions

 

In case you didn't know: VTH stands for Veeam's Threat Hunter technology.

Why Your Backups Need a Threat Hunter (and why Veeam Delivers) 

In today’s cyber battleground, relying solely on production environment security is like wearing half a suit of armor. Existing tools might miss stealthy threats, third-party scanners drain budgets and resources, and performance bottlenecks slow critical recoveries. 

Let's look at VTH: a zero-cost, zero-install second opinion embedded directly in Veeam’s SureBackup, Backup Scan, and Secure Restore workflows. No extra licenses needed. No complex deployments. Just pure, surgical malware hunting !

 

But what if you need granular control over what gets scanned? 

That’s where the registry keys VTHScanEmail and VTHScanExclusions come in to play. 

VTHScanEmail: The Email Scanning Power Switch 

• Key Path: `HKLM\SOFTWARE\Veeam\Veeam Threat Hunter\`  
• Value Type: DWORD  
• Default State: `1` (Enabled)  

 

What It Do ?

 When enabled (value `1`), Veeam Threat Hunter will scan:  

• Plaintext emails (e.g., .EML, .MSG)  
• Email databases (PST, OST, MBX, DBZ, etc.)  

A Trade-Off: 
 

Scanning complex email structures isn’t lightweight so expect longer scan times for your restore points, especially with large mailboxes and/or a lot of local files. Think about servers that hold multiple user's OST files. If performance is critical or PST files aren’t a priority, setthis key to `0` to disable email scanning.  

My personal view:
 

Use this key situationally! Enable it for targeted Secure Restores of mail data, but disable it for broad backup scans where non-email files are the focus.  


 

VTHScanExclusions: Your Performance Safeguard 

• Key Path: HKLM\SOFTWARE\Veeam\Veeam Threat Hunter\  
• Value Type: REG_MULTI_SZ (Multi-String)  

This key is Threat Hunter’s "exclusion list" a wildcard-driven filter to skip non-essential paths. Every second counts during malware scans, and excluding bloated folders (like temporary files or archives) can slash scan times dramatically.  

How to use this exception list ?

One Path Per Line: List exclusions vertically—no commas, no quotes.  
Wildcards Are Your Friend (But Handle With Care):  

•   *.log → Matches any ".log" file in any directory.  
•   Backup* → Skips folders and files starting with "Backup" (e.g., `C:\Backup_Old\`).  
•   \Projects\Temp\* → Ignores everything in "\Projects\Temp\" (but not subfolders like "\Projects\Temp\Archive\").  

Good to know: 

Veeam auto-prepends `*\` to your entry. 

                            "Documents*" becomes `*\Documents*` so matching any folder named "Documents".

Drive letters are wildcarded: 

                            "C:\Logs\*"  becomes "*\Logs\*"  

Minimum 3 characters per entry are needed

Deep path example: "\demo1*\demo2*\*" excludes "\demo123\demo\demo456\application.exe"

So pay attention when using wildcard in the middle of an exclusion string.  

A Real-World Example: 
 

Registry entry: 

*.tmp
Temp*
\Archive\*
Windows\Logs\*.bak

  
This set of exclusions will skip temporary files, "Temp"-prefixed items, anything in `\Archive`, and `.bak` logs under the path "Windows\Logs".  

Why This Matters: 

Veeam Threat Hunter isn’t just another scanner, it’s an insurance against "silent backup corruption". 

By leveraging these keys:  

• You avoid scanning gigs of irrelevant email data (VTHScanEmail).  
• You sidestep performance-killing directories (VTHScanExclusions).    
• You gain enterprise-grade threat detection without buying new tools.  

Final Checklist:  
 

• Back up your registry before editing.  (of course we always do !) 
• Guest file indexing must be enabled in order to scan the individual files.

• Use Veeam ONE to monitor scan performance trends.  
• Combine keys: Disable email scans (`VTHScanEmail=0`) & exclude non-critical paths for max speed.  
• Explore Veeam’s Official Threat Hunter Guide for more information

REGKEY of the month: JUNE

Hi, here we are again with our second episode of a total of 12, interesting regkeys for Veeam products.

This month we'll zoom in into the BackupCopyMirrorAll key...

Veeam Backup & Replication's Backup Copy jobs have two modes: Immediate copy (continuous) and Periodic copy (scheduled). By default, an immediate-mode backup copy job on its first run will only process the latest backup chain, not the entire history. In practice this means if your primary backup repository has older full/incremental chains (e.g. earlier monthly or yearly archives), those older restore points are skipped. In other words, the initial synchronization only grabs the newest full backup and its increments, leaving all previous chains behind. This behavior is documented by Veeam: "Backup copy job in the immediate copy mode processes only the latest backup file chain"helpcenter.veeam.com.

If you need to replicate the entire backup history for a job (for example, seeding an offsite repository or creating a full clone of past backups), this default behavior is a limitation. You would normally have to manually copy files or run complex scripts to migrate older points.

But with the BackupCopyMirrorAll you can do this in an automatic way.

Veeam provides a hidden registry setting named BackupCopyMirrorAll to override this limitation. When enabled for a given backup copy job, the job's first run will "mirror" all existing restore points from the source repository. Technically, this key forces the job to include every restore point in its initial sync instead of only the latest one

The registry key must be created on the backup server's registry (not on each repository).

Its details are:

• Registry Path: HKEY_LOCAL_MACHINE\SOFTWARE\Veeam\Veeam Backup and Replication

• Value Name: BackupCopyMirrorAll

• Value Type: REG_MULTI_SZ (Multi-String Value)

• Value Data: A list of backup copy job names (one per line) that should use full-chain mirroring.

Each entry in the multi-string value must exactly match the display name of a Backup Copy Job (including spaces and case). For example, if your jobs are named "Daily Offsite Copy" and "Monthly Archive Copy", the data should contain those names (each as a separate line). Crucially, this registry value must exist before you run the copy jobs for the first time - otherwise the older restore points will not be picked up.

Configuring the BackupCopyMirrorAll Key

To enable full-chain copying, create or update the registry value. For example, using PowerShell (run as Administrator) on the Veeam backup server:

# Example: Enable full-chain mirroring for two backup copy jobs

            $jobs = @("Daily Offsite Copy","Monthly Archive Copy")  

            New-ItemProperty -Path "HKLM:\SOFTWARE\Veeam\Veeam Backup and Replication" 

            -Name "BackupCopyMirrorAll" -PropertyType MultiString -Value $jobs

This creates a REG_MULTI_SZ value under HKLM:\SOFTWARE\Veeam\Veeam Backup and Replication named BackupCopyMirrorAll and populates it with the specified job names. You can verify it with:

            Get-ItemProperty -Path "HKLM:\SOFTWARE\Veeam\Veeam Backup and Replication" 

            -Name BackupCopyMirrorAll

Alternatively, you can add the value using regedit or reg add, but PowerShell is often easier for multi-string data.

How the this key affects backup copy behavior

With BackupCopyMirrorAll in place, the backup copy job's logic is altered. On the first synchronization run, instead of grabbing just the newest chain, the job enumerates all restore points in the source repository. It essentially processes each existing restore point as if it were "new". In practice, the copy job reads each restore point and creates a new, independent backup chain on the target repository.

This mirroring does not simply copy files byte-for-byte; it rebuilds a valid Veeam backup chain. For example, if the copy job is in Mirror mode, each original full backup in the source will be turned into an incremental backup on the target chain. The end result is that the target repository ends up with a continuous chain containing all the data from the source history.

Important:

Once the data is copied, the backup copy job enforces its own retention policy on the new chain. It does not inherit the source job's GFS (Grandfather-Father-Son) flags or retention settings. In other words, any weekly or monthly flags on the original backups will not automatically appear on the copied backups. Only the copy job's configured retention (including any GFS schedules you set on the copy job) will apply. Therefore, after the mirror operation, ensure the copy job's retention/GFS configuration is set appropriately. Otherwise, Veeam may prune older points from the target chain during its next retention run.

Use Cases and Operational Benefits

Enabling BackupCopyMirrorAll is particularly useful in scenarios where you need a complete backup history on a secondary location:

• Offsite or Cloud Seeding: When introducing a new offsite repository or cloud archive, you often want all existing backups transferred without manual copying. With this key, an immediate-mode copy job will seed the offsite store with the full backup chain in one synchronization, saving time and effort.

• Compliance/Retention Requirements: For regulatory compliance, you may be required to retain a certain history of backups offsite. By mirroring all restore points to a copy job, you can ensure those historical points are preserved. You can then rely on the copy job's own GFS schedule to keep, say, one full per month/year, knowing that the source's older backups were captured.

• Dev/Test Environments: Developers or testers often need a full production dataset. Using this registry key, you can copy the entire backup chain to a separate test repository. This provides a complete set of restore points for rapid restore or data seeding, without interfering with production jobs.

• Repository Migration: If you're migrating backups to a new storage system or upgrading the repository (e.g. moving to faster storage), a backup copy job with this setting can move the entire chain seamlessly. This avoids manual file transfers and ensures the chain is rebuilt correctly in the new location.

• Retention Considerations: Whenever using this key, remember that the copy job's retention still applies. For example, if the copy job is configured to keep only 2 fulls, after copying the whole chain it will later prune older fulls as needed. Configure the copy job's retention (including any GFS policy) before running it so that required historical points aren't removed unexpectedly.

In each of these scenarios, the BackupCopyMirrorAll key automates what would otherwise be a labor-intensive process of replicating every backup point. By preparing the registry value in advance, your immediate-mode copy jobs will effectively "mirror" the entire source history to the target repository.

REGKEY of the month: MAY

I’ll be sharing interesting and handy Windows Registry keys related to Veeam products. Whether it’s a hidden tweak, a performance optimization, or a useful troubleshooting tip, each month will bring a new Registry key that can help you get the most out of your Veeam environment.

Stay tuned for more keys, it might just save you some time or solve a tricky issue!

Got a Registry key you’d like to see featured? Let me know !

 

Unmount SureBackup NFS datastores automatically.

We all have seen it. Inaccessible datastores. You immediately think somethings wrong, but after a second look you find out it's the NFS mount for your SureBackup. Nothing wrong there, but for some people quite annoying.

 

This is normal behavior, by default the datastore remains mounted. Why ? This saves time when mounting it again when you fire up the next vPowered task.

But leaving them can cause false alarms, misinterpretation on capacity planning calculations (eg. VeeamOne reports) since these datastores are seen as disconnected.

But as from VBR version 12.3.1 you can get rid of these inaccessible datastores with a red sign using a regkey.

To unmount SureBackup NFS datastores automatically, us the following registry keys.

The first key is to enable the automatic unmount

vPowerNFSUnmountDatastore (DWORD)

            Key Location: HKLM\SOFTWARE\Veeam\Veeam Backup and Replication\
            Value Name: vPowerNFSUnmountDatastore
            Value Type: DWORD (32-bit) Value
            Value Data: 1
 

The second key defines a timeout in minutes to perform the unmount.

vPowerNFSUnmountDatastoreRetryTimeoutMinutes (DWORD)

            Key Location: HKLM\SOFTWARE\Veeam\Veeam Backup and Replication\
            Value Name: vPowerNFSUnmountDatastoreRetryTimeoutMinutes
            Value Type: DWORD (32-bit) Value
            Value Data: 5 (example)

 

Fun fact:

Internally within Veeam, this is called 'The Hannes Feature" named to Hannes Kasparick, part of the Veeam product management and an advocate to implement this feature.