Backup Browser Launch Performance

[ferrus]

I've read a few threads about slow opening speeds of the Backup Browser, during File Level Restores, but many of these concern remote Veeam proxies, over WAN links.
As I don't have any other installations to compare with, could anyone advise if the speeds listed below are normal, or if we have slow launch speeds.

Below times are for the "Please wait" dialog, after the launch of the Backup Browser, and before the files are listed: (B&R v8)

2TB VM, Host Veeam Proxy, DAS
2 minutes 30 seconds

2TB VM, 2nd Veeam Proxy (4Gbps LAN connected), DAS
4 minutes 45 seconds

2.5TB VM, 2nd Veeam Proxy (4Gbps LAN connected), DAS
8 minutes 15 seconds

[PTide]

Hi,

Please provide some details about your environment. Do you use Remote console (where is it installed?) or you start FLR from the VBR server? Also what mount server(s) did you specify for your repo(s)?

Thanks

[ferrus]

Hi, thanks for the reply.

Veeam B&R AS v8 - so no remote console.
Backup Browser started from within the B&R console, times above recorded after the completion of the Guest Restore wizard, and before the File Hierarchy is displayed (with the 'Please Wait' dialog showing).

Veeam servers: 3x Cisco C240 M4, 2x E5-2660, 96GB RAM, 43TB RAID6 DAS, 2TB RAID1 C:, 960GB RAID1 SSD. 4Gbps NIC Team, connected on the same switch.

[PTide]

Veeam B&R AS v8 - so no remote console.

I missed that, sorry. In this case please check entries in HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices. If there are many unknown devices listed the it might be the reason why it takes so long, you can delete them manually (be careful, don't delete system drives entries). Btw, do you have any plans to upgrade? New functions available in V9 allow you to flexibly choose the place where your backup files will be mounted thus increasing the efficiency of FLR operations.

Thanks

[ferrus]

Interesting suggestion - thanks.

I was going to put a support call in for another storage related issue we're having:
Most of the time I try a QuickBackup on a VM, I receive an error message - "Storage ('long guid...', CreationTime '14/03/2016 10:37:13') not found"
After a few retries it would work, but now I have to start a backup of the parent job instead.

There's also the unresolved IR performance issues we have - vmware-vsphere-f24/instant-restore-perf ... 35034.html

I'll have a look at the key you suggested. Would be great if they were all related.

[ferrus]

Version 9 migration planned - within the next couple of weeks

[PTide]

I was going to put a support call in for another storage related issue we're having:
Most of the time I try a QuickBackup on a VM, I receive an error message - "Storage ('long guid...', CreationTime '14/03/2016 10:37:13') not found"
After a few retries it would work, but now I have to start a backup of the parent job instead.

Please create a separate topic for that and post your case ID once you get it.

There's also the unresolved IR performance issues we have

I suppose that you've already checked that nothing is worng with the vmkernel port, right? If so then please consider contacting support team.

Thanks

[ferrus]

Yeah - definitely going to put at least one call in.
On the IR performance: the vmkernel was configured at the correct speed, there were no errors, jumbo frames weren't enabled because of our environment, but there appeared to be little utilization of the bandwidth - which is another thing that makes me consider storage again.

There's 27 entries in the HKEY_LOCAL_MACHINE\System\MountedDevices list. I'll work through them and see how they compare to our FC volume list in Computer Management.

[ferrus]

Update:

Quick Backup issue resolved (Case #01837409). Required manual deletion of the storage guid from the SQL database.
Unfortunately, it doesn't appear to have affected the Backup Browser performance, so - unrelated.

Noticed many of the entries in HKLM\System\MountedDevices, were from the Cisco vKVM/IMC remote console.
DIsabled this across all servers, and removed the entries from the registry.

Unfortunately, that hasn't affected the performance either.

May wait until after the v9 upgrade, before placing support calls for the remaining performance issues.