Can you reindex Evault from Centerra after a crash?
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
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 existIf 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.