FSA archiving task creates very large log files – 7.1GB in size

[Topper454]

Hi,

I have a customer with EV 9.0.2 1061 with only FSA configured.

Over the past few months the following errors are displayed the log file whenever the archiving task is run.

This is not a valid placeholder file.  Ignoring this file.  Element not found. (Exception from HRESULT: 0x80070490)

The files which the error is logged against vary each time.

Twice a week on average the archiving task log file grows to over 7GB in size and the EV event log has an entry

which states the archiving task completed with over 11million errors. 

On several occasions this has caused the EV server C drive has run out of free space and therefore stopped all the EV services.  On the last occasion the issue occurred part way through the archiving task run which shot one of the indexes to pieces.(this has now been repaired thankfully)

The following Symantec technotes / workarounds have been applied

Problem files have been restored from the archive using FSAUtility – no change
HOWTO56261 - FSA FIX Offline utility - no errors found
TECH77221 - PreCreateOverwritten Value = 1 - applied, no change
TECH165458 - Update Placeholder Service and EVMF.SYS files on FSA target server, no change
TECH168167 - Read Only file error from DVDs etc - not all files giving errors are Read Only

There was an overlap between the EV archiving task and the BE backup job.  This has now been removed.

The Partition collection jobs (3) have been rescheduled to avoid

1. Each other.
2. Backup jobs
3. Archiving task runs

I would grateful of any suggestions anyone has.

Many Thanks

[Rob_Wilcox1]

I'd strongly suggest discussing it with Symantec support --  Log files of that size are just going to cripple the Enterprise Vault server, sooner or later.

[Jeff_Shotton · Accepted solution]

So from experience I can tell you that FSA CAN generate simply enormous logfiles without that actually being an error because of the number of items it can process on a pass (i.e the entire folder structure).

You DO have the option to turn verbose reporting (the default) off, and simply produce the summary version (the brief report) which may help, but not in resolving your problem. Maybe you could just turn down the number of reports kept to, say, 1.

Now the issue itself is one which could indicate an 'issue' with the placeholders (if indeed you have any placeholders). For a file to be considered a placeholder it needs to

1) Have the offline attribute

2) Have a reparse point

3) Have a sparse file attribute (as of EV6 sp2)

Now not all backup applications support reparse points or sparse file attributes, so if you were to backup a file system and restore the whole lot, you may find that not all the data actually came back (for instance, backup exec 10 used to actively block the writing back of the reparse point, even though it was in the backup)

So, what I would suggest is have a read of the following technote:

http://www.symantec.com/docs/TECH77221

Then try and get hold of steamexplorer (tho when i last checked the website was down due to funding issues)

www.rekenwonder.com/streamexplorer.htm

you might be able to get it instead from cnet : http://download.cnet.com/Stream-Explorer/3000-20432_4-75182124.html

OR failing that maybe just try querying the reparsepoint :http://technet.microsoft.com/en-us/library/cc785451(v=ws.10).aspx

Anyway the point is you are trying to investigate these files to make sure they are proper placeholders, because the error message indicates they are not. See this other forum posting for someone else reporting the same issue

https://www-secure.symantec.com/connect/forums/inavalid-placeholder-file-some-archived-items

Regards,

Jeff