Repository settings for Exagrid

[ddockter]

I noticed on v6 there are two new repository settings "Deduplicationg Storage Compatability". What should these two paramentes be set to for an Exagrid?

[dellock6]

I talked with ExaGrid engineers, you do not need to use alignment, but you can obviously use decompression to increment ExaGrid performances.
About the second settings, if network bandwidth is not constrained, I will personally disable compression directly in the backup job, so I will not have to compress first and than decompress on the ExaGrid.

Luca.

[ddockter]

So since I already have compression level set to none in my backup job, I can leave both of the "Deduplicationg Storage Compatability" parameters unchecked, and I'm good to go?

[dellock6]

Yes, I'm using same settings here.
Luca.

[Daveyd]

I am an Exagrid customer...Per Exagrid Best Practices, you should not use Veeam compression so no need to Decompress and use "LAN Target". I do not use the "Align" feature.

Personally I think it's a numbers game. If you send highly deduped and compressed files to Exagrid,it will not be able to achieve high dedupe rates therefore showing low dedupe ratios. We are using another pair of Exagrid appliances for offsite replication and I think their replication has issues with compressed files from Veeam

[Gostev]

Luca is most correct. If you are backing up to ExaGrid unit located on-site, then compression should be disabled in the job settings. But if you are backing up to ExaGrid unit located off-site, then the best way is to keep the compression enabled in the job, and enable "Decompress" option in the corresponding backup repository settings. This way, the data will be sent over network compressed, but then decompressed by the target agent just before writing it to ExaGrid (for better dedupe ratio). Of course, your backup repository must be configured to use proxying server in the target site for that (which is NOT a default setting for CIFS-based backup repository).

[ddockter]

A bit of a side track ... we do a copy-to-tape of our Exagrid Veeam backups with Backup Exec for DR purposes. With Veeam compression turned off and storage target set to local storage, this makes for some large tape backup files that take a long time to restore. Right now I have almost all of my VMs in one backup job. I'm thinking of breaking out the ones that need to be restored first (AD, DNS, etc) in the event of a disaster. Or maybe the other option would be to turn on compression in Veeam and/or higher dedup so the tape data is not quite so large. Or would that make the tape restore run faster, but the Veeam restore take longer thereby being a wash? Any thoughts?

[Daveyd]

Luca is most correct. If you are backing up to ExaGrid unit located on-site, then compression should be disabled in the job settings. But if you are backing up to ExaGrid unit located off-site, then the best way is to keep the compression enabled in the job, and enable "Decompress" option in the corresponding backup repository settings. This way, the data will be sent over network compressed, but then decompressed by the target agent just before writing it to ExaGrid (for better dedupe ratio). Of course, your backup repository must be configured to use proxying server in the target site for that (which is NOT a default setting for CIFS-based backup repository).

It was my understanding from an Exagrid tech, and I could have misinterpeted him, that there were issues with sending a compressed backup to a local on-site Exagrid appliance if you are replicating to another remote Exagrid appliance(s) using Exagrid's replication technology. Is that not so?

[Gostev]

If you want best possible dedupe ratio on ExaGrid side, then you should not write compressed backups to it. I believe, this is what ExaGrid tech was telling you.

[dellock6]

I think you are talking about two different scenarios, and the difference here is : "who I use to send my backup over WAN?". Tell me if I can recap for both:

Anton: if you place the ExaGrid in a remote site, use a target site Veeam proxy, compress the backups and then decompress in the remote site right before saving them to the ExaGrid

Daveyd: if you have ExaGrid on both production and remote site, use usual settings to save to local ExaGrid (basically disabling compression in Veeam) and then let ExaGrid do their site replication over the wan link.

I think both solutions are perfect, they are simply describing two scenarios.