To confirm, there are no jobs on the Primary, and the only jobs on the only Aux Copy are those Index jobs?

AND you can’t manually prune them?

Have you tried the command line approach?

https://documentation.commvault.com/commvault/v11_sp20/article?p=45239.htm

If that still does not work, then I’m out of ideas and would suggest creating a case with support.

See if I'm right:
SP: SP_ProdVM_DiskLibProd
- primary (There are no jobs)

- Copy-test-worm

i think the original jobs were removed and the copy jobs were not removed.
question: Is it possible to remove the copy jobs without having the original one?

Obs.: I dont know the person did this, but i need to remove.

This is a Lab.

Hello @Mike Struening 

These jobs are not necessary, but i can´t remove these:
 

The clients in the CommCell:

Hi @Fernando Souza , following up on this one.  Were you able to determine what to do with those jobs (needed or not needed)?

Thanks!

Perfect, thanks!!

Looks like these are indexing jobs for a subclient that doesn’t exist anymore.

Can you look at this client SP_ProdVM_DiskLibProd_Index Server and see if there’s a Big Data Apps Agent agent installed anymore?

If you no longer need them, you can manually prune them off.

@Mike Struening 

In attach the Forecast Report.

@Fernando Souza , for the Media Agents associated with SP - ProdVM_DiskLibProd are any of them protecting client data from back then?  

You may have some jobs that exist per the retention so these Index jobs are required.

Hello @jgeorges 

have a media agent associated: The CommCell: CommservDEMO

@Fernando Souza ,

These are the index jobs. They retain the Index Backups for the client indexes protected within them (used for when you browse the client data etc).

Can you confirm if those Media Agents associated with SP - ProdVM_DiskLibProd are protecting client data from back then?

Cheers

Jase

That’s definitely odd….can you confirm you are viewing the jobs on that same copy, and not across the whole Storage Policy?

Also, run a Data Retention Forecast and Compliance Report for this Storage Policy.  I want to see why 5929 hasn’t aged yet.

You have me intrigued, my friend!

The retention:
 

WORM jobs can’t be deleted before their retention period ends.

Hello @Mike Struening 

How can i remove these or can´t remove?

There’s your answer!  You have WORM jobs on this copy.

WORM Copy is an option that prevents the deletion of data that is not qualified for aging. The expiration date for the read-only is set to match the data retention time established in the storage policy copies. These archive files cannot be modified or deleted by any user or application until the specified retention date. Once the retention expires, the system deletes the archives as part of Data Aging.

WORM Copy also prevents deletion of clients, libraries, and mount paths.

After you create a WORM Copy, the following rules are enabled:

• WORM Copy cannot be cleared.

• The data retention on the WORM Copy can be increased but cannot be lowered.

https://documentation.commvault.com/11.24/expert/13938_worm_copies.html

Hello @Mike Struening 

When i try do delete expire jobs (In the DDB) for these backups, received this error:

Close….SQL query 

Check the post linked above for this part:

use Commserv

select * from idxsidbstore

That will show you which jobs the database thinks still exist for that dedupe database.

ok @Mike Struening how can i see the index portions? by CLI

Hey @Fernando Souza !

Assuming the database shows 0 jobs associated, the DDB will prune off on its own.

However, confirm 100% that the database itself has 0 jobs, not just the GUI.  Sometimes index portions remain but don’t show up in the GUI.

Hello @MichaelCapon 

I need to remove this DDB, and i put this DDB as Seal:
 

What is the next step to remove this DDB?
 

Hello @MichaelCapon 

Thanks, i removed the DDB sealed.

and i will remove the DDB.

Hey @Fernando Souza ,

Check out the steps followed in this thread and see if that helps:

Let us know how you get on!
 

Best Regards,

Michael