Skip to main content

Hi!

I’m coming to you with the following issue. Our customer saw a sudden increase in Disk Library usage. Turns out a bunch of jobs weren’t getting aged anymore because their respective subclients were re-associated to a different Storage Policy. This makes sense as the cycle criteria part of the retention wasn’t being hit. However, according to the documentation, Commvault should drop the cycle criteria and age solely on days:

“If a subclient is re-associated to a new storage policy, the job retention is dependent on the following factors”

“The cycle retention specified in the old storage policy is ignored. Only the retention days specified in the old storage policy are honored after a full backup job is performed using the new storage policy. “

KB article: https://documentation.commvault.com/11.25/expert/11977_data_aging_frequently_asked_questions.html

A full backup has been taken on the new Storage Policy, but the jobs on the old Storage Policy are being kept and aren’t being aged.

Are we missing something? Do we need to adjust anything?

Thanks.

Jeremy

Good morning.  If you run a Data Retention and Forecast Compliance report, what does it show as the reason that the jobs are being held past retention?  What is the retention for the storage policy currently set to for the old and new storage policy?


Hi,

It just says Basic Retention as reason for not aging. (Which I guess makes sense as the Cycle criteria isn’t hit)

The retention for both policies is the same. It’s really odd.

 


@Jeremy , without seeing the report, my suspicion is that these subclients have not run a new full since.

The Basic Days count begins on the last Incremental of a given Full, so if no new full has run, then the count for Basic Days can’t begin.

Can you confirm if that is the case?  You should be able to tell by seeing the expected Prune date for these jobs.


Have you tried running synthetic fulls against these clients?

Reassociating a client should cause the next job to run as a full, if you simply reassociated the clients but have not run any jobs since then a synthetic full would allow the cycles to close.


Hi all,

It turns out the customer created new BackupSets for a handful of clients. And removed the schedules on the subclients under the DefaultBackupSet. Because of this, jobs weren’t getting aged anymore because the cycle criteria of the retention wasn’t being hit. I advised them they will have remove the jobs manually.

Thanks everybody.