Feature enhancement, would this be possible ?

[FreKac2]

Before adding it as an idea/request would it be possible to add e.g. subject/filename etc. to the databases when items are archived ?

Yes it will increase the amount of storage in the database but you could e.g. truncate the name/subject to X characters.

Reason for this is when you need to identify a mail/file/whatever based on the savesetid.

Have had one customer and it looks like I've got another where the partitions have been corrupt or files missing. Backups are either corrupt or have been through backup media retention, meaning no way to restore healthy savesets.

The natural question from the customer is "can you identify which mails/files/etc." that are affected.

Answer: most likely no and absolutely no guarantees and a lot of time spent investigating.

But I don't know if it's possible at all.

[JesusWept3]

Just because storage is corrupt, does not mean that the indexes are corrupt.
You could take the identifiable information from the database (SavesetID, TrnasactionId, IndexSeqNo etc) and put it in to Search.Asp to get you the meta data from the index.

[MarkBarefoot]

I was just going to post the same thing as JW2 said. Remember, your index is separate to the storage - it could at least point you in the right direction.

[MarkBarefoot]

As an example the TransactionID is pasted (minus the -'s) in the "Other Attribute" section

[JesusWept3]

And just to compliment what Mark put, you can use the following query to determine where the item exists, what folder, archived date and other attributes.

Also note that if you use Other Attribute and you put in the SavesetID, you need to put SSID in the name.

In the following query, you would use the IndexSeqNo that returns from the query, and then go to http://yourEVServer/EnterpriseVault/Search.asp?advanced, and where it says "Sequence Number" just enter the IndexSeqNo from the "From" and "To" text boxes

 Also knowing the Archive Name, you can then make sure you give yourself permission to that archive in order to search it etc

SELECT A.ArchiveName "Archive Name",
       AF.FolderName "Folder Name",
       AF.FolderPath "Folder Path",
       S.IdTransaction "Transaction ID", 
       S.ArchivedDate "Archived Date",
       S.IdDateTime "Sent Date",
       S.ItemSize "Item Size"
       S.IndexSeqNo "Index Sequence No."

       
FROM EnterpriseVaultDirectory.dbo.Archive A,
     EnterpriseVaultDirectory.dbo.ArchiveFolder AF,
     EnterpriseVaultDirectory.dbo.Root R,
     EnterpriseVaultDirectory.dbo.Root R2,
     yourVault.dbo.Saveset S,
     yourVault.dbo.Vault V,
     yourVault.dbo.ArchivePoint AP
     
WHERE S.ArchivePointIdentity = AP.ArchivePointIdentity
  AND S.VaultIdentity = V.VaultIdentity
  AND AP.ArchivePointId = R.VaultEntryId
  AND V.VaultId = R2.VaultEntryId
  AND R.RootIdentity = A.RootIdentity
  AND R2.RootIdentity = AF.RootIdentity
  AND S.IdTransaction = '2238DFDE-0807-4D4D-95EA-874CE8F9A3B0'

[FreKac2]

Had that issue on the first customer as well, since the index volumes was corrupt as well :) (it was a bad situation with several filesystem that was semi-working/corrupt, rare case but anyway).

You're correct though, forgot about the indexes in this case, will check that.

The question though is if it would be a good idea with some way to correlate the savesets with e.g. a subject since searching through the index means you need to add yourself with permissions through e.g. EVPM or using DA or some such.

Edit: just saw the additional posts, will comment later.

[MarkBarefoot]

I tried putting TransactionID in the other attibute field, and it didn't like it, so I left it blank. I wonder if it does a generic search for that string value?

I also thought of the AF stuff, but obviously it doesn't bring back the subject matter. I think this wouldn't be looked at to get added as it doesn't have real value.

[JesusWept3]

actually if you do a DA search, the DA search will return subjects, file names, file sizes etc, and it will store that in the database, i think its stored in something like tblIntDiscoveredItems or some such table.

As for the Archive folder stuff, well that is just more for a clarification, for instance if its an FSA volume, ok the item may belong to something like "FileServer\My Share"  but if you're looking at getting it from back up you will need to know what folder path the item belonged to in the first place.

And in terms of "well my index was corrupt as well" you can restore that index from a backup as well, and then just perform an update, an update won't remove entries from the index that exist in the index and the DB but don't exist on storage, because EV will think that the index for that item is fine, and just add items that don't exist in the index.

I guess though the real issue is that its worrying to say the least that a backup might exist of an item archived long long ago, where as the active DVS files have inconsistent or unreliable backups

[FreKac2]

Well JW2 you don't know the situation that was present at that customer.

I said it was a rare case.

The problem was not that there wasn't any backups, the problem was that the backups were broken as well because the data that was backed up was corrupted. It doesn't matter if you have a valid backup and the content is fubar. Shit in Shit out :)

Rebuilding/updating indexes with missing/corrupt savesets ?

The root cause for the problem was not because of EV, it was because the storage device was failing but the OS etc. didn't fail because of it. So EV was happy archiving the content, Netbackup backing the data up, indexing did generate events but as it is asynchronus to the archiving the damage was already done. Indexing doesn't stop the archiving process or the "remove safety copy" process.

It wasn't a huge data loss, about 400 items that we couldn't identify/recreate but a data loss is a data loss.

[JesusWept3 · Accepted solution]

Gotcha, all i meant was, say your disk failed and you lost data on your vault store and then your index goes bad, you then do a "Rebuild" of the index and it then goes along and says hey, i couldn't index these items, they're missing.

well what you could do is restore the indexes from before you rebuilt it, then when you searched against it, it would return the items regardless of whether they're truly on disk or not.

And if you were to do an update, it would simply compare the Internal Index Entry to find its highest item sequence number and then compare it to the database and update from there.

So you may have archived 500 items after the index originally went bad.
So in the index it says "my highest item is 1608" and it checks the db, its highest item is 2108.
It would then start added item 1609, 1610, 1611, 1612 so on and so forth until it hit 2108 and was back up to date.

But what an Index Update will NOT do is it will NOT remove entries that exist in the index and the database but do not exist on the disk.

So therefor if you've lost items on disk, and they're not in the index because of a rebuild after corruption, you simply restore the index, then search again and the items should be there in the search