cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted

Corrupt Evault Partition

Hi

Running EV 8 SP5 on Win2k3 std 64bit.   SQL is 2005 SP2 on a separate server.  Using Exchange archiving, and I archive to local NTFS partitions.

I have had some RAID and other IO related hardware problems with the server, which has resulted in a corrupted NTFS partition.  I've run a complete verify on the partition using evsvr, and it everything reports OK except the following:

Verify that Savesets can be retrieved - 18 failed

Some for 2 different reasons...

Error: The file or directory is corrupted and unreadable.  [0x80070570]
Fingerprint validation failed [0x80041b9f]

I am just wondering if this is an appropriate action plan to fix the problem:

1 - Verify backups are OK.
2 - Run chkdsk /r  on the corrupted partition.
3 - Replace corrupted files that were not repaired and deleted from backup copies, including ones reported as corrupted in previous evsvr verify
4 - Run another evsvr complete verify on the partition

Does this make sense?  How would you handle it?

1 Solution

Accepted Solutions
Highlighted
Accepted Solution!

well there is definitely

well there is definitely something going on, for you to have such a discrepency between what you had, and what you now have and EVSVR reporting whats missing its either

1. User deletions
2. Storage Expiry
3. Collections putting items in to CAB files
4. an EVSVR repair removing any corruption that it found
5. A database being restored to a time before items were archived

I'm not exactly sure what support are trying to say by there being not a 1:1 relation with DVS files and the number of items archived, because that still holds true, for each email archived there is always a DVS, if you have 2000 DVS files, you have 2000 archived email, the difference is when you have large attachments that get shared out, you could have 10 DVSSP files that are shared and with those DVSSP files gone, it can cause thousands of archived email to fail

For instance lets say I send 1000 people an email with a PDF file thats 1MB
Everyone archives the email, and we're all part of the Vault Store Group that shares
For each email archived there will be a DVS file created containing the meta data (who archived, when it was archived and other meta data etc)
Then the PDF File gets archived once and in the database those 1000 emails will link to this one PDF File, because they all share it

so you have

1000 x DVS Files (1 for each person who archived the email)
1 x DVSSP (This is the PDF file, all of those 1000 DVS files link to it)
1 x DVSCC (This is the Converted content, the HTML/TEXT rendition of the PDF)

If you delete the 1 DVSSP, you now actually cause 1000 seperate failures, because each email that links to that PDF, will try to find it, see that its gone and fail the recombine.

This is what i was trying to say earlier when that those missing files could be leading to other errors in your EVSVR, so one DVSSP file can cause multiple archive emails to fail the integrity checks

Also forget the technote, you don't have a centera, if you set it up with the partition set to be a centera, it would never have worked, plus you have an active and working fingerprint database, which doesn't get used ever for the Centera, because the archiving piece hasn't change at all from 2007 -> 8 -> 9 etc

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

View solution in original post

9 Replies
Highlighted

I think that is pretty sound

I think that is pretty sound so i think i would do

1. A complete backup (Chkdsk could possibly make it worse)
2. Then Run a ChkDsk and let it repair what it can
3. Run the EVSVR and see what state you are in now
4. Try to find any corrupt items on backup
5. Then run chkdsk again

Some of the items may be consigned and resigned to having to be removed completely from the environment

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

I should clarify what I meant

I should clarify what I meant by some for 2 different reasons.  The 18 items have only one error or the other, not both...  file or directory is corrupted OR fingerprint validation failed.

 

PS. This is not a Centera device.

Highlighted

i figured it wasn't a centera

i figured it wasn't a centera device due to the fact you have fingerprinting enabled
But really fix what items you have corrupt and then try validating the finger prints again, because they could all be connected
 

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

That's the plan.  Is the

That's the plan.  Is the method I mentioend above something you would recommend?

 

I find it a bit odd that if I compare some backups to the current corrupted item, one folder shows this difference:

 

The backup has 1180 files, and 584 files with the extension of .DVS.  Current partition has 318 files, 159 of which are .DVS files.  In theory, I should have seen a lot more than 18 failures when I ran the complete verify.

 

Does that make sense based on what the verify reported?  I thought it was one .DVS file per archived item.

Highlighted

Expiry or user deletions

Expiry or user deletions would be my first guess

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

EIther that, or collections

EIther that, or collections moving DVS from that folder into CABs.

Highlighted

oh man yeah, sorry, thats by

oh man yeah, sorry, thats by far the most obvious one, sorry

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

Support advised that in 8.x

Support advised that in 8.x there is no longer a 1:1 relation with DVS files and the number of items archived.  Items don't expire, and my users can't delete anything.  Also no CAB collection.

 

I've cleaned up the corruption on my one NTFS parition and restored corrupted items from good backups.  After all that, evsvr verify is still reporting the fingerprint validation errors.  This is all I can find about the error:

http://www.symantec.com/business/support/index?page=content&id=TECH130135

I do not have a CEntera (but have had settings set that may imply to evault that I do), and I'm running SP5 which this hotfix does not cover...or the technote has not been updated.  I suppose it's off to support I go!

Highlighted
Accepted Solution!

well there is definitely

well there is definitely something going on, for you to have such a discrepency between what you had, and what you now have and EVSVR reporting whats missing its either

1. User deletions
2. Storage Expiry
3. Collections putting items in to CAB files
4. an EVSVR repair removing any corruption that it found
5. A database being restored to a time before items were archived

I'm not exactly sure what support are trying to say by there being not a 1:1 relation with DVS files and the number of items archived, because that still holds true, for each email archived there is always a DVS, if you have 2000 DVS files, you have 2000 archived email, the difference is when you have large attachments that get shared out, you could have 10 DVSSP files that are shared and with those DVSSP files gone, it can cause thousands of archived email to fail

For instance lets say I send 1000 people an email with a PDF file thats 1MB
Everyone archives the email, and we're all part of the Vault Store Group that shares
For each email archived there will be a DVS file created containing the meta data (who archived, when it was archived and other meta data etc)
Then the PDF File gets archived once and in the database those 1000 emails will link to this one PDF File, because they all share it

so you have

1000 x DVS Files (1 for each person who archived the email)
1 x DVSSP (This is the PDF file, all of those 1000 DVS files link to it)
1 x DVSCC (This is the Converted content, the HTML/TEXT rendition of the PDF)

If you delete the 1 DVSSP, you now actually cause 1000 seperate failures, because each email that links to that PDF, will try to find it, see that its gone and fail the recombine.

This is what i was trying to say earlier when that those missing files could be leading to other errors in your EVSVR, so one DVSSP file can cause multiple archive emails to fail the integrity checks

Also forget the technote, you don't have a centera, if you set it up with the partition set to be a centera, it would never have worked, plus you have an active and working fingerprint database, which doesn't get used ever for the Centera, because the archiving piece hasn't change at all from 2007 -> 8 -> 9 etc

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

View solution in original post