Comprehensive data protection for all workloads
Post Reply
jotge
Influencer
Posts: 18
Liked: never
Joined: May 20, 2019 11:44 am
Full Name: Jan Groschopp
Location: Deutschland
Contact:

Bad Data Domain Compression Factor (Reduction %)?

Post by jotge »

Good morning at all!

We use a Data Domain as target storage for a backup copy job. Everything works as expected. Only the achieved compression rate is very bad in my opinion. We reach a value of 3.3x (69.5%). So 53.1 TB will be reduced to 17.9 TB.

Since we have written the same backups to the data domain before backing up with Veeam with the same hardware but with the EMC Networker, we have the comparison. Backed up with the Networker, we always achieved a reduction of around 98%!

Where is the problem? Or is Veeam + Data Domain with 69% the best result we can achieve?

The settings of the backup copy job are as follows:
Copy every: 1 day
Objects: about 120 VMs
Restore Points: 20
Data Reduction: None
Enable inline deduplication: disabled
enable backup file encryption: disabled
Data transfer: direct

The Data Domain Backup Repository settings are as follows:
Decompress backup data blocks before storing: enabled
Use per-VM backup files: enabled
Limit maximum concurrent tasks to: 60

I am looking forward to your feedback.

Thanks and best regards

Jan
ferrus
Veeam ProPartner
Posts: 299
Liked: 43 times
Joined: Dec 03, 2015 3:41 pm
Location: UK
Contact:

Re: Bad Data Domain Compression Factor (Reduction %)?

Post by ferrus »

I would have thought Veeam should achieve the same results as Networker, as the DD does the compression and deduplication (DDboost just offloads it).
For your comparison - are the compression figures for a single full backup, or for a whole backup chain? As you're likely to have a smaller chain with a newer backup product.

When we migrated to our new DC, with mostly new VMs - the compression factor on our DD mtree's, dropped from around 30x to 5x.
I'm hoping it increases as further GFS point are added.
jotge
Influencer
Posts: 18
Liked: never
Joined: May 20, 2019 11:44 am
Full Name: Jan Groschopp
Location: Deutschland
Contact:

Re: Bad Data Domain Compression Factor (Reduction %)?

Post by jotge »

Hello ferrus,

Thanks for your experiences.

We have defined 20 restore points for the Data Domain retention. I only read the values when they were reached.
jmmarton
Veeam Software
Posts: 2092
Liked: 309 times
Joined: Nov 17, 2015 2:38 am
Full Name: Joe Marton
Location: Chicago, IL
Contact:

Re: Bad Data Domain Compression Factor (Reduction %)?

Post by jmmarton »

I'm wondering if Networker was copying full backups daily vs Veeam copying incrementals. Sending daily fulls will artificially inflate the data reduction numbers since Boost will write the same data blocks in either scenario. The end result is the same space is used on the Data Domain. I mean after all, with some of the really crazy numbers I've heard with Avamar/Networker to DD like 150:1... there isn't any sort of magic that makes Boost dedupe to that degree with those solutions but not with Veeam. It's simply the case that Veeam didn't even attempt to send as much data in the first place, so there's less for Boost to dedupe.

Joe
jotge
Influencer
Posts: 18
Liked: never
Joined: May 20, 2019 11:44 am
Full Name: Jan Groschopp
Location: Deutschland
Contact:

Re: Bad Data Domain Compression Factor (Reduction %)?

Post by jotge »

Hello Joe,

thanks for your feedback.

I agree with you, the networker writes daily fulls (actually incrementals which are indexed accordingly), at least for the hypervisor backups. But these fulls also contain the daily changes. The networker, however, compared to save more recovery points (In this case, I have the direct comparison, which is the same environment to be backed up, after switching to veeam). Therefore, I have to assume that the dedup rate is better overall.

Is there anyone who also uses a data domain in conjunction with Veeam and has comparative values. I just want to make sure that I get the best possible dedup rate with Veeam and not give away resources due to a wrong configuration.

thanks and have a nice day
SteveK821
Novice
Posts: 9
Liked: 2 times
Joined: Apr 01, 2016 11:56 am
Full Name: Stephen Kebbell
Location: Germany
Contact:

Re: Bad Data Domain Compression Factor (Reduction %)?

Post by SteveK821 »

We have a few customers with Veeam and DD. Reduction factors according to the DD are between 14x(92%)and 22x (96%). They are also using the DD as a target for backup copy jobs (AFAIK). The jobs and repositories have similar settings to yours. The compression is either set to none or dedupe friendly.

We also have Networker and Avamar customers using DD. The rates for some Avamar/DD systems are about 100x, but that's because every Avamar backup is a Full, so the values are distorted there.
Networker/DD report slightly higher values on average. But not all. Some are lower (about 5x). Depends on the data, I suppose. I'm not a Networker specialist so I can't tell you how it backs up the data compared to Veeam. But it also uses vProxies and CBT.
Are you creating regular synthetic or active full backups on your primary backups?
jotge
Influencer
Posts: 18
Liked: never
Joined: May 20, 2019 11:44 am
Full Name: Jan Groschopp
Location: Deutschland
Contact:

Re: Bad Data Domain Compression Factor (Reduction %)?

Post by jotge »

Hi Stephen.

Thanks for your feedback. The values mentioned by you are very interesting for me. Unfortunately we do not reach them. When we secured the same environment with the networker, we still achieved it. Hmm ...

Anyway. Yes the DD is only used for backup copy jobs. We run a Synthetic Full weekly on Saturday through the Backup Job, and once a month on Saturdays we run an Active Full instead.

Hmm, where is the difference?

As far as the dependency of the dedup rate on the data type is concerned. Yes, of course there are some. For example, compressed data is very difficult to deduplicate. We already have this experience. In our environment, however, there are not many such data and as already said, above the previous backup with the networker the environment to be secured did not change.

Have a good time!
Post Reply

Who is online

Users browsing this forum: Bing [Bot], joel.preston, Lei.Wei and 86 guests