Hi @LukasM 

I assume you are using deduplication?

Basically no, merging by moving/migrating the mount path towards an existing mount path with existing data is not possible.

There is a workaround by migrating the data to a subfolder placed on the new mount path, but this will mess up the space calculation as you are actually defining a mount path within a mount path. If you don't mind this, then you can, but it's not advised.

Question, is this mount path part of the same disklibrary config?

If it's a different disklibrary then you could create a new storage policy copy and aux copy the data, when completed disable the old copy. That is a valid migration method.

But this won't work if the mount paths are part of the same disklibrary / storage policy copy.

Hi, you are right there’s deduplication in place and Disk Library is the same. So the only way is to put of MP to disable new data and wait?

Will you be trying to continue to use that mount path? Or just move it to the new host until it ages off and can be retired?

I see the answer now that you replied to Jos about. Yes, as Jos said you can move the mount path to the new host, but i would highly recommend that the moved mount path be marked as offline and set to not reference blocks. This will begin the process of aging off all of the blocks on that mount path so that it could eventually be retired, typically a couple weeks past the jobs have aged for it. Otherwise, as Jos said it would not be desirable for that mount path to share the same phyiscal disk as it would double report consumption on that mount path. It could also cause additional performance issues for writing new data to it if left in place to be used. 

Yes and no.. a few thoughts:

• if your remaining goal is to phase out the old host you could migrate the mount path to a new storage location on the new host, clean but leaves you with two paths
• if your goal is to phase out the mount path now you could migrate the mount path to a subfolder on the new mount path and create a nested config, dirty but works, but will mess up space calculation.

So in all situations you are stuck with 2 different mount paths from a Commvault perspective, the latter one only provides you a file system solution to reduce paths from an OS perspective.

Thats a disadvantage of using deduplication, you are creating a configuration/relation between an engine and storage which is preventing to reclaim storage once written with deduplicated data.

In general, when you disable the mount path for new data and let data age you are still bound to this mount path due to the relation with the deduplication engine. Only when the mount path is empty and then deduplication engine id (the currently active DDB) used is sealed and empty you can delete the mount path location.
With the newly created deduplication engine id the remaining accessible paths will be used and the path you disabled for new data will be free to delete.

Downside of sealing the DDB, you will create a new baseline of unique blocks thus increasing your storage usage, perform proper pre-checks/calculations on your available storage capacity and expected storage usage for the time to come. Otherwise you can confront your company with unexpected requests to expand storage capacity or have them choose to delete backup data and start over, both not pleasant situations.

Back from the complexity to the basics:

• do you need to phase out the host, or
• do you need to phase out the storage, or
• can things wait till hardware live cycle management comes in play?

All depends on your situation to say which strategy is most useful.

After reading your reply, I have been checking and depending on the Feature Release used you can indeed use the option “Prevent data block references for new backups”.
Thanks @J Dodson 

This was introduced in V11 SP14.
Seems I need to stand corrected on my DDB seal statement.
Apologies for creating confusion by providing info related to old feature releases.

This would be a good option to phase out the mount path 

Instructions are here to prevent future block references:

https://documentation.commvault.com/11.24/expert/9376_disabling_write_operations_on_mount_path.html

Be aware that this still takes time as blocks on the mount path are referenced to by existing backups, these first need to be aged to delete existing reference points in the DDB before the path will be released by the DDB / CSDB and allowed to be deleted. 

Thanks you guys for the answers, since moving MP to nested paths would cause some storage reporting issues I’ll leave that idea any simply wait for data to be pruned, since MP was already set to prevent block references.

I though there was a workaround which I wasn’t aware of.

Have a great day!

If you already set that setting on the mount path, then it is a matter of the retention period passing for the data on that policy to pass since enabling the setting plus 1 cycle. In most cases that is. You can view the jobs on the existing mount path and see an idea of when that will be (Retain until column). Also the mount path free space will be equal to the mount path size.