BCD Index restore, during Intellisnap backup

Hi @Farmer92 

What library is associated with the snap primary copy? disk/tape?

A previous case number would help so I have a bit of context to help :-)

Edit: If these are only snapshot backups, a workaround (not ideal) for now would be to specify the same Media Agent to be used for all scheduled intellisnap jobs so that the index would not need to be restored on each job. I know that isnt ideal but perhaps a solution until a better one is found.

Further addition after discussing with a colleague.

What you are seeing is expected behavior with Indexing V1 and using different media agents. Since indexes are not shared, it has to be restored from the previous Media Agent - but there are two options on the table to change your config to combat this.

1. Pin all those snap backup jobs to a single Media Agent - the index will always be available. You can also configure it to only failover if the primary is not available in the storage policy settings I believe (but be careful as it will affect everything going to that SP)
2. Migrate to indexing V2. I would not recommend this if you have tape in use without knowing more about how the environment is configured - but if not, there is more of a seamless workflow to lookup indexes remotely without having to copy the index back to the MA if it does not exist. V2 (or VM-centric backups) has several other benefits as well noted here.

Damian,

  Thank you for the feedback.  I forgot to mention we are on V1 for our VMware backups, and we do use tape.
   I searched my old cases, and I am not getting any hit for BCD.  It must have been a verbal conversion while I was on another ticket or the search is not accurate. :-)
   I would rather not pin the Snapshots as you noted it will defeat the benefits of Gridstore.

   I guess my concern is the 20 min lag.  The Index restore from the peer media agent takes seconds.  I just wish it was a step in the flow of the backup, rather than pending the job and waiting 20 min.

Thank you again!

Just got thinking of a reasonable comparison of how I would expect it to work.  When browsing backup,if the index is no there, it just restores the index inline and then gives me the results.  The browse does not say to go away for 20 min and try the browse again. :-)  It should just be a call to restore the index and then continue with the Snap backup.  Not a timed 20 min delay.

Thank you again, just venting the frustration.

Totally understand your frustration. Definitely unnecessary to be in a holding pattern when that phase has already completed. I sent a question to our engineering team to ask if the 20 minutes can be lowered through an additional setting or some other means - will let you know what i get back, but may take a bit of time 😉

Damian,

   Thank you again.  I am pretty sure this is the default job retry time out.  If I adjust it, it will affect all jobs. I think the only real solution is to not have the job go pending to begin with.  The job should call the Index restore in line, then when it is done (seconds) it could continue on.  The index restore seems like an out of band call.   Then after the default 20 min it will check and see it restored the index.

   I realize this is for V1 and I am sure it is not on the high priority list to work on for all us ‘old’ customers.

   I know back in the version 6.1 time frame, when Commvault service engineers came out to help install Commvault for us, he said just throw all your jobs at it, and Commvault will get them all done in the most efficient time possible.   This was quite foreign at the time, with ARCserve, we had to manage all the jobs manually and move things around.   It seems the the ‘Intellisnap’ backup job going pending for and index  restore was not the most efficient option that could have been developed. ;-)

Thank you again

Bill