Solved

Index backup aging


Badge +2

Hello team

My Commvault is 11.20. In one of my storage policy I observed following problem. Index full backup jobs seems not to be aged. As far as I know system keeps only a few copies of full index backup. Schedule and cleanup rules are default. Retentions for this storage policy is no more than 1 month.

I see almost 40 jobs of full index backup from January this year until now. Every job has a copy on disk and a tape on storage policy. Data retention forecast report says aging of these jobs are according to index rule. Backups are small but it is annoying because old single copy of job takes full LTO8.

What is the cause of this behaviour ?

Is there any problem with index cache ?

How can I check it ?

Can I manually delete old index backup jobs ?

Thanks for any advice.

Regards,

icon

Best answer by Mike Struening RETIRED 6 July 2022, 23:21

View original

16 replies

Userlevel 4
Badge +8

Hello @jps666 

 

By default, for each storage policy and backupset we should be keeping 3 index backups each. So it is possible that they are all required depending on how many storage policies/clients you have.

 

I would suggest opening a case with support if you suspect something is off!

Badge +5

Hello@jps666 

 

I have the same problem, did you manage to solve it?

Userlevel 7
Badge +23

@Wayn , assuming we don’t get a reply, can you open a case and share the number here?

Userlevel 2
Badge +4

Hi,

From now on I remove the BIG DATA APP (per storage policy) client association with a DISK storage policy only with a copy on that to another disk copy target and skip the copy to tape for this.

Unfortunately this does not come out of the box with a SERVER PLAN.

Remember it's not JOB but unique BLOCKS that holds the retention on the TAPE storage policy copy.

This way you get easily rid of the locked on tapes by the BIG DATA APPS jobs.

 

I raised a support case and this is there answer:

BIGDATA APP jobs hold until all blocks have the latest last 3 backups not the 3 backups jobs how we see when we view the content.

This is the reason why though the retain time passed yet the JOB was listed due to not having the additional backup of blocks ( as of the last three). And this SQL database decides

This is a reason not suggested to keep in tape. If so keeping in the tape is the option,  BIgdata apps jobs to meet the block count of the last three backup sets and until all blocks

hold the last three sets... And I still believe these jobs will be existing since tapes are not smart enough to understand the other media outside the library if kept, knowing that some copy is left in it.

Hence manual intervention is needed sometimes if those tapes are to be utilized. If not, once they have met the blocks as explained above they will release those jobs.

 

And

 

 

I mentioned the workaround for the existing tape where the index backups job residing. So that you use those tapes.

and then Asked for any specific reason why you want to keep the Bigdata apps in tapes, Which we generally won't ask to do so . As keeping disk is a more easy task when restore is needed.

Userlevel 2
Badge +7

Same issue with a customer, a case has been opened and support proposed to perform a Media Refresh to merge the index backups onto one tape and reclaim other tapes back to the scratch pool but for me it seems to be tinkering !!

Userlevel 6
Badge +15

Well, reading this, I feel less alone, as I thought I missed some configuration somewhere.

I see fully aged backups on tapes except index backup that lock the tape, and then got pending tape copies until I manually erase the content of the tape.

Userlevel 2
Badge +7

CV infra has been upgraded to 11.24.43 to resolve this issue but it does not. 

Userlevel 7
Badge +23

@Gilles SCHMIDT , if you can, open a support case for this and share the incident number here.  I’ll move your replies into its own thread for better tracking once you do.

Userlevel 2
Badge +7

@Mike Struening Of course, here is the case n° : 220506-267

 

Userlevel 7
Badge +23

Ok, thanks!  I’ll keep this thread combined and unmark the best answer.

Userlevel 7
Badge +23

Sharing the details of the diag for anyone following:

I have received the DIAG from the development team. 

 

1. Please take a DR backup 

2. Please make sure the MR 52 is install before installing the DIAG

3. Services will be restarted during the install

 

Please find the diag details below.
 

Release v11
Minimum version 11.24.52
Summary Backport SP28 Form 525 - Aging index backups on copies if no backup job available on copy
Applicable-packages CommServe; CVGxCommServe; CVGxCommServeDB; ServerDB
Diag name UpdateBundle_Build1108123_Form5176
Userlevel 6
Badge +15

This case is currently in an archived status with the note that the customer will not be installing the Diag until August.
 

Userlevel 7
Badge +19

We also ran into it as well while running FR26 and if I recall correctly the fix is already part of a MR.

Badge +1

Just discovered this for one customer too - got index backups going back over 2 years!  

 

Unfortunately they’re only on 11.24.42, so looks like I’ll at least need to do an update before I even think about the DIAG

Badge +1

Just discovered this for one customer too - got index backups going back over 2 years!  

 

Unfortunately they’re only on 11.24.42, so looks like I’ll at least need to do an update before I even think about the DIAG

Actually, MR 11.24.65 looks like it includes it

 

Index backups being retained on copy even though no backup jobs present on that copy.

5963, 5968
Userlevel 7
Badge +19

Yes, by now it is included in a MR for all applicable feature releases who are still in support. 

Reply