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

  • 23 January 2022
  • 6 replies

Badge +1

Management has provided me with a separate partition for my Database backup jobs. I already have a storage policy dedicate to our DB backups. Is there a way to force a backup job or a storage policy to only save to a specified mount path? I am thinking I can move a mount path to the DB partition and then direct my DB storage policy or DB jobs to copy only to the mount path on the DB partition that has been provided 


Best answer by Laurent 27 January 2022, 11:27

View original

If you have a question or comment, please create a topic

6 replies

Userlevel 6
Badge +15

Hi and welcome !


Do you know if the mount path where your current ‘database’ backups are backup to, also contains backups from other storage policies, or is it already dedicated to database backups ?

Maybe the mount path is on a volume that hosts another mount path used for other storage policies. This we don’t know.

Because, if that’s the case, then performing a move of mount path can also be a solution : you’ll keep all backups and expiration dates, and no problem (though depends on the amount of data you have to move, and time it would take).

But if that mount path is also used to store backups of other storage policies (non sql, if I got your information), then move of mount path is not the solution, as it would move the whole contents = meaning all data from all the storage policies using that point path. ==> that’s where solutions provided by Emils and Mike would have to be applied.


Userlevel 7
Badge +23

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 :nerd:

Badge +1

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. 

Userlevel 7
Badge +23

@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!


Badge +1

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 

Userlevel 2
Badge +6

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.

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.