How does the expoiry process work?
Hello all,
Does anyone know where I can find information on how the storage expiry process exactly works?
We have recently enabled expiry on Journal Archives. We expect millions of items to be expired (long story).
We do see the index-locations dropping in size, indicating removal. We do see event 7085 in the eventlog of the Journal Archiving servers. (Number of vaults processed: 1 , Number of vaults enabled for expiry: 1 , Total number of expired items deleted: 6124314)
We do not however see the storage location dropping in size. We think that the storage expiry will only happen after it has processed all indexes. Is that true?
What I am looking for is a technote (or explanation) that when you enable storage expiry, it will first process the complete index, put items in the journaldelete table (or watchfile or whatever), and when the index is processed, it will start deleting items from the storage locations. Or whatever the process in itself is supposed to do.
Reason for the slowness might be (but that is a wild guess) is that items have been journal-archived since 2005, with a retention of 2 years, but we have only actually enabled expiry last month. This means it has to expire items of 6 years worth of journal archiving. We expire based on 'modified date'. Is there also a need to have the expiry schedule setup with 'gaps', or can it be 24*7?
Thanks, as usual.
Gertjan
Comments 5 Comments • Jump to latest comment
Do you do collections?
Basically what's going to happen is each item will be moved to journal delete and it works the same way as journal archive in that it tracks the items to make sure it's removed from storage and from indexing
This will happen concurrently the DVS/dvssp/dvscc will be removed, however if you do journaling and mailbox archiving, most likely a large portion of what's in the journal will be shared out to mailboxes, so the shareable parts will remain, only the journals DVS files will be deleted
If you have collections, then you won't reclaim any space until sparse collections have run
Hi JW
For Journal Archives, we use a seperate VSG, without sharing. We have the Journal Partitions on Centera, seperated from Mail Archives. We do have 'device level sharing' ticked. We do use centera collection (on the properties of the VSP)
What I suspect is that the delete on the EMC's is not happening. We do have a ticket open at EMC for the below. I'll check your article on sparse collections again :-)
Log Name: Symantec Enterprise Vault
Source: Enterprise Vault
Date: 7-2-2013 11:00:25
Event ID: 6760
Task Category: Storage File Watch
Level: Error
Keywords: Classic
User: N/A
Computer: server.domain.nl
Description:
Error from EMC Centera FPLibrary
Function call: NetworkPacket.checkControl(13)<HPPPurgeBlobTransaction::run()<Cluster::DeleteBlob(4LJD17CPL2T59e5JSGC77FMFSBJG415NULP2PR0C8Q39E5072R2FJ,,0)<ClusterCloud::DeleteBlob(4LJD17CPL2T59e5JSGC77FMFSBJG415NULP2PR0C8Q39E5072R2FJ,,0) with 6 retries<FPClip::Delete(pool,4LJD17CPL2T59e5JSGC77FMFSBJG415NULP2PR0C8Q39E5072R2FJ,,0)<_FPClip_Delete(pool,4LJD17CPL2T59e5JSGC77FMFSBJG415NULP2PR0C8Q39E5072R2FJ,NULL,0)<FPClip_Delete(-,4LJD17CPL2T59e5JSGC77FMFSBJG415NULP2PR0C8Q39E5072R2FJ)
Status: FP_SERVER_ERR (-10005)
Reason: No delete targets available - ENOTARGET - EATOM_SERVER_ERROR (transid='Servername/190/DELETE_CLIP')
Pool Address: the pool ip-addresses?\\servername\EVCentera\prf_ev.pea
Thank you, Gertjan, MCSE, MCITP,MCTS, SCS, STS
Company: www.t2.nl
www.quadrotech-it.com
www.symantec.com/vision
that would suggest an issue with the PEA file
give EMC Centera Checker a whirl with the PEA specified and see what results you get
Most likely Solution: Retain archive transaction history for: xx days.
Default was used (32 days).
As we do not use Vault Cache, this is being set to 25 days (we started expiry about 25 days ago). Hopefully this will now allow EV to start physically empty the JournalDelete table.
More to follow this week.
Thank you, Gertjan, MCSE, MCITP,MCTS, SCS, STS
Company: www.t2.nl
www.quadrotech-it.com
www.symantec.com/vision
Expiry is a hard delete and bypasses the dumpster, if it does anything other than that, then it's a bug
Would you like to reply?
Login or Register to post your comment.