Slow backup storage optimization - Veeam 8 Update 2

[lightsout]

From the Update 2 release notes: http://www.veeam.com/kb2024

What does this mean exactly for the "slow backup optimization":

Using the default “Automatic proxy selection” setting for backup repositories types providing an option to specify a gateway server disables the cache.

This seems like it could be written better. Does this mean I should leave my repository on automatic selection to make this cache work?

Is there anyway to tell if the cache is active or not in the job log?

[beaue]

I was wondering the same. Not very clear as to what needs to be set to take advantage of this feature.

I've opened a SR to get clarification and I will update this once I hear back.

[Gostev]

Does this mean I should leave my repository on automatic selection to make this cache work?

The opposite: leaving automatic selection on disables the cache.

This seems like it could be written better.

Please suggest a better description, and I will update!

[chrisdearden]

Out of interest why is this the case ? is it to avoid large numbers of caches to build / tear down ?

[lightsout]

Thanks Gostev for the clarification.

Here is my suggestion:

Using the default “Automatic proxy selection” setting for backup repositories when specifying the gateway server disables the cache.

And to follow up my other comment? Is there anyway to tell if this is active, beyond some memory usage increasing?

[Gostev]

OK, but not all backup repository types have an option to specify the gateway server, so there is a loss of information in your proposed sentence which can cause even more questions.

How about:

Using the default "Automatic selection" gateway server setting for Shared folder, EMC DataDomain or HP StoreOnce based backup repositories disables the cache.

As far as cache being active - I am sure some debug logs reflect this, but basically the cache is always enabled for 64-bit repository/gateway server OS (aside of this specific limitation we are discussing), so we did not include any special user-facing reporting.

[lightsout]

That covers all the bases, so yes.

[Gostev]

OK, changed in the forum topic, and requested the same change in the KB article. Thanks!

[ori]

Can you please clarify on

3. Disabling built-in deduplication disables the cache.

Selecting Data Domain as repository automatically disables deduplication in the job, should I turn it on? Wouldn't it impair the Data Domain built in deduplication?

[Gostev]

I believe that for Data Domain repositories the cache is always enabled, but I will need to double check.

[ian0x0r]

Would be good to know if the cache is always enabled for Data Domains either way. Looking forward to an update

[Gostev]

Confirmed with the devs that for primary backup jobs, cache is not enabled when deduplication is disabled, simply because it is useless in this scenario. My confusion was due to Backup Copy jobs, where it is always enabled regardless of deduplication setting (due to the Backup Copy jobs architecture specifics). Thanks!

[ori]

So would you recommend turning it on for Data Domain jobs? Wouldn't it impair the Data Domain built in deduplication?

[olssa]

So would you recommend turning it on for Data Domain jobs? Wouldn't it impair the Data Domain built in deduplication?

This is something I would like to know as well. Because if I check enable inline deduplication and click next veeam wants to change it to disabled ...because its not recommended, but KB says it should be enabled.

[hoFFy]

I'm wondering whats the best practise when using a NAS as backup target: We used to connect to NAS via iSCSI on the B&R server. Are these caching mechanisms only active when using CIFS? Shall we use CIFS instead of iSCSI now?
Sometimes the performance is VERY poor, unter 10MB/sec when using reversed incremental on a NAS with RAID 6 and 6 HDDs...

[chris.childerhose]

So would you recommend turning it on for Data Domain jobs? Wouldn't it impair the Data Domain built in deduplication?

I am interested in this as well. Looking forward to some direction from Veeam.

[dellock6]

I'm wondering whats the best practise when using a NAS as backup target: We used to connect to NAS via iSCSI on the B&R server. Are these caching mechanisms only active when using CIFS? Shall we use CIFS instead of iSCSI now?
Sometimes the performance is VERY poor, unter 10MB/sec when using reversed incremental on a NAS with RAID 6 and 6 HDDs...

No, they are always enabled as explained if the system running the target datamover is a 64bit system. In case of SMB (sorry I can't say the other name without getting sick...) the datamover is the gateway server, that can be automatically selected (and cache is disabled) or manually selected. If you left everything at default, the cache should be disabled since default is to auto-select the gateway.

For iSCSI storage, the datamover is the windows or linux machine mounting the iscsi volume as a local disk. Honestly, unless you're using something really small, the server running windows or linux will always be more powerful than the small NAS, and I would always prefer to use it.

Luca

[bgutwein]

I am also a bit confused with what the best practices are now for backing up to DataDomain. I was under the impression that I needed to disable Veeam deduplication on all of the jobs going to the DD share.

Also, how does Veeam know that I am backing up to a DataDomain? I currently have it set up as a CIFS share attached to the server. I can choose it for the Backup repository on the Storage screen of my backup jobs, but I haven't specified that it is a DD appliance as opposed to another CIFS server...

Will be monitoring this thread for sure!

[ian0x0r]

So as Gostev has pointed out, caching is disabled if dedupe is disabled on a primary job. Is this because the cache is only handling dedupe data so there is nothing to actually cache if it is disabled?

I'm just guessing here, would be good to know either way.

[dellock6]

Correct, metadata informations are used to map existing block already stored in the backup set, and leverage deduplication. If you do not want to use Veeam deduplication, there's no need to consume memory for the read cache

[foggy]

I am also a bit confused with what the best practices are now for backing up to DataDomain. I was under the impression that I needed to disable Veeam deduplication on all of the jobs going to the DD share.

Here's a good post on this, should give you a detailed answer.

Also, how does Veeam know that I am backing up to a DataDomain? I currently have it set up as a CIFS share attached to the server. I can choose it for the Backup repository on the Storage screen of my backup jobs, but I haven't specified that it is a DD appliance as opposed to another CIFS server...

You can specifically add your storage device as Data Domain repository, as opposed to CIFS repository.