10-29-2013 07:48 AM
Hi everyone, I know an EVSVR running with the [below] config will 'take as long as it takes'
Large storage, with the wide scope config = big task
Thing is, this report has been running for 4 weeks
The .log file date modified is incrementing, and the entries in the report increment with appropriate date logs, BUT it sems to miss days at a time,and sometimes many days at a time before logging another entry?
Can anyone take a look at the attached log and see if they can spot anything bad?
Are there any techniques or tactics I could be deploying to monitor this report's progress?
Many thanks
Config as follows:
check = process all vault store groups.
check = process all vault store stores.
check = process all partition.
In section “operation to perform” select “Operation = verify ” “Option= “complete”
Choose the whole date range .
Solved! Go to Solution.
10-29-2013 08:45 AM
Well the thing is, support really isn't meant to be helping with DR or cleanups etc.
But that being said, the current issues you have is with data being missing or inaccessible.
so for the ones saying its missing, such as
\\bdp\ev\EV_Archive\Vault_W\BDP Vault Ptn16\2012\12-10\D\Collection136747.cab
(File: 2012\12-10\D\0FD\D0FD23F932CD70A43E0F5289A70991B1~D9~18BE3351~00~1.DVSCC)
Does the CAB file exist?
Does the item exist in the CAB file?
If the CAB file doesn't exist, have a look on your backups and see if you can find it.and restore it
Also if the item doesn't exist in the CAB file, see if you can find the file name (The DVSCC) either in that cab or on backup before it was collected.
And like this file
Same again, do you have it on backup? if so, restore it etc
When time comes to do a repair, you're going to have to be in backup mode for it.
So try and limit it to that partition (Ptn 18) and that date (07-13-2013), and push up the threads
For that repair it would be Database Linkages etc
But definitely sanity check all this stuff, because its such a long ongoing process, you could have had network glitches, storage going down etc that may be showing false positives
And its the same with repairs, if you tell EVSVR to remove items that don't exist, and the storage goes down, then all of a sudden, item doesn't exist, remove it, item doesn't exist, remove it
So take a backup of your Directory/VaultStore/FingerPrint database before you do all of that
and make sure that you don't have the NoMonitor registry key set, because if drives do drop off, the NoMonitor will mean that the Admin Service doesn't shut everything down, and EVSVR will continue removing entries that do in fact exist
10-29-2013 08:02 AM
Well, you're missing some cab files and some savesets, and you're running one thread on a massive scope
what exactly are you looking for feedback on?
10-29-2013 08:32 AM
Hi bluesteel,
Running EVSVR - Verify against *all* the vault stores is going to take long time to complete. How much data do you have archived in the system? That can give you an idea of how long might take to complete. If you run a dtrace with the evsvr process for 5 minutes, you can see what folder and saveset is processing.
In addition, EVSVR verify will log an entry in the report only if it finds something wrong in the storage and/or the databases (CAB files missing, fingerprint DB entries missing, inconsistencies in the vault stores DBs, etc). Thus, if you haven't seen an entry in several days, that's a good sign.
Once the EVSVR verify finishes, then you need to do a repair. I **strongly** recommend you to open a case with support to run any EVSVR repair on your environment.
I hope this helps.
10-29-2013 08:45 AM
That was in fact exactly what I was looking for JesusWept - cheers
GabeV - thanks also
10-29-2013 08:45 AM
Well the thing is, support really isn't meant to be helping with DR or cleanups etc.
But that being said, the current issues you have is with data being missing or inaccessible.
so for the ones saying its missing, such as
\\bdp\ev\EV_Archive\Vault_W\BDP Vault Ptn16\2012\12-10\D\Collection136747.cab
(File: 2012\12-10\D\0FD\D0FD23F932CD70A43E0F5289A70991B1~D9~18BE3351~00~1.DVSCC)
Does the CAB file exist?
Does the item exist in the CAB file?
If the CAB file doesn't exist, have a look on your backups and see if you can find it.and restore it
Also if the item doesn't exist in the CAB file, see if you can find the file name (The DVSCC) either in that cab or on backup before it was collected.
And like this file
Same again, do you have it on backup? if so, restore it etc
When time comes to do a repair, you're going to have to be in backup mode for it.
So try and limit it to that partition (Ptn 18) and that date (07-13-2013), and push up the threads
For that repair it would be Database Linkages etc
But definitely sanity check all this stuff, because its such a long ongoing process, you could have had network glitches, storage going down etc that may be showing false positives
And its the same with repairs, if you tell EVSVR to remove items that don't exist, and the storage goes down, then all of a sudden, item doesn't exist, remove it, item doesn't exist, remove it
So take a backup of your Directory/VaultStore/FingerPrint database before you do all of that
and make sure that you don't have the NoMonitor registry key set, because if drives do drop off, the NoMonitor will mean that the Admin Service doesn't shut everything down, and EVSVR will continue removing entries that do in fact exist
10-29-2013 08:59 AM
Bluesteel,
Glad to assist. If you don't need more assistance regarding this topic, please mark the post that best solves your problem as the answer to this thread.
Cheers
10-29-2013 09:51 AM
Hello,
If you have concerns about the EVSVR Verify, you may want to open up a support ticket to have a TSE take a look at it. Depending on the amount of time you've put into the current EVSVR Verify, you may also want to consider breaking it down into smaller checks of each vault store or vault store partition rather than a complete EVSVR Verify against the whole environment, as this means the box has to stay up until it's done, or you'll get an incomplete report.
11-06-2013 08:45 AM
Thankls a million for input into this