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?
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.
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.
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!):
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!
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.
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.
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.
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.
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.
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!
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.
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.
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.
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.
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.
We use 3 different kinds of cookies. You can choose which cookies you want to accept. We need basic cookies to make this site work, therefore these are the minimum you can select. Learn more about our cookies.
