Veeam Backup from Storage Snapshots - IBM SVC Rescan Performance

[falkob]

Hello community,

i have a question regarding the performance of rescanning the Storage Subsystem. (Storage discovery)

Iam experiencing some very long discovery phases of storage snapshots at a customer of mine.
The discovery runs about 1,5 hours per snapshot.



Is there any way to investigate where the problem really comes from ?

I know that there are two registry keys, which can be changed for the rescanning interval.

HKEY_LOCAL_MACHINE\SOFTWARE\Veeam\Veeam Backup and Replication\SanMonitorTimeout
Type: REG_DWORD
Default value: 600 (seconds)
Description: defines how frequent we should monitor SAN infrastructure and run incremental rescan in case of new new instances

HKEY_LOCAL_MACHINE\SOFTWARE\Veeam\Veeam Backup and Replication\SanRescan_Periodically_Days
Type: REG_DWORD
Default value: 7 (days)
Description: defines how frequent we should initiate periodic full rescan after Veeam Backup service rescan

Will those keys give me any advantage on the rescanning performance, or do i have to troubleshoot on another layer ?

Thank you very much and Best Regards !

Falko

[Andreas Neufert]

Did you have configured iSCSI access for rescan, as it is usually way faster?
Here are additional tips:
To optimize the Veeam Snapshot scan process, we suggest to reduce “PDORemovePeriod” at the multipath driver on all Veeam Proxies to 10 seconds. It can be defined in the Registry of the used multipath driver. For Windows MPIO please find the settings at:https://technet.microsoft.com/en-us/lib ... s.10).aspx

Some Server and Windows Versions need very long to initialize the UEFI Bios or boot Windows if they can access storage systems without a single volume attached (scan forever for volumes). In that environments it can be helpful to mount a small “helper” disk (20MB) from storage to the Veeam Proxy. The volume do not need to get initialized or formatted in Windows (offline is OK).

Veeam Snapshot scan processes at the Proxy use iSCSI as preferred access method as it is faster. If you want to force scans through FibreChannel access, you need to take care that the Veeam Proxies can not access the iSCSI interfaces of the Storage. For example by blocking iSCSI communication at the Windows Firewall or by disabling of the iSCSI protocol at the Lenovo Storage System within the Veeam Backup & Replication object.

[Andreas Neufert]

Oh and please share IBM setting for copyrate (should be 0) and cleanrate.

[crackocain]

Hi

I experienced similar issue for my customer. ESX datastore rescan duration about 10 minutes.

SAN zoning configuration not correct. We are fixed zoning and rescan times duration is 10 seconds.

[falkob]

Hi Andreas,

no we strictly use FC, iSCSI has been ticked off during the add of the SVC infrastructure as there are no iSCSI connections.
Due to my understanding i cannot use iSCSI if i have a FC only infrastructure, or am i wrong with this ?

I will give my customer a hint regarding the PDORemovePeriod at the multipath driver. Maybe this changes the behaviour.

Some Server and Windows Versions need very long to initialize the UEFI Bios or boot Windows if they can access storage systems without a single volume attached (scan forever for volumes). In that environments it can be helpful to mount a small “helper” disk (20MB) from storage to the Veeam Proxy. The volume do not need to get initialized or formatted in Windows (offline is OK).

The customer is using Direct Storage Access and Backup from Storage Snapshots, so the vSphere Datastores are already mapped to the Veeam Proxies. Due to my understanding this won't affect the "scan forever for volumes" problem.

Could you maybe give me more hints on this please.

Oh and please share IBM setting for copyrate (should be 0) and cleanrate.

Regarding the zoning: i checked the zoning and it should be all fine. Single Initiator Single Target Zoning on all components.

Thank you so far !

Best Regards!

Falko

[Andreas Neufert]

Copyrate setting is not 0 the volume start to fill the clone with actual data if I understand it correctly. Please check with IBM.

[Andreas Neufert]

And reagarding iSCSI. You can use iSCSI in parallel and we will scan with iSCSI which is way faster by design of the windows implementation for it.

[falkob]

I rechecked copyrate with my IBM colleagues. If copyrate is 0, there will be no sync of the data to the flashcopy.
If copy rate is higher than 0, this means, that there will be a sync to the flash copy with a specified processing rate in the copyrate parameter.

Thanks for the input so far. This means i can use iSCSI in parallel even that there is no configuration existing, right ?

Thank you !

[ag_ag]

Hi Falko

May I ask you if you have any existing support case? We would need to enable the extended logging for IBM and get the rescan logs in order to understand what's going on.

[falkob]

Hi !
We did not create a support case so far. We are testing the Registry properties of the multipath driver and the iSCSI settings at first.
If this doesn't help we are going to raise a case at the support.

I'll keep you updated.

Thanks for the help so far !

Best Regards
Falko

[falkob]

I opened up a case @ Veeam now.
Case # 03398819

Maybe you could re-check with the support !

Thank you !