Solved

Clarification on Extended Retention Recommendations and Messaging

  • 14 June 2021
  • 5 replies
  • 541 views

Badge +1

What is confusing about this topic is that Commvault seem to be sending mixed messages regarding the topic of extended retention.

From v10, the recommendation was to use separate selective storage policy copies (and therefore separate DDBs) for jobs with longer retention to avoid issues with the DDB size and performance. This was where that warning message in the Commvault Admin Console originated. This however leads to a massive increase in the amount of back-end storage consumed as you have a seperate baseline for each storage policy copy you create.

However in recent documention, when describing how to configure Plans from the Commvault Command Center, the documentation specifically states that one should use extended retention rules to create a hierarchical retention scheme (e.g to retain month-end backup jobs for longer. see https://documentation.commvault.com/11.23/essential/131386_extended_retention_rules.html

Seeing as this contradicts the message from the Admin Console does this mean that Commvault has changed their tune regarding extended retention rules and the message in the Admin Console should now be ignored as obsolete?

Or are there specific cases when one should use a seperate copy for long term data? The obvious case is when one wants to send the long retention data to an archive tier storage platform (e.g. tape or cold tier public cloud storage).  But what about if the extended retention is greater than a certain number of days or where the where the amount of deduplicated back-end storage is greater than a certain size (either of which could cause the DDB partitions to be excessively large)?  If this is the case Commvault should be providing guidelines for their users.

icon

Best answer by Mike Struening RETIRED 23 July 2021, 20:04

View original

5 replies

Userlevel 3
Badge +5

Hello Ryan,

We are still recommending to create separated selective copies for extended retention when deduplication is enabled:

https://documentation.commvault.com/11.23/expert/11947_data_aging_for_deduplication.html

https://documentation.commvault.com/11.23/expert/11919_configuring_extended_retention_rules.html

The documentation link referenced for Command Center Plan configuration talks about extended retention in general but it does not specifies whether deduplication is enabled or not. However, the same recommendation applies.

https://documentation.commvault.com/11.23/essential/131386_extended_retention_rules.html

 

I hope this helps clarifying your questions!

 

Best regards,

Sarahy Pardo

US-Server

Userlevel 7
Badge +23

Agreed with Sarahy, although the software handles mixed retention MUCH better than previously with changes that came in “DDB V2 Gen2”, which seems like yesterday, but it was a while ago now!

 

One big improvement solved many of the DDB drawbacks in terms of performance and DDB size, you can watch this (very) technical detailed video to explain what changed on that front: https://commvaultondemand.atlassian.net/wiki/spaces/ODLL/pages/501350567/Tech+Talks#TechTalks-DeduplicationGeneration4Version2

 

Badge

So, after listening to that in depth video from Carl Brault it seems that @Sarahy ’s advice is actually “out of date” provided the DDB that is associated with the Storage Policy Copy was either created as DDB v4 Gen 2, or you have performed an update of a previous generation DDB using the DDB compact tool since the DDB structure was modified.

Is that correct?

If so, can you please confirm what Service Pack those DDB updates were released in, and also how we tell what version a particular DDB is so we know if it needs to be updated.

And also, if this is true then the stock answer from Commvault support needs to be changed to include this information, and the warning message shown on the admin console should only be displayed when attempting to set extended retention on a copy associated with an older DDB version. 

 

Userlevel 7
Badge +23

Essentially yes; depending on the when and what (version), the overall advice might differ.

With that said, yes the stock answer is not going to be accurate because it changes with the evolution of the product….so I’m going to speak to some folks internally and see if we either have something that covers the differences (and if not, create it!).

Userlevel 7
Badge +23

Sharing a just published article that answers these concerns:

Feel free to comment and discuss via the link above!

Reply