FSA - 41142, moved archive point

[ianG]

Hi folks,

Have an issue whereby a folder enabled for archiving (with its own archive point), has been moved to a different file server - out of my control, for space balancing issues etc. The destination file server has the placeholder service installed, and the user has no issue recalling archiving files etc, the problem is just limited to archiving new content since the move.

I had thought just simply updating the file server targets would resolve it, ie removing the old path, and adding in the new one - choosing not to create a new archive point, as one already exists, but unfortunately, am getting a number of the following events:

Event Type:    Warning
Event Source:    Enterprise Vault
Event Category:    File System Archiving Task
Event ID:    41142
Date:        05/05/2011
Time:        02:57:40
User:        N/A
Computer:    EVserver
Description:
Duplicate archive point: '\\?\UNC\server\volume$\folder'.
The original folder and its archive point have been copied.
This folder and its subfolders will not archived until this situation is resolved.
Refer to the documentation for more information.

For more information, see Help and Support Center at http://evevent.symantec.com/rosetta/showevent.asp

Now, Ive found the following technote - http://www.symantec.com/docs/TECH64969 - which suggests deleting the archive point via admin console, and just recreating it with fsautility -a -s "pathname". But Im concerned that in doing so, I'll just end up with a brand new archive being created, and all subsequent content being archived into this new archive. From an admin and user point of view, multiple archives are just a no-no (we've archiving to a Compliance Plus Centera, so cant even delete and consolidate archives)

Just wondering if anyone has any ideas how to resolve this, without the creation of new archives. Can the moved archive point be updated to reflect the UNC path change, but yet still point to the old archive?

[RahulG]

you can refer the following instructions

) To fix this issue you will need to identify the folders that have the duplicate archive points from the event warnings.
2) Go the Vault Admin Console and open Targets->File Server->Server Name->Volume.
3) Right click on the volume and select archive points.
4) Browse to the archive that has the duplicate archive point and delete it.
5) Open a command prompt and change the path to program files\enterprise vault
6) At the prompt type in FSAUtility and then press enter
7) You get a list of the options for this tool
8) The option you need is -a which will recreate the archivepoints for everything under a specific volume.
9) Type the following fsautility -a -s "\\servername\volume" and press enter
10) You will see "Recreating Archive Points for \\servername\volume and when complete you will see XML Log file generated Done.
11) You will need to give the tool about 2 -3 hrs before it recreates the archivepoint.
 

[Rob_Brenner]

This is an area that is widely not well understood by Customers who implement FSA and can lead to severe headache, meaning that to recover from the side effects of incorrectly moving the Archives can be very troublesome.

The most important point to note is that in order to 'move' and Archive Point (AP) with its Placeholder contents from a source path to a destination path either in the same file server or on a new file server, the included tool FSAUtility.exe should always be used.

FSA maintains the relationship between the processed items on the file server and the corresponding records in the EV databases by means of Alternate Date Streams (ADS). Each folder processed as a target, including subfolders, will have a hidden stream added at the folder level which will contain the unique ID used to reference that folder in the EV database. 

Instead of using FSAUtility, if the Folder defined as an AP is moved to another server, there will be complications, including the Archiving Task will detect the AP at the new location as a copy or duplicate.

The recommendation here, if this environment has not been further manipulated would be to return the content to the source location, and use FSAUtility to recreate the AP at the original source location.

Depending on how much manipulation has been done after the content was moved to the new destination file system, it may be necessary to work with Symantec Support as the complications and recovery steps are far too complicated to address in a forum.

At this point in time we would strongly recommend disabling the FSA Archiving Task for the affected target AP until the situation is brought back to normality. This would prevent further corruptions within the metadata involving the ADS and database records.

[ianG]

unfortunately, the environment has most likely been further manipulated, and returning any moved folders to their original destinations isnt possible (capacity, file servers retired etc)

bit concerned by your post mentioning complications, corruption and recovery steps and so forth, as we've not experienced any issues with the data to date - files have been recalling no problem. Only issue has been the automatic archival process

[Rob_Brenner]

I feared this would be the case, nevermind. Let's then consider a different approach. Again the rate of success will depend on how many changes have been made to date since the move.

The content is now on a different file system / different target file server. As the FSA Agent seems to be installed on that file server it would allow the PH that were transferred from the source file server to be fully retrievable. The problem, as you have already highlighted would be during new archiving operations.

The main issue being that the AP xml stream contains an ID which in the database refers to the old file server. so this AP is no good.

Ideally, where possible, all PH should be recalled, then the existing AP at the folder level which was copied from the source file server (EVArchivePoint.xml) should be deleted. It would be advisable to save a copy of the ADS before you delete. Saving and deleting can be easily achieved with 3rd party tools such as NTFS Stream Info.

Once all the data has been recovered you should then define the targets and a new AP. Archiving then would be processing all files into the new Archive.

If you are unable to recall all Placeholders in one go you may do this in stages but we would recommend to do all as soon as manageable.

[ianG]

That certainly sounds doable, and makes good sense in my head - but we would have really like to avoid any solution that would result in additional archives being created though.. sadly, its starting to sound like theres no other way?

Many thanks for your patience and advice so far by the way..!

[Rob_Brenner]

Let's put things into the right context.

Assuming you would be able to recall all the content from the legacy Archive and the items would be re-archived into the new Archive, you should be able to delete the old Archive and end up with one Archive only. This is the main reason why it would be better if you can recall all the Placeholders in advance. it would simplify things.

In any case, one of the most important things to consider is that you should preserve backup sets created before you make any major changes, so that in the event any content from the old Archive has not been retrieved and re-archived into the new Archive, there will always be a possibility to restore the backup sets to a parallel system to retrieve the required content.

[ianG]

That would be the way to do it alright - we're on a compliance plus centera though, so deletion of archives is somewhat limited.. (impossible as far as I know? well, prior to their 7 year retention)

having slept on it, perhaps though I could:

• recall all PH
• delete old archive point (backing up stream info)
• recreate, and archive into new archive

and then, since I cant delete old archive

• rename old archive to something relevent
• set permissions for everyone to deny all or the like
•  

Though I dont think Im able to add 'everyone' when manually setting permissions on an archive via the GUI

[Rob_Brenner · Accepted solution]

In regards to Centera, you are correct, EV will not have any means of overriding the retention settings controlled by Compliance Plus. Therefore the items will remain in the Vault Store partition for the pre-defined period. I presume this would represent less of an issue compared to the logical corruption involving the Archive Point target you have at the moment.  

The idea of renaming the old (legacy) Archive would be a much better approach, I agree. At the Archive level you can manually override the permissions by setting 'Deny' manually.

I would not use 'Everyone' as you could be locking out even the VSA account. Even the 'Domain Users' will lock the VSA. Creating a customized AD Group, where VSA is not included, would be more suitable, while you explicitly add the VSA account with all permissions to the Archive, in case you need to access this legacy Archive at a later stage. The GUI will allow you to specify any Windows AD groups, 'Everyone' included.

[ianG]

This sounds like a plan alright, and is what Im going to go ahead with.

My main concerns about the multiple archives would be the confusion for the users, having multiple archives in archiveexplorerUI etc, and management overhead for ourselves trying to identify old vs new archives etc

Renaming the old archive ('archive' -> 'archive-old-date' or the like), and then setting some deny permissions should take care of both the above. The archives themselves are typically only accessible by a single user per archive anyway, so I'll just add them as the deny.

Not too concerned with space, as the Centera should single instance the rearchived data for the most part anyway

Many thanks again (very much so) - Ill mark the last post there as the solution

[Rob_Brenner]

I agree with your plan. You seem to have enough ammunition to tackle this appropriately. Let me wish you good luck, just in case.

Keep FSAUtility in mind for future administrative tasks.

Best Regards