Veeam with Data Domain and boost - dedupe rates

[jbsengineer]

Curious to what people are are seeing there de-duplication rates with Veeam and DDboost? Also what size datasets do you have? DellEMC is claiming north of 10:1.

[Andreas Neufert]

Hi,
as the source data is the same and both will store them uncompressed the deduplication of datadomain will do it´s job and reduce the data in the same way and ratio.
Within Veeam there are several ways to reduce the data before it is stored to datadomain without to break the deduplication engine. For example you can use the "dedup friendly" compression which deletes white space and other stuff before writing into datadomain. This can be helpful for performance as the deduplication engine has to process less data. The datadomain reduction ratio would show less reduction but the overall storage consumption on datadomain is the same.

As well you can increase the deduplication rate at the datadomain by storing more (synthetic) fulls. Which gives you a nice reduction rate, but do not change really the consumed storage after deduplication.

So overall the question is more what data you want to backup and how much deduplication you can achive there.

[DaveWatkins]

I would say 10:1 is pretty conservative estimate. We inherited a DD2500 with a acquisition and I've added it to our Veeam install. I wasn't holding out much hope since we don't get advertised dedup ratios anywhere (our SAN runs about 1.2:1 after being told we should expect 2:1) but was presently surprised with the DD. We're currently on ~20:1 with 385TB compressed down to 18TB

[Jo@BIT]

Within Veeam there are several ways to reduce the data before it is stored to datadomain without to break the deduplication engine.
For example you can use the "dedup friendly" compression which deletes white space and other stuff before writing into datadomain.
This can be helpful for performance as the deduplication engine has to process less data.

Hi Andreas,

why should I choose a compression? ... select "None" would be the best option here, or not?
because the repository is set to "Decomporess backup data blocks before storing"
Then the "white space and other stuff" are back again ....

regards
Jo

[foggy]

If repository is set to decompress data before storing, enabling compression on the job makes sense for data transfer optimization only (in case of slow links, for example).

[Jo@BIT]

Sorry for asking again ... what did you mean with "data transfer optimization" ? from production storage to Proxy ?
the "compression level" is a option for the "Target Storage"

[foggy]

I meant data transfer between proxy and repository - this is where the compression level you configure applies.

[Jo@BIT]

and who "Decompress backup data blocks before storing" ?

[foggy]

Repository (or gateway) server.

[Jo@BIT]

our way is
VM on Production Storage >> Storage Snapshot >> Proxy >> DDBoost
between the Proxy and the DataDomain is nothing ... we didn't have a GatewayServer (DataDomain9300)

[foggy]

In this case proxy itself acts as a gateway server, so compression level doesn't play any role (data is not compressed and then decompressed within a single server).

[Andreas Neufert]

DDboost Repository has a Gateway Server setting. This server is used to receive data from the Proxies.

It is best practices to always use compression and decompress onl directly at the end (Gateway Server). Makes processing faster as less (half) data is transported through the windows network stack and network.

If Proxy and Gateway server are the same we detect it and do not compress uncompressed data.

[mdiver]

Picking up this topic as it relates to my question:
I assume Andreas' statement is also correct for the new V10 NAS jobs when pointed to a dedup appliance?
So, will the gateway uncompress the NAS backup according to the repo settings even if the job does optimal compression?

Regards,
Mike

[Andreas Neufert]

Yes, correct