Can I point a specific backup job or storage policy to a specific mount path?

Hi @Convey2923 

We will need to determine whether the existing DB storage policy is deduplicated or not?

For a non deduplicated library you can create a separate library for the new partition and point the Database Storage Policy Copy (SPC).

To be able to dedicate your Database to the new partition, assuming its a non-deduplicated SPC you can create a sperate library for the New Partition.

Once this is created you can change the default Datapath of the Database SPC to point the newly created library

You can let the older database jobs remain in the old Mountpath and let them age as per the retention settings.

If the Copy is deduplicated you can add the additional partition as an additional mountpath into the existing library used for the SPC associated to the database.

https://documentation.commvault.com/11.24/expert/9360_adding_additional_mount_path.html

Enable the option “Prefer mount paths with more free space” within the library properties 

This will allow new unique data to be written to the mountpath with more free space.

If the older Database jobs are required to be copied to the new mountpath an additional copy can be created point to the new library created earlier for the new partition

Perform an auxiliary copy.

Once the Aux copy has completed and all the jobs have been copied, you can Promote the secondary copy to become the new primary.

Maybe I did not explain this correctly or the word Database is adding confusion. Our DB team using Microsoft to backup their databases and generates several large BAK files on a network share each week. I back them up with simple WFS backups. I keep hearing management talk about the “SQL” and “Database” backups so much I get confused but this is just a basic WFS backup that I would like to direct to a mount path on a separate drive volume. I do not use AUX copy for this storage policy, I only keep the backups weekly for 3 weeks and one monthly for 3 months. That is all in place. I just need to get that one storage policy that I call Database_Critical to separate itself from everyone else. We do use deduplication but I do not understand it enough as of yet. It was preconfigured long before I started. I will read your article and if my new info changes the picture, please chime in 

@Convey2923 , thanks for the additional details (and welcome to our community)!

So essentially you are backing up flat files via the Windows File System iData Agent (aka WinFS iDa), though management wants them going to their own drive, isolated, etc.

With that in mind, are these backups going to their own Storage Policy now, or to the same Storage Policy as other backup types?

If the former, all you have to do is create a new library, add it to the existing Storage Policy, disable the original for write by this Storage Policy and eventually the old jobs will age off.

However, if you are using deduplication, this complicates matters a bit (you’d do the same as above, but also seal the store to ensure no new references get created to the old files).

Now, if that data is in a Storage Policy along with the other clients, then you’d need to create a new Storage Policy with the above steps.

Based on what you mentioned, it sounds like you already have a separated Storage Policy called Database_Critical, though it likely shares a library with other Storage Policies. and just need to add the new data path and disable the old one for writing within this Storage Policy.

Let me know if that helps!

The job that performs this WFS backup has its own storage policy already. It does not AUX COPY. This is probably simpler  than I tried to explain. I would be happy if that one storage policy copied all data to a specific mount path that I will move to another Drive Volume. I do not see a real performance advantage but my management will see it as their “SQL BACKUPS” being stored separately in a volume they can physically see and feel more secure that the backups exist. 

You could create an Aux Copy to this new device, then promote the Aux Copy to Primary (and delete the old primary once you’re done with the older data).

That might be the simplest way forward