Video Screencast Help

EV FSA Archiving - Recall Problem where source folder deleted

Created: 12 Sep 2012 • Updated: 03 Dec 2012 | 9 comments
SYMAJ's picture
This issue has been solved. See solution.

I have a site where the customer is running EV8 FSA / Email archiving, and I am having problems when trying to run FSAUtility to recall a directory.

The site have deleted the directory some time ago, and wish to recall all of the files back again.  When accessing the archived folder through the ARCHIVEEXPLORERUI.ASP web interface I cannot see the archived share (I can see some other archived shares OK), even though I am signed on as the VSA so should have access.  Just to be sure I added the VSA to the permissions tab in the Archives tab of the admin console for the archive in question  - but no change when viewing through the web-app.  I also synchronised via the FSA task.  I have not restarted IIS.  I did logoff / logon.

If I do a search archive from the archives tab in the admin console I do see the folder I am interested in and can see all of the items within it OK - but obviously cannot recall from there (and there are many sub-folders / files to restore so not feasible).

I don't see why I cannot see the V$ archive through the Web-App (I can see 3 out of 5 of the FSA Archives in the web-app), but can see it and search it in the Admin Console.......

I tried running the FSAUtility as follows (signed on as the VSA):

FSAUtility -t -s \\server_name\volume\directory -d \\new_server\new_share -f -r

\\server_name\volume\directory above was the original directory I am looking for.  The archive point was at the volume level.  This directory no longer exists on the fileserver, although the archive still holds all the data.

I thought this should restore the files to the new share - although with the -r I was trying in report mode first.  All I get is an error message INVALID USER SWITCH FOR THE -t (Restore original files) OPTION.

Will this utility only restore files where the shortcuts already exist in the original folder (and must the original folder exist), or should it simply pull back all of the files which were archived from the original directory ?  I understood it should query the EV database and restore all files which were archived from the specified directory.

Am I missing something here ?

What is the correct way to 'bulk' restore files from the archive in EV8 where the original location no longer exists ?

Also, when I can get this to work is there a way to achieve the following.  The archive runs from the root of the V$ drive, and my directory is underneath that level.  My directory contains many subdirectories, and if possible I want to be able to specify to restore only subdirectories beginning H thru Z (i.e. don't want ro restore subdirectories beinginning A thru G).  Is this possible ?  If not I will restore all and simply delete the ones I don't want.



Comments 9 CommentsJump to latest comment

chetan_k32's picture


Can you recreate the directory in source again with same name and then try with fsautility

SYMAJ's picture

I could potentially recreate the original volume and path, and had already thought about this - but am unsure i this will progress the situation.  Do you feel it will allow the restore to progress (either via RMC - Restore to original location from Web-App or FSAUTILITY) ?

One more update - I can now see the archive under the Web-App, it was a permissions issue.  However, when RMC on any of the documents I get the option to RESTORE TO ORIGINAL LOCATION (no option for alternate location), but if I do select this it just progresses as if it had worked but restores nothing - I guess as the original location does not exist.


ZeRoC00L's picture

If you update the database with the new location, you can restore the placeholders with the fsautility.

If this response answers your concern, please mark it as a "solution"

SYMAJ's picture

Thanks for that - I will take a 'deeper' look at this option.


Topper454's picture

Hi AJ,

I had an issue with duplicate named archives one on a currrent server and one on an old server that was powered off.

After several attempts to restore items from the archives using FSAUtility I attempted to modify the database.

This failed and a Symantec employee in this forum suggested recreating the old server as the there were too many entries in the databases to reconfigure.

This was done and after the archive points were recreated, items could then be copied manually from the archives using  archive explorer.

I am still resolving DNS issues so have not yet succeeded using FSAUtility.

Hope this is of some help,


Topper 454

TypoProne's picture

Just checking to see if this was resolved. You have some great suggestions here that I assume resolved your issue. If it did please mark the appropriate posting as being the resolution to your issue so that the resouces attempting to help people on this forum do not pop into a thread where the assistance is no longer needed. 

This can be a pain... and the suggestions I see above are where I would start. I was suggesting that the permissions was the issue with AE (Permission browser is what you would use to really dig into this one for future reference) and glad you got that sorted. 

The solution for getting your content back depends on some details and the extent of the issue.Both of the reccomendations above are viable IMO and may be prefered depending on the circumstances. 

If you have sorted this ... please flag it properly... if not and you still need assistance... please let us know where you are now and what the end goal is and what direcion you are headed. 

Many thanks

SYMAJ's picture

After looking into the various options with the client, and taking into account the time and effort involved, the client made the call that as they were only interested in a small number of items they would open them up and re-save (via the archive explorer).

I would have liked to bottom this one out but unfortunately had to stop at that point.  I felt that having to recreate the original server & share was over-kill (not saying it wouldn't work), and there should be an option within the utility to cater for this type of event.


TypoProne's picture

Thanks for the update. I think that your concers related to the methodoligies to deal with this sort of situation and a couple of other similiar situations is one of the challenges of FSA. I am not sure but I think SYMC is aware of this and hopefully seeking to recity some of these shortcomings. I have seen several situations where that overkill solution was confirmed to be the only one possible for resolution.

I am not sure if that was the case in your situation. Thanks for the update. If you can flag your (or someones) posting as the solution that would be awesome.

Thanks again.