cancel
Showing results for 
Search instead for 
Did you mean: 

Can you reindex Evault from Centerra after a crash?

Chris_Petersen
Level 3

Hi all,

I apologize in advance for my verbosity...

My question is regarding our backup procedure for our Enterprise Vault 8.0.4 environment (on Centerra).  Currently we perform nightly full backups of our entire evault environment (which consists of 2 archiving server, one journaling server, one SQL server, and one DA server).  However, the backup window for the indexes is growing too large and effecting other things.

So... this has caused us to take a good look at our backup procedure for the indexes (we are now considering switching to incrementals during the week with a full on the weekend) - which prompted another question all together.  We pull Friday night's full backup tape sets on monday morning for off site storage.  If our building were to be overrun by zombies on Tuesday, the most recent backup set would be from that previous Friday night.  However, one of our centerra nodes is off-site and would still have all the archived and journaled data.  So...  would we be able to restore from Friday night's full backup and then reindex the information from centerra that we didn't have a tape set for (saturday, sunday, and monday's data)?

Does any of that make sense?  Moving to an incremental backup of the indexes nightly with a full on the weekend would fix our backup window problem... but now I'm worried that we're not covered properly due to our tape vaulting procedures.

Thanks in advance for any help!

Chris

1 ACCEPTED SOLUTION

Accepted Solutions

JesusWept3
Level 6
Partner Accredited Certified

hang on, don't do a repair unless you have missingitems that failed to index, an update and a repair are completely different operations.

An update will do the following:
Compare the highest ISN (Index Sequence Number) in the physical index files vs what is in the database. IF the database has a higher ISN than the index, then it knows that it has items that are not in the index and it will index from the highest ISN in the index through to the highest ISN in the database.

For instance if you have archived and indexed 1000 items, it will show that the ISN is 1000 both in the database and in the index, and then if you restore the indexes to an earlier time where the highest ISN is 500, it will then start updating item 500 -> 1000.


A repair however is something different:
As items are archived and indexed, it is possible that an item will fail to be indexed, possibly it cannot be retrieved from storage or maybe there are memory issues, the item will be put in to a log file named "IndexMissing.log" which will list each saveset identity and a reason the item couldn't be indexed.

Also it updates the database and the physical index files themselves with an item missing count, when that number is 1 or more , then the "Repair" option is able to be used with in the Vault Admin Console and then you can run the repair.

The repair will read in each Saveset ID from the IndexMissing.log file and attempt to retrieve those items from disk and add them back in to the index.

If the option is available but the IndexMissing.log file does NOT exist, then what will happen is an event will be thrown saying that a repair is being done, but it will never ever finish, it will just sit idle in the background because the IndexMissing.log itself doesn't exist

 

If you do get in to this scenario of where you have to restore a little older indexes, the index volumes themselves will not fail, they will be online, they will be readable (as long as the restore puts back complete and integral information in to the correct locations).

All you would simply need to do is have the users perform a search against there archive, EV will load up the index in to memory, notice the counts between the database and the internal index entries are out of sync and push out an update.

Again alternatively you can update through the Vault Admin console, or if you use Discovery Accelator you can push out a blanket search against every user that you have and will cause everyones index to update.

I would also suggest not rebuilding indexes as there is no need.

https://www.linkedin.com/in/alex-allen-turl-07370146

View solution in original post

3 REPLIES 3

JesusWept3
Level 6
Partner Accredited Certified

If you restored all the indexes from a couple of days ago you would just need to update each of the indexes, theres a couple of ways you can do this

Either in the Vault Admin Console going to the properties of each archive and going to the Index Volumes tab and then right clicking the last index volume listed and going to Update Index Volume.

You could also do a search through Search.asp and when a search kicks off, it will force the index to update as well.

From the Release notes way back when

"If the value in the vault store database is greater than the value in the index volume, then indexing is prompted to start indexing items. Users attempting to search an index that is being updated will see a warning that search results may be incomplete.

If the value in the index volume is greater than the value in the vault store, then the index volume is marked as failed, in order to avoid inconsistent or invalid search results. An error is also written to the event log. This situation may arise if you restore an old vault store database from backup."

https://www.linkedin.com/in/alex-allen-turl-07370146

Liam_Finn1
Level 6
Employee Accredited Certified

JesusWept comments above use your database to see the inconsistancy and fails the index. You then do a repair and that repopulates the missing data into the indexes by reading the missing savesets from the database pulling the items from Centera and then reindexing it and populating your indexes again

Indexes are rarly a big issue to rebuild, the big worry is the data on Centera or in your vaults and the databases.

If you loose either of these then real work is needed to get the data back.

 

I would recommend a differential in the indexes because that will only require two tapes to restore whereas an  incremental backup will requireanywhere between two and 7 tapes to do a restore if you loose your indexes on a Friday before the next full backup is run

 

 

 

 

JesusWept3
Level 6
Partner Accredited Certified

hang on, don't do a repair unless you have missingitems that failed to index, an update and a repair are completely different operations.

An update will do the following:
Compare the highest ISN (Index Sequence Number) in the physical index files vs what is in the database. IF the database has a higher ISN than the index, then it knows that it has items that are not in the index and it will index from the highest ISN in the index through to the highest ISN in the database.

For instance if you have archived and indexed 1000 items, it will show that the ISN is 1000 both in the database and in the index, and then if you restore the indexes to an earlier time where the highest ISN is 500, it will then start updating item 500 -> 1000.


A repair however is something different:
As items are archived and indexed, it is possible that an item will fail to be indexed, possibly it cannot be retrieved from storage or maybe there are memory issues, the item will be put in to a log file named "IndexMissing.log" which will list each saveset identity and a reason the item couldn't be indexed.

Also it updates the database and the physical index files themselves with an item missing count, when that number is 1 or more , then the "Repair" option is able to be used with in the Vault Admin Console and then you can run the repair.

The repair will read in each Saveset ID from the IndexMissing.log file and attempt to retrieve those items from disk and add them back in to the index.

If the option is available but the IndexMissing.log file does NOT exist, then what will happen is an event will be thrown saying that a repair is being done, but it will never ever finish, it will just sit idle in the background because the IndexMissing.log itself doesn't exist

 

If you do get in to this scenario of where you have to restore a little older indexes, the index volumes themselves will not fail, they will be online, they will be readable (as long as the restore puts back complete and integral information in to the correct locations).

All you would simply need to do is have the users perform a search against there archive, EV will load up the index in to memory, notice the counts between the database and the internal index entries are out of sync and push out an update.

Again alternatively you can update through the Vault Admin console, or if you use Discovery Accelator you can push out a blanket search against every user that you have and will cause everyones index to update.

I would also suggest not rebuilding indexes as there is no need.

https://www.linkedin.com/in/alex-allen-turl-07370146