Video Screencast Help
Symantec Appoints Michael A. Brown CEO. Learn more.

How does the expoiry process work?

Created: 07 Feb 2013 • Updated: 01 Mar 2013 | 5 comments
GertjanA's picture
This issue has been solved. See solution.

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 CommentsJump to latest comment

JesusWept3's picture

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

GertjanA's picture

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

JesusWept3's picture

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

GertjanA's picture

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

JesusWept3's picture

Expiry is a hard delete and bypasses the dumpster, if it does anything other than that, then it's a bug

SOLUTION