Unsolved
This post is more than 5 years old
11 Legend
•
20.4K Posts
•
87.4K Points
0
829
August 6th, 2014 13:00
Re: Ask the Expert: Migrating traditional backups products to Application based backups using DDBoost
with DDBoost you are sending unique block only, then why is it being report as if i am send a full backup every day. That's my problem, it needs to report on the unique blocks only. There is no way in hell i can send 160TB in 4 hours (my backup window) to this DD890, yet it's being reported as if i am. So then your marketing people take this number and run around claiming that DD can ingest at 10G/sec rate (160TB in 4 hours of backup window).
I really like Avamar and i really like DD but the reporting/marketing is questionable, especially for customers who migrate from other backup tools.
No Events found!
Mabro1
2 Intern
•
666 Posts
0
August 7th, 2014 13:00
This is the original comment posted by Dynamox:
"Hi,
this is not a question but more of a comment. We are migrating from TSM/Data Domain to Avamar/Data Domain. When we look at Data Domain Pre-Comp Written to Post-Comp Written numbers, we find them to be sooooo inflated which in turn inflates Total Comp Factor number and make them look so good. TSM performs perpetual incremental backup, so does Avamar, yet DDboost numbers coming from Avamar look as if the system performs full backup every day which is not the case. As a customer i find it very deceiving.
The replies to this can be seen on : Re: Ask the Expert: Migrating traditional backups products to Application based backups using DDBoost "
I have branched Sergey's last reply to a separate thread to facilitate this discussion continuing while allowing the ATE conversation to continue on its original broader topic.
Regards,
Mark
akc5247_d7e299
45 Posts
0
August 8th, 2014 06:00
For those who missed out, this was branched out because of below:
ionthegeek
2 Intern
•
2K Posts
1
August 8th, 2014 07:00
This is an artifact of the way the Avamar client processes data from disk. The Avamar client runs every backup as a full, meaning each file on the filesystem is queried to determine if it has changed. We can get away with this approach since we're just hashing up the file attributes and comparing them against the hash in the file cache which is a relatively cheap operation.
The main side-effect of this in an Avamar / Data Domain integrated environment is that the amount of data being "ingested" by the DD Boost libraries is artificially inflated, as you've noted. It's not intentionally misleading, it's just a side-effect of the way Avamar handles unchanged data. If you were to run a full every day in other backup applications that integrate with DD Boost, you would see similarly inflated numbers.
dynamox
11 Legend
•
20.4K Posts
•
87.4K Points
0
August 8th, 2014 11:00
Ian,
it needs to be reported based on the actual ingested data. Now only are you inflating how much data is being ingested, you are also inflating your affective deduplication rate. When i am was backing up same servers to DD using TSM i was getting on average 14x dedupe on my DD, now that switched the same clients to Avamar/DD i am getting 114x dedupe. You think this is right, I don't think so.
ionthegeek
2 Intern
•
2K Posts
0
August 8th, 2014 13:00
I'm not saying what's right or wrong, I'm saying what is and why.