Data pruning after the DDB Seale in the cloud wasn't performed. (Micropruning Off)

  • 3 November 2021
  • 7 replies

Userlevel 4

Hello Commvault Community, 


I need help with data pruning issue after Seal DDB (every 3 months) - micro pruning is disabled, but jobs shouldn't be held for that long anyway. (screen1.png)


Micro pruning is disabled due to the cost of operations in the Cloud Storage.
As I remember correctly, Commvault also recommended disabling micro pruning on the cloud library.


We have generated a Forecast report, where some of the described Jobs are actually kept by not being copied to Secondary Copy, but it's about 30TB, and for example (screen2.png) it says that the data is 126TB within one of the Sealed DDBs. There are several such databases and a total of about 600TB of data remains in the Cloud, which should probably be deleted.


I am asking for help in solving the problem. Screenshots and Forecast report are attached.


Thanks & Regards


Best answer by Mike Struening RETIRED 4 November 2021, 16:17

View original

7 replies

Userlevel 7
Badge +23

Hey @Kamil , thanks for the post!

Your report didn’t get attached (nor the screenshot).

Drilling holes being disabled might be the cause, though if you put an Ma in the cloud as well, it can be very efficient.  there might be more to why you were told to disable it (environmental issues, or it was true at the time) though we can now.  If your MAs are Hyperscale, I ABSOLUTELY recommend installing the appropriate Maintenance Release that just came out yesterday since there are some improvements to cloud drilling holes.

With what you mentioned, it’s possible that the remaining Aux Copies are holding onto the remaining chunks in the store, though I’d like to see the report before confirming (i.,e. if all the remaining jobs say “Not Copied” then we have our answer).

Userlevel 4

Thanks @Mike Struening for quick reply.


Attachments should already be added. The client works on the FR 22 environment, have the fixes you are talking about also applied there?



Userlevel 7
Badge +23

They show up now.  Might have just been a lag on the backend.

Looking at gddb-am4-bkp-mag01-p_15, there are some NOT Copied jobs waiting for an Aux Copy, though how much they are a factor is not clear.  I would get them over to the Aux copy and rerun Data Aging.

Otherwise, there are some backups for deconfigured subclients (run through the report looking for gddb-am4-bkp-mag01-p_15 and you’ll see examples.

Since you currently have drill holes turned off, it’s tough to ascertain how many big chunks are up there that would be full of holes otherwise….

Here are the MRs with the improvements, though note that these are specifically regarding Hyperscale Media Agents.

If you have only non-Hyperscale MAs that would be pruning these cloud files, then this is likely not your issue.

Feature Release

Maintenance Release


50 or higher


35 or higher


21 or higher


6 or higher

Userlevel 4

Hi @Mike Struening


Media Agents are not hyperscalable, @Mike Struening could you tell me more about "Drilling holes", I tried to find in documentation but unfortunately didn't find it (new documentation is harder to find information).



Userlevel 7
Badge +23

Drilling holes is more of a hardware vendor supported feature.  Essentially it means that as small pieces of a chunk file can be pruned, we drill holes into the big block (freeing up some small space).

If your hardware does not support drilling holes/sparse files, then you can run a Space Reclamation to get that back:

Rereading what you originally posted, I may have conflated micro pruning and drilling holes (which are not the same, though they are similar in concept….just not where they apply) so we can ignore my comments regarding that feature, though I’ll leave them there for informational purpose :nerd:   

So if we’re talking strictly about micro pruning of the dedupe store (before we even worry about the physical deletions).  If this is the case, then you need to ensure that ALL jobs in a store age off logically before you reclaim any space.

Looking at the report, you have a lot of older jobs sitting around waiting to be copied, and a few others I recall for deconfigured subclients.

I covered the best way to find the jobs in another thread here:


Here’s the instructions:

If you have access to the SQL studio manager on the CS, below queries can be run to confirm if there are any jobs stuck in the DB for the DDB store.

use Commserv

select * from idxsidbstore

[this will list all stores, identify and make note of the store id for the one you are concerned with].

Next run the following query to list jobs associated to this DDB.

use Commserv

select * from archjobsonstoreinfo where storeid = n

[n = store id for the DDB in question]

If this query outputs any jobs, You will have to run qoperation per instructions in BoL link for qoperation agedata

Now if that turns up empty, then we need to look at the SIDBPrune and SIDBPhysicalDelete log files on the Media Agents to see why data is not being removed.

Userlevel 4

Hello @Mike Struening


Forgive me for a long time without a response, I have a lot of work to do and forget about certain issues ...

The Customer asks if he can play single jobs that he would like to be copied? He would release a few jobs that are still kept on the first sealed database, it would be known if this would change something on the blob and if the amount of data would be reduced after the task was completed.



Userlevel 7
Badge +23

Sure thing!  It sounds like they want to make copies of a few of the jobs before you prune them?

Just create a Selective Aux Copy that does NOT Automatically pick jobs.  you can then go and manually pick them to copy: