Deduplication Estimator Utility

[cffit]

I know this is kind of off the wall, but I was looking to reconfigure my backup jobs, and I thought it would be nice if there was some utility I could run to find out approximately how much deduplication I would get and what the estimated size of the backup job file would be?

I know I could just do this by running the actual jobs, but some of these are pretty large. Also, I don't want to mess with the current schedules they are working off of.

[veremin]

The practical use of such utility is the main question here, since the backup size isn't not very predictable thing as it depends on too many specific factors. If you're after making some rough estimations, you can use 50% as a data reduction ratio (compression + dedupe), because typically you won't see ratios less than that.

Thanks.

[cffit]

So I took the time to recreate all my jobs. Before I had different jobs for test vs production, but knowing that our test servers are near idential to our production servers, I combined them in jobs to take advantage of the deduplication. After all is said and done, the overall backup size is the same as when I had them separate. I expected to reduce my total backup size significantly by redoing my jobs to include servers that were near identical in each job. I'm disappointed.

Is there a way to find out what a job's deduplication level was?

Does the setting for "Storage Optimizations" under the storage tab of a job have a big impact on deduplication? If I feel deduplication should be better, would I change this from "Local Target", which is what it is, to "LAN Target"?

[Gostev]

Deduplication level is listed in a few places,for example in the job report, or when right-clicking the backup and going into its properties.
As far as impact of "Storage Optimizations" on deduplication ratio, this is actually described right there in the user interface, for each setting.

[cffit]

I understand that, but I guess my question then would be is there ANY deduplication with the Local Target setting? Because I grouped 5 SQL servers that should be 80% or more identical, and if the deduplication factor is the part in () after Transferred, it reads 1.1x. That seems very low for this.

[Gostev]

That means they are not identical at all. When I did the exact same experiment backing up 10 VMs made from the same OS template (but having a few different apps installed), I was getting close to 80% dedupe (basically, most of the image blocks belonging to the OS got deduped).

Also, I was getting the great dedupe after copying the same ISO to those same VMs, and running an incremental backup. The backup size was half of the ISO size (compression), when effectively the file was stored 10 times on the production storage.