move indexv1

Last post 04-20-2019, 10:49 AM by Wwong. 7 replies.
Sort Posts: Previous Next
  • move indexv1
    Posted: 04-16-2019, 6:22 AM

    Hi All,


    is there any possibility to move the index data for seperate clients from one MA to another MA ? We are using windows filesystem data with indexv1.



  • Re: move indexv1
    Posted: 04-16-2019, 11:11 AM


      If possible can you please explain the use case. This would help us provide you a better approach.

    Reason for asking the question:

    in v1 indexing index would be created in the index cache location and kept there for specified number of days based on index retention criteria. In case the index is getting filled then the least recently used index would be aged. So in general there shouldnt be an issue with index getting written to any media agent.




  • Re: move indexv1
    Posted: 04-16-2019, 5:58 PM

    Hi Smithse 

    For Windows Client backed up using Indexing V1, the Index Data will be populated and stored (until Index retention is met) on the default MediaAgent that it was backed up to. 

    Unless the Storage Policy you are backing up to consist of multiple MediaAgent, the only way to move the Index, is to move the client to another Storage Policy, but this will result in new baseline and a new Full to the new Storage Policy



  • Re: move indexv1
    Posted: 04-17-2019, 2:24 AM



    the Main reason is that the customer has 2 MAs and the Mas has an very large ( 1,2TB ) index cache different so on MA1 he hast 250Gb index cache space and on MA 2 1,5Tb he is using clients with indioex v1 and indexv2 actuallay we are trying to move the index gv2 from MA2 to Ma1 but the customer is running out of space in the flashcard where the index is hosted.


    thats the main reasion why i´m asking to move index v1

  • Re: move indexv1
    Posted: 04-17-2019, 4:57 AM

    For just index v1 - if you are backing up to local disk libraries (not cloud or tape) why not just delete the v1 index files and let commvault re-create the indexes when it needs to (ie when the next set of incrementals run).

    We have had index cache drives completely fail and Commvault rebuilt what it needed and completed the nightly backups on a new (empty) index drive with no issues. Index restore took a few mins max for each job.  It really isnt a big deal for v1 indexes.

  • Re: move indexv1
    Posted: 04-17-2019, 5:01 AM



    thats an good idear to clean up the index v1 directory.


    For the index V2 do you know if there is any workflow or something like this to move the index data ?


    Under the defaultbackupset properties i see the index server but when i change here something and click okay nothing happend. Also when i make an screen befor and after changening something in the properties the files and folders looks as befor.


  • Re: move indexv1
    Posted: 04-17-2019, 5:07 AM

    There is a workflow to redistribute v2 indexes, but i havent had a play yet.  From what i remember, changing the index server under defaultbackupset applies to new indexes, not existing data.  There is also a workflow to do this in bulk.

    Have a look at:


    I think index v1 is stored in the CV_Index subfolder.  its been a while since i did this, so i would check with your commvault support partner (or google) before deleting stuff!

  • Re: move indexv1
    Posted: 04-20-2019, 10:49 AM

    Hi smithse

    What Nicholas has mentioned is correct, the Index Data for V1 Index are just flat files, which are also stored with the Data written to Disk Library. 

    In the scenario where a V1 Index Cache is lost or deleted, if a "Browse & Restore" or a Backup (Synthetic Full) requires the Index, it will recall the Index from Media. 

    • Note - however if the Index Cache is associated to a Storage Policy Copy writing to Cloud (this could incur additional cost due to recalling from Cloud) or Tape (this will require the physical Media in the Library). 

    In regards to load-balancing, when you change the Index Server (Backupset Level), during the next Backup, the required Index will first be retrieved from the previous Index Server, replayed into the Index Server (newly selected) and then it will continue to use this Index Server. Over time the old Index Server will age out content which has met retention. 

    The second method using the workflow is also another method to load-balancing the Index Server, but this will be distributing the load across the entire environment. 

    Usual Index Location - /IndexCache/CV_Index/2/<ID's of Client>



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 © 2020 Commvault | All Rights Reserved. | Legal | Privacy Policy