- Veeam Support Knowledge Base
- SureBackup: Error: Mount with leaseId already activated
SureBackup: Error: Mount with leaseId already activated
| KB ID: | 1237 |
| Product: | Veeam Backup & Replication |
| Version: | Any |
| Published: | 2011-09-30 |
| Last Modified: | 2025-03-11 |
Cheers for trusting us with the spot in your mailbox!
Now you’re less likely to miss what’s been brewing in our knowledge base with this weekly digest
Oops! Something went wrong.
Please, try again later.
Challenge
A SureBackup job displays the error:
Error: Mount with leaseId 'xxx-xxx-xxx-xxx-xxx-xxx' already activated.
Cause
Surebackup will fail with this message if certain operations time out. Veeam Backup & Replication implements timeouts for most operations to protect against hangs. However, even when no process is hung, timeouts may occur due to significant performance problems or an unusual use case.
Typically, this error occurs due to the slow performance of the vPower NFS datastore. Possible causes of the slow performance:
- Slow repository read performance, especially due to deduplication storage "rehydrating" deduped/compressed backup data.
- Slow network link between host and vPower server due to congestion, setting of 100Mb/s on a NIC, or other infrastructure issues.
- Poor performance of the vPower NFS server.
Solution
Increase Timeouts
The timeouts can be configured by creating the following registry values on the Mount Server. Increase the timeouts to 2x or 3x their default value. Needing to increase the timeouts further may indicate that performance needs to be investigated instead.
MountLeaseTimeOut
Key Location: HKLM\SOFTWARE\Veeam\Veeam Backup and Replication\SureBackup
Value Name: MountLeaseTimeOut
Value Type: DWORD (32-Bit) Value
Default Value Data(Dec): 600
The value is measured in seconds.
remotingTimeout
Key Location: HKLM\SOFTWARE\Veeam\Veeam Backup and Replication
Value Name: remotingTimeout
Value Type: DWORD (32-Bit) Value
Default Value Data(Dec): 900
The value is measured in seconds.
Improve Performance
Impact of Deduplicating Storage
The most common cause of this error is slow read performance from the backup repository. Which often correlates with the use of deduplicating storage as a back-end for Surebackup. If you must verify backups from deduplicating storage, increasing the above timeouts to several hours may be necessary, especially if there are any large (multi-TB) VM disks. Optimize storage devices for random read I/O of large blocks (typically 256 KB – 512KB with default settings or 4 MB for backups on deduplicating storage; your use case may vary). A simple benchmark is described in KB2014.
Performance of deduplicating appliances can also be improved by adding them as Deduplicating Appliance instead of via SMB (CIFS) or NFS.
Additional Performance Considerations
- If verifying offsite backups, ensure the virtual lab and vPower NFS server are on the same site as the repository.
- Depending on the underlying infrastructure, significant performance differences can exist between having the Mount Server assigned to a VM or from a physical machine. For example, try using a VM on the same ESXi host as the virtual lab.
- Heavily fragmented full backup files can reduce restore performance. Schedule compact operations to minimize fragmentation.
- Where applicable, test the throughput of the network connections between the repository and Mount Server and between the Mount Server and the ESXi host.
- Investigate CPU and memory usage of the repository and vPower servers.
If this KB article did not resolve your issue or you need further assistance with Veeam software, please create a Veeam Support Case.
To submit feedback regarding this article, please click this link: Send Article Feedback
To report a typo on this page, highlight the typo with your mouse and press CTRL + Enter.
