commvault.com commvault.com
Question

Running Mount Path "Space Relamation - Orphaned data"

  • 20 February 2024
  • 4 replies
  • 81 views
T
Rank
Userlevel 2
Badge +11

Question: If “System created schedule policy for DDB Space Reclamation” will not run against mount points that support drilling of holes… will me manually running [DDB] → All Tasks → “Run Space Reclamation (and choosing “Clean Orphan Data”) actually run and clean up orphan data if I have mount points that have hole drilling support enabled?

 

Background:

I have some mount paths (direct connected storage to physical media agents, not cloud) that have data not associated with jobs, and appear to be full of “referenced data” (they list DDB’s as being referenced) or maybe there is some “orphaned” data in them…I want to clean them up and eventually delete the mount points.

I plan to seal each DDB to remove the ‘referenced data”, but I believe if ‘orphaned data” existed, it would be left on the mount point after all the DDB’s were sealed and pruning/ageing occurred on them. I am hoping to have “completely empty” mount points before deleting them. 

Anyway, I see in this help doc: Performing a Space Reclamation Operation on Deduplicated Data (commvault.com)

These statements:

  • “For space reclamation operations on disk library, by default, the deduplicated data space reclamation operation is automatically associated with the System created schedule policy for DDB Space Reclamation schedule policy”
  • “...but the space reclamation process runs only on the mount paths that do not support hole drilling”

Currently, my “System created schedule policy for DDB Space Reclamation” schedule policy is disabled, and it appears all my mount points have hole drilling enabled (mount point → properties → General Tab: Supports Drilling of Holes = YES”

4 replies

S
Rank
Userlevel 2
Badge +9

Hi @tigger2,

We can still run space reclamation job on the mount path which do support drill holes option. we don’t recommend it because if the mount path drill hole support enabled it will by default defrag data at block level and space reclamation job tries to perform the same thing on the mount patghs which do not support drill holes.

 

Alternatively we would recommend you to ran full DDB verification instead of space reclamation job, it will also remove associations if there are any.

 

Things to consider:

  1. If the mount path was disabled today, data retention is 60 days. We will ahve to wait for 60 days and enable below options on the mount path. 
    ref: Mount Path Properties (Allocation Policy) (commvault.com)
  2. Then ran full DDB veriifcation, if there are no associations on the mount path, it can be deleted.

     

 

Regards,

Suleman

 

T
Rank
Userlevel 2
Badge +11

@SMD 

We have the “disable for new data” + “Prevent data block references...” settings above set on the mount path(s) (for maybe a year, waaaay longer than our retention), and we ran a full DB verification at some point (maybe after the mount paths were moved to new storage?), but I can run a Full DDB verification again and see what happens. 

The only other thing I have heard that will work is sealing the DDB’s, but I wanted to avoid it if possible, just because of space usage as 1 of our DDB’s are kinda large and it would be close in terms of “available space”.

These mount points are holding 90TB of space, and there is a possibility its ‘all orphaned or similar”, we don’t know, but as long as those DDB references are there we were really hoping that “finding a way to get the DDB references cleaned up” would free a lot of space.  However, there is also some fear when freed it would just ‘start being used up on the other, live mount paths” which makes sense that it would if its all truly being referenced.  Just some of the “chunk folders and file” in these mount paths are like 5-7+ years old according to the created/modified timestamps.

A
Rank
Userlevel 1
Badge +4

@tigger2 

For this comment

I plan to seal each DDB to remove the ‘referenced data”, but I believe if ‘orphaned data” existed, it would be left on the mount point after all the DDB’s were sealed and pruning/ageing occurred on them. I am hoping to have “completely empty” mount points before deleting them.

 

Sealing and aging all data would ensure that cleanup happens for all the data, leaving mountpaths empty.

Since you mentioned the steps done in this link are already done

https://documentation.commvault.com/2023e/expert/retiring_mount_path.html

Running space reclamation may be helpful.

 

S
Rank
Userlevel 2
Badge +9

Hi @tigger2,

 

We completely understand your concern. Also no need to seal the DDB as we have quiet large data.

 

Also, can you please confirm if the mount paths which needs to be deleted are online too ?

 

Here what we can do it create a a dummy mount paths for the moount paths you wish to deleted (Provided both the options “disable for new data” + “Prevent data block references” were enabled). Then Ran Full DDB verification. If Full DDB verification job completes without any error. we can delete the mount paths. For this you will have to raise an incident.

 

how to create dummy mount path

=> Go to mount path properties, sharing tab, edit the path to a local path, create commvault folder , create CV_MAGNETIC folder under that, select the local path before the commvault folder. Right click on the mount path, create mount path label. once that is done we will have to restart media agent services and dummy mount path will be online.

 

note:

ex: if the path is c/temp/commvault/folder_10.12.2023 then commvault folder is “folder_10.12.2023”

 

Regards,

Suleman

 

 

 

Reply


Terms & ConditionsCookie settings