Skip to main content

Hi All.

Can someone please explain how data aging functions on an Indexing job?

Referring to "https://community.commvault.com/self-hosted-q-a-2/why-are-index-server-jobs-agent-type-big-data-apps-being-retained-on-storage-longer-than-the-storage-policy-indicates-5132".

I have a storage policy with several copies to different libraries. This is a mix of disk, S3 and S3 with Object Lock enabled.

There are several Indexing Jobs which reside on the S3 library with Object Lock enabled but the dependent backup jobs are located on a different selective copy. Is there a way to have the Indexing jobs kept with the backup jobs or is this by design?

The issue here is that the Object Lock enabled library is configured with 90 days retention and the other S3 library is configured with long-term retention varying between 365 days to 1825 days.

The above behaviour is preventing the sealed DDBs from being removed when all backup jobs have met retention as the Indexing jobs are retained.
I have seen the information at https://documentation.commvault.com/2022e/expert/backupset_level_indexing_index_cache_cleanup.html but I am not sure that this is applicable.

I do see the section "An index backup on the primary copy is deleted only when more than three backed-up versions of an index (per storage policy) exist on the secondary storage". In my instance the Index backups also exist on the Selective copies which have the backup data.


Thanks.
Ignes

@Iggy ,

From the documentation link that you provided, this is the part that you need to review. As it describes what has to happen in order for the data to age.

  1. If a secondary copy is associated with the IndexBackup storage policy, retention of index backups proceeds according to the following rules:

We also have the following report in the store, https://cloud.commvault.com/webconsole/softwarestore/#!/135/743/23630 which will let you know what jobs are preventing the index backup from aging off.

Regards,

Edward J Holowienka.

Hi @HolowEd ,

Thanks for the report, it proved really helpful. It shows which backup jobs are protected by the Index Backup.

In my scenario there are some VMs that got associated to a new VM Group (subclient).

 

 

I do have a question regarding the location of the Index backups. The Index Backup is located on 4 copies in the SP but the actual backup jobs are only located on 2 of the copies. Should the Index Backups not be on the same copy as the backup jobs?

 

Cheers.

Ignes

 

@Iggy ,

The index backup jobs will be copied to all copies.

Reqards,

Edward J Holowienka

 

Hi @HolowEd ,

Should the Index Backups remain on the copy if the backup jobs are not on the same copy but only on other copies?

Cheers.

Ignes

 

@Iggy ,

Yes, they will remain on the copy per the rule of 3 or until all of the jobs the index job is guarding are aged off.

Regards,

Edward J Holowienka.

Hi @HolowEd ,

Understood but the challenge I have is that all jobs on the Primary copy is Index Backups, a total of 50. The backup jobs only exist on the long-term copy.

In my situation the short-term library has S3 Object Lock enabled so the DDB are only deleted when all jobs have expired.

Is there a way to manually expire these jobs as I am unable to delete them because of WORM (Object Lock).

 

Regards,

Ignes

 

@Iggy ,

Can you please open a ticket with our support so that we can look at this issue further.

Regards,

Edward J Holowienka

Reply


Terms & ConditionsCookie settings