Index System Created Backups

Last post 04-11-2019, 11:11 AM by pereirath. 2 replies.
Sort Posts: Previous Next
  • Index System Created Backups
    Posted: 04-10-2019, 3:30 PM

    I have read the topics

    https://forum.commvault.com/forums/thread/56814.aspx

    https://forum.commvault.com/forums/thread/57334.aspx

    After reading still not completely clear... The IndexServer clients (Big Data Apps) created as of the SP11 release, my understanding is that the index for the jobs follows whatever the storage policy is configured to.

    1- Schedules are configured to run every 8 hours... Does it really needs to run this often?

    2- I have FULL copies every time it runs, does it really need FULLs or it can be set as incrementals? Which I believe would decrease the amount of time it normally runs for? Usually these copies takes a little longer to finish, any way to speed up the copies?

    3- If the data follows the storage policy, in case of TAPE backups, wouldnt it be more efficient to run Synthetic Fulls for copy it to tape?

    4- Trying to determine the most effective way to set this up, since I have seeing my monthly copies (tapes) significantly increase. Best practices?

    I appreciate the support.

  • Re: Index System Created Backups
    Posted: 04-10-2019, 7:04 PM

    Answers inline.

    1- Schedules are configured to run every 8 hours... Does it really needs to run this often?

    [Answer] Each run of Index backup merely checks if an index is qualified for backup. It does not mean that every index is backed up every 8 hours. Every subclient creates a unique index and every index is qualified for backup once a week only. Once a week backup of index is needed so that when index is not in cache or corrupted, rebuild of index is swift.

    2- I have FULL copies every time it runs, does it really need FULLs or it can be set as incrementals? Which I believe would decrease the amount of time it normally runs for? Usually these copies takes a little longer to finish, any way to speed up the copies?

    [Answer] Job runs as full, but it does not mean that entire index cache is backed up as full. As explained above, index qualification criteria for backup works differently. How long is index backup job running on your seutp? It is not expected to run that longer. Perhaps an escalation so we can check?

    3- If the data follows the storage policy, in case of TAPE backups, wouldnt it be more efficient to run Synthetic Fulls for copy it to tape?

    [Answer] We do not need Synthetic full for index as index backup is always full in nature.

    4- Trying to determine the most effective way to set this up, since I have seeing my monthly copies (tapes) significantly increase. Best practices?

    [Answer] Is your primary copy on tape? Perhaps it is better to understand your use case via a phone call? Either you can request for a Webex session via support or if you provide any other means to call you, I can explain. 

  • Re: Index System Created Backups
    Posted: 04-11-2019, 11:11 AM

    1- When you say is qualified for backup once a week it is a bit confusing since the schedule says weekly, but monday through friday is selected, so my understanding is that it runs basically everyday.

    2- When you say the index works differently can you be more specific? I have two storage policies that the primary is to tape, and usually index to tape takes a long time, which is one of my concerns.

    4- Two storage policies writing to tape (primary). NetApp snapvaults.

    Additional question, can I have Glocal Secondary Copies being written to the same tape as the Index tape? How do I assing a particular job to a tape? or tape to a job? Lets say I have 10 tapes and 3 storage policies (global sec copies) which I want to be written to a single tape. How do I prevent commvault to pick 2 or 3 different tapes to each job? 

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