Best practise around Storage Policies in a new Commvault 11 Environment?

Last post 04-11-2017, 12:48 PM by Girish. 6 replies.
Sort Posts: Previous Next
  • Best practise around Storage Policies in a new Commvault 11 Environment?
    Posted: 03-12-2017, 5:13 AM

    I'm in the process of setting up a new Commvault 11 environment from the ground up.

    My other Commvault environment has several storage policies but that's due to it starting out round a decade back when many of our backups were directly to tape before we switched many to D2D2T.

    In the new environment I've setup my Global Dedupe storage policy and I have test backups flowing and aux copying so before I go further my question is around storage policy best practise.

    Our environment is simple, we have a dozen Windows and Linux File Agents, a couple of Exchange agents, and some VMware Socket licenses.

    Is there a guide on best practise around when to use separate storage policies if the intention is to use global dedupe everywhere and use Global Secondary Copy to optimise media usage with tape?

    Thanks Smile

  • Re: Best practise around Storage Policies in a new Commvault 11 Environment?
    Posted: 03-13-2017, 11:50 AM

    Hello Commvault Admin, 

    The usual configuration would look like this: 

    Based on the amount of data you plan to manage, you would need to choose the media agent/s (aka dedupe node). Media Agent versions available today are Small, Medium, Large and Extra Large. Hardware specs for a single dedupe node available here:

    You can also combine multiple media agents in a partitioned configuration for resiliency and increased dedupe pool capacity. This link has specs for 2 media agents in a partitioned configuration: 

    In v11 we support max of 4 partitions, so with each media agent hosting one partition, you can combine 4 media agents. 

    From a CV software configuration perspective, you would then create a single Global Dedupe Policy (GDP) that basically ties up the media agents and disk library to a single config. Then create multiple Storage Policies (SP) based on the type of data here - one for File systems, another for Exchange, etc. The primary copies of these individual SP's will point to the common GDP. 

    Each of these individual SP copies can have independant retention based on your business requirements. 

    Advantage of a common GDP is that this creates a single common dedupe store which makes all of the data landing into this store dedupe amongst each other for maximum storage savings. 

    For tape out, follow a similar strategy. Create a Global Secondary copy for tape (to optimize tape use) and each of the individual SP's will now have a secondary copy that points to this common secondary tape copy. The secondary copies can and usually will have different retention than primary copies. 

    Set up clients to point to each of the individual SP's and then set backup and aux copy schedules. 

    This is a quick run down on the process. Please ask any questions.  

  • Re: Best practise around Storage Policies in a new Commvault 11 Environment?
    Posted: 03-13-2017, 12:13 PM

    Girish thank you, that's where I am now.

    Where I'm still a little unclear is what is best practise around when to use a different storage policy?

    Is it based on client type, retention, or something else?

    For example if we want same retention of all backups is there any issue with a single storage policy?

    We're small, half a dozen agents and < 100TB.

  • Re: Best practise around Storage Policies in a new Commvault 11 Environment?
    Posted: 03-13-2017, 12:30 PM

    If we keep multiple storage policies based on data types, that will be best from a management and troubleshooting perspective.

    For example, if there is an issue with your exchange backups, you can easily zero down on the Exchange SP, start looking at how performance of those jobs looks like, etc. If we keep only a single SP here for all data types, you might have to filter out the exchange jobs, etc. 

    This also lets you change retention for data types if the need to do that arises at a later point in time, keeping the configuration flexible. 

    Also you can change the order and priority in which data gets replicated. For example, copy Exchange first and then file systems via auxcopy schedules, which won't be possible via a giant monolithic policy. Or easily disable auxcopy for a particular data type. 

    Reporting also becomes simpler - for example, show me all the jobs that ran for a particular SP. Otherwise you will need to pick and choose clients, etc. based on data type. 



  • Re: Best practise around Storage Policies in a new Commvault 11 Environment?
    Posted: 03-17-2017, 1:00 PM

    Short answer, no. There is no issue using a single policy but you may see dedupe rates be impacted down the road.

    Rule of thumb is to create as few storage policies as possible. We used to do it by data type (1 for file system, 1 for VM, 1 for SQL, etc.) but when we rolled out V10 a few years ago professional services recommended creating 1 for VM's/file systems, 1 for all databases (SQL, Oracle, Exchange), 1 for transaction logs (non-dedupe). We had the same retention policy for all data types so it was easy to manage, but if you have various retentions then different policies per retention would make sense.

    In your case, if you have very basic requirements then one policy should suffice. Just pay attention to dedupe rates if you're mixing data.

  • Re: Best practise around Storage Policies in a new Commvault 11 Environment?
    Posted: 04-11-2017, 12:32 PM

    Hi Girish,

    Could you please help me in understanding how can we implement Partition Deduplication in SAN Disk Library situations. Like how can we share a LUN between two MA's (R/W or R/O)?

    Have you come across any similar sitautions, where customer has DL on SAN storage (Netapp E-series) and Two MA's in DC1 & two MA's in DC2. I am thinking of implementing "Partitioned Extended Deduplication setup" as my DC1 data gets replicated to DC2 and vice-e-versa.


    Thank You

    Best Regards,


  • Re: Best practise around Storage Policies in a new Commvault 11 Environment?
    Posted: 04-11-2017, 12:48 PM



    Please check this out:

    You would want to use this feature to share out the mount paths. This is a recent addition to the product. Before this, mount paths had to be manually shared as read only via CIFS or NFS to the media agent not hosting the storage. Data server over IP simplifies this to a considerable degree. 

The content of the forums, threads and posts reflects the thoughts and opinions of each author, and does not represent the thoughts, opinions, plans or strategies of Commvault Systems, Inc. ("Commvault") and Commvault undertakes no obligation to update, correct or modify any statements made in this forum. Any and all third party links, statements, comments, or feedback posted to, or otherwise provided by this forum, thread or post are not affiliated with, nor endorsed by, Commvault.
Commvault, Commvault and logo, the “CV” logo, Commvault Systems, Solving Forward, SIM, Singular Information Management, Simpana, Commvault Galaxy, Unified Data Management, QiNetix, Quick Recovery, QR, CommNet, GridStor, Vault Tracker, InnerVault, QuickSnap, QSnap, Recovery Director, CommServe, CommCell, SnapProtect, ROMS, and CommValue, are trademarks or registered trademarks of Commvault Systems, Inc. All other third party brands, products, service names, trademarks, or registered service marks are the property of and used to identify the products or services of their respective owners. All specifications are subject to change without notice.
Copyright © 2019 Commvault | All Rights Reserved. | Legal | Privacy Policy