Solved

Delete Mount Path associated to DDB

  • 29 January 2021
  • 14 replies
  • 4235 views

Userlevel 1
Badge +4
  • Commvault Certified Expert
  • 11 replies

Hello there,

I’m have a minor issue, I cannot delete unused Mount Path, since it’s used by DDB. There’s a few of MPs under Disk Library dedicated to this DDB. In the DDB properites I can only remove whole Disk Lib, which is not the point. 

 

CommCell says that in order to delete this MP, I need to delete each Storage Policy Copy which is referencing to this Disk Lib. It’s not an option neither. 

 

 

Logs are saying something similar:

 

EvMMConfigMgr::onMsgConfigStorageLibrary() - Error [470, Mount path is used by a Deduplication database.] occurred while deleting the mountPath[xx]

 

###### MLMMountPath::deleteMountPath() - :mlmmountpath.cpp:6170: Failed to delete mountpath [xx] due to error [470, Mount path is used by a Deduplication database.].

###### MLMMountPath::deleteMountPath() - :mlmmountpath.cpp:5593: Failed to delete MountPath from database for Id [xx] due to error Mount path is used by a Deduplication database.:470

 

 

Do you have ideas, workaround to delete single MP in that situation? 

icon

Best answer by Jordan 31 January 2021, 23:36

View original

14 replies

Userlevel 7
Badge +23

You likely have some blocks on that Mount Path that are in use by various jobs.  Removing it would cause numerous restores to fail.

You can mark the MP to not write new jobs which will prevent new blocks being laid down.

When you prevent writing, you can use the Prevent data block references for new backups option to prevent future jobs from referencing these blocks (no need to seal the store, yay!):

https://documentation.commvault.com/11.22/expert/9319_disk_libraries_advanced.html#b9376_disabling_write_operations_on_mount_path

Once the jobs that already referenced these blocks are aged off, there should be nothing left on that drive and you should be able to remove it.

Generally, due to how Deduplication works, adding a mount path to a Dedupe Storage Policy is semi-permanent without the above method.

Others might have some context as well.

Edited: Added details about the Prevent data block references for new backups option.

Userlevel 4
Badge +6

Please follow below guidelines.

https://documentation.commvault.com/11.22/expert/9319_disk_libraries_advanced.html#b9379_retiring_mount_path

Userlevel 1
Badge +4

(….)

Thank you Mike, but this MP contains no jobs. So it’s not the case.

 

I’ll give Space Reclamation a try, thanks!

 

Userlevel 7
Badge +23

(….)

Thank you Mike, but this MP contains no jobs. So it’s not the case.

 

I’ll give Space Reclamation a try, thanks!

 

Keep in mind that “view jobs” is misleading with deduplication since the actual blocks in a job are really spread all over. For that reason, jobs listed in other mount paths are referencing blocks in this mount path as well. 
 

Assuming the baseline blocks for any subclient were written there, and assuming those original jobs have aged, you might not see the newest jobs for that subclient associated to this particular mount path, but the referenced blocks might still be there. 
 

Keep me posted on space reclamation and how that goes!

Userlevel 5
Badge +11

@Lukasz what feature release are you on?

 

In recent FR versions, the CSDB will automatically check and remove referenced volume folders in the DB once they have been removed from disk.

 

This means that after you have enabled the “Prevent data block references for new backups” option, it will take approximately retention period + a few days before you will be able to easily remove this mount path. The reason for this time is because once you enable this option, other jobs written prior to this option being enabled may still be referencing the blocks residing in the volumes and chunks on this mount path. Once retention period is over (make sure all jobs prior to enabling this option has actually aged off), it will still take 1-2 days for the CS to receive all the volume check information from the respective MA(s), before it removes the references in the CSDB itself. 

 

Once all data volume references in the CSDB for this mount path have been removed, it will also remove the DDB association and thus allow you to delete the mount path. 

 

Another easy way to check if the mount path can be removed is to check the “Deduplication DBs” tab and see if the association still exists or not.

https://documentation.commvault.com/11.22/expert/9319_disk_libraries_advanced.html#view-deduplication-databases-ddbs-associated-with-mount-path

If it still exists and you feel retention period should have expired already, run a “Data Forecast and Retention Report” to determine what jobs may not have been aged yet and why. 

https://documentation.commvault.com/11.22/expert/39786_data_retention_forecast_and_compliance_report_overview.html

Userlevel 1
Badge +4

@Lukasz what feature release are you on?

 

In recent FR versions, the CSDB will automatically check and remove referenced volume folders in the DB once they have been removed from disk.

 

This means that after you have enabled the “Prevent data block references for new backups” option, it will take approximately retention period + a few days before you will be able to easily remove this mount path. The reason for this time is because once you enable this option, other jobs written prior to this option being enabled may still be referencing the blocks residing in the volumes and chunks on this mount path. Once retention period is over (make sure all jobs prior to enabling this option has actually aged off), it will still take 1-2 days for the CS to receive all the volume check information from the respective MA(s), before it removes the references in the CSDB itself. 

 

Once all data volume references in the CSDB for this mount path have been removed, it will also remove the DDB association and thus allow you to delete the mount path. 

 

Another easy way to check if the mount path can be removed is to check the “Deduplication DBs” tab and see if the association still exists or not.https://documentation.commvault.com/11.22/expert/9319_disk_libraries_advanced.html#view-deduplication-databases-ddbs-associated-with-mount-path

If it still exists and you feel retention period should have expired already, run a “Data Forecast and Retention Report” to determine what jobs may not have been aged yet and why. 

https://documentation.commvault.com/11.22/expert/39786_data_retention_forecast_and_compliance_report_overview.html

 

Hello Jordan,

this option from FR 22 to dissociate MP looks nice, but the environment is running on stable FR 20 and it’s not possible to test there FR22.

 

As for report, the MP was disabled for new data and as mentioned, there are no jobs at this MP. I’m currently testing the space reclamation solution. I’ll let you know if it helped.

 

 

regards,

Łukasz.

 

 

Userlevel 1
Badge +4

Still no effect, I’ll escalate the issue. Once it’s resolved I’ll let you know.

 

regards,

Łukasz.

Badge

Move the DDB data to new path.. wait for some time to clear the old records of old DDB then delete it….

 

Userlevel 7
Badge +23

Still no effect, I’ll escalate the issue. Once it’s resolved I’ll let you know.

 

regards,

Łukasz.

Let us know what happens (I’ll try and follow the case).  I’m thinking there are still blocks there (even though you don’t see anything on View Jobs) because the original jobs have aged off, but the old blocks (that are still being referenced) are there.

If I’m right, then you are on your way to a solution.  If I’m wrong, then Support will help you get to the cause!

Thanks!!!

Userlevel 5
Badge +11

@Lukasz , even in SP20 the feature was there :)

 

If you still don’t see the DDB being disassociated to the MP, then there may indeed still be jobs remaining that are holding up the blocks. Keep in mind that with deduplication, it doesn’t have to be a job on this MP, rather as long as there’s a job against the DDB itself from prior to when this MP was disabled and prevented for references (even if job is associated to another MP in the library), there may still be blocks being held up on this MP.

Userlevel 1
Badge +4

Thank you Jordan, I see your point. Correct, this view is available at FR20 as well. The MP is being held, but it contains 0 jobs (r-click > view jobs > shows nothing). So it looks like that’s kind of stuck or something which is preventing us from deleteing that MP. 

Userlevel 5
Badge +11

Hey @Lukasz, you may want to also double check on the disk itself for that MP whether there are any volumes under CV_MAGNETIC. If so, then it means there’s still some data blocks present that are referenced by other jobs in the DDB. Note down the time you enabled “Prevent data block references” option then view all jobs against DDB and see if there are still any jobs remaining that are from prior to this time.

If so, see if these jobs can be deleted at all. 

Userlevel 1
Badge +4

@Lukasz what feature release are you on?

 

In recent FR versions, the CSDB will automatically check and remove referenced volume folders in the DB once they have been removed from disk.

 

This means that after you have enabled the “Prevent data block references for new backups” option, it will take approximately retention period + a few days before you will be able to easily remove this mount path. The reason for this time is because once you enable this option, other jobs written prior to this option being enabled may still be referencing the blocks residing in the volumes and chunks on this mount path. Once retention period is over (make sure all jobs prior to enabling this option has actually aged off), it will still take 1-2 days for the CS to receive all the volume check information from the respective MA(s), before it removes the references in the CSDB itself. 

 

Once all data volume references in the CSDB for this mount path have been removed, it will also remove the DDB association and thus allow you to delete the mount path. 

 

Another easy way to check if the mount path can be removed is to check the “Deduplication DBs” tab and see if the association still exists or not.

https://documentation.commvault.com/11.22/expert/9319_disk_libraries_advanced.html#view-deduplication-databases-ddbs-associated-with-mount-path

If it still exists and you feel retention period should have expired already, run a “Data Forecast and Retention Report” to determine what jobs may not have been aged yet and why. 

https://documentation.commvault.com/11.22/expert/39786_data_retention_forecast_and_compliance_report_overview.html

Hi Jordan,

it look 7 days, instead od 1-2, but CS DB marked this MP as unnecessary. Then it could have been simply removed. Thank you.

 

 

regards,

Łukasz. 

Userlevel 7
Badge +23

Moved the new issue to its own thread:

 

Reply