Solved

Two sites, two Media Agents, two DDBs, each site secondaries to the other, wildly different space usage

  • 9 March 2022
  • 3 replies
  • 45 views

Userlevel 1
Badge +6

So we have two sites… one media agent at each site.  Each site has a Primary backup to that sites’ MA with a secondary going to the other site.   It’s been this way for years.

 

In THEORY, with each site writing to itself and copying to the other, using dedupe/compression… one might think both sides would look roughly the same - as it’s the same “stuff”.  However, one site is ~290TB while the other is 440TB and growing.

 

I’ve talked to support to find out if there was a way to reconcile this difference and, while they were extremely helpful, it seems that life’s answer is “with dedupe and compression, you’re not guaranteed the same size when these things are involved.  You’re just going to have to purchase more space at the larger site”.  

 

Don’t get me wrong - we’re backing up more than a petabyte of data on each site, but it seems like one’s just far less efficient than the other.

 

Has anyone else faced this situation, and how did you deal with it?  

icon

Best answer by Mike Struening RETIRED 11 March 2022, 21:02

View original

If you have a question or comment, please create a topic

3 replies

Userlevel 7
Badge +23

Hey @roc_tor , thanks for the thread!

Support was right, though I can offer a bit more detail.

When we dudupe on Primary, the hash comparison for blocks is super easy.  Each job can check itself to see which blocks already exist and which need to be created.  Easy, and efficient.

Now, when we do the Aux Copy, there are numerous jobs being copied over across various streams.  However, we don’t dedupe each running stream against each other, because they are running concurrently.

That last part is a HUGE reason the sizes won’t match.  Granted subsequent streams will dedupe against what is already written, but not against the concurrent streams.

For that reason and a few others you already mentioned, it is not that rare to see such a large difference.

Userlevel 1
Badge +6

Thank you for your insight - good to know the secondary copies may not perform as well.  

 

An addtional question, if I may ~ does the below image, from the bigger engine, make sense?  Our Baseline/total app size is 238TB, and the total data size on disk is … larger?  427.5 TB?

 

 

Userlevel 7
Badge +23

Maybe…..?  I would assume no, to start though.  You could some white space you can reconcile?

https://documentation.commvault.com/11.24/expert/127689_performing_space_reclamation_operation_on_deduplicated_data.html

This very well could be what is happening.