Forum Discussion

Mark_Harford's avatar
14 years ago
Solved

Restore FSA data without original server present

Hi all,

I have a situation with a customer who at some point last year moved all his data from an old server, FS1, across to two new servers, FS2 and FS3.  This data had been partially archived and so all the placeholders were moved across at the same time.  I believe the data was moved by a mixture of dragging and dropping and also backup to tape with a redirected restore.  At no point was FSAUtility used and many of the placeholders do not now work.  The old server has also now been decommissioned and the target entry for it in the Vault deleted.

What they would now like to do is export all the archives to a location on the file server from where they can always get the files if need be so I thought let's use the following:

FSAUtility -t -s "fs1.domain.com\share1" -d "fs2.domain.com\share1" -l 0

BUT this gets the following error looking for the old server:

FSA Data Mover Utility.
Symantec Enterprise Vault.
Copyright (c) 2010. Symantec Corporation.

Restore files
Source : \\fs1.domain.com\share1
Destination : fs2.domain.com\share
Error: Invalid fileServer \\fs1.domain.com

Is there a way around fsautility looking for the old server?  I just want the data out, it really doesn't matter if the data slots neatly into an existing folder structure.

Thanks

Mark

  • im not sure how much help support can be as they're technically a break/fix organization, this really falls under the realms of professional services to be honest

  • i know this will sound a little ridiculous, but on the File server could you create the share, then on the EV Server just get the hosts file to point fs1.domain.com at the ip address of fs2?

  • Hi thanks

    Unfortunately that has not helped.  I think it is expecting to correlate the source path with a live server that still has the archive point as a valid target.  

    As it's very quick to build a new server from a template, one thing I have tried is to create a new server called FS1 and add it as a server to EV with the placeholder service.  I then created a test folder and archive point matching the old ones, albeit empty, and ran the command again.  However I now get the following:

     

    FSA Data Mover Utility.
    Symantec Enterprise Vault.
    Copyright (c) 2010. Symantec Corporation.
     
    Restore files
    Source      : \\fs1\share1\
    Destination : \\fs2\share1\
    Error: The path \\fs1\share1\is not associated with an archived volume. If you migrated placeholders to this location, let the File System Archiving task process the volume, then stop the task and re-run this command
     
    I created and ran a task against the new share / archive point but i still get the same message so I think perhaps I shouldn't go any further down that path.
     
    Recreating placeholders into a blank folder structure with the fsautility -c option also does not work.
     
    FSAUtility really does expect the original server to be there.frown
  • Not sure if this will do is, as I haven't been able to try it out, but I wondered if the "-b" option in FSAUtility would work?

    The Utilities guide says the following:-

    You can use FSAUtility with the -b parameter to recall files corresponding to

    placeholders present in a folder. This facility recalls the placeholders in a given

    source folder, irrespective of the volume and archive in which the files are located.

    It also works with placeholders that you have copied into the source folder from

    another folder. 

     

    Might be worth a look?

  • I was about to try that when I discovered that the new servers a) don't have the space to take all the data back (several TBs) and b) some placeholders no longer exist so what the customer wants is to redirect the restore to yet another drive/share on the new server.

     

    It comes back to needing a simple export utility direct from Archive but obviously not to PST.

  • Hmmm. Bit of a stumbling block with your comment about the lack of space - surely this is going to impact whatever method you find to use?

     

    I worked on a case a while back whereby we had to engineer our own way of doing something similar to recalling data from the archive, but not using FSAUtility as it had some problems and wasn't quite what was needed. This consisted of some scripting etc, but was very involved. There was also something similar done using Powershell. (the method was using some SQL to get a list of "To Do" stuff, then using a hook into a recall object)

    You could log a case with Support to see if they could help here, but if you don't have space to begin with then I don't see how you are going to accomplish this task.

  • im not sure how much help support can be as they're technically a break/fix organization, this really falls under the realms of professional services to be honest

  • Thanks for your comments.

    We have raised a support ticket and they are being very helpful suggesting a number of things to try to get FSAutility working . Since I did have the opportunity to rebuild a server with the original name and I can now present some decent storage to it, we are looking at options using that server including looking at/editing the GUIDs in the ADS xml files to match what is in the database.

    The in-house IT guys at the customer have now taken this on so I may not be able to feedback much on what if anything fixes this but at least we have a way forwards.

    Worst case a) they now reckon there are some 2-3 year old off-site backup tapes taken prior to the initial archiving runs and b) export to PST could be used to a limited degree for smaller groups of files needing recovery.

  • @JesusWept2 - unfortunately 'we' don't have a Professional Services anymore, but thankfully do have some great Technical Support Partners.

    I agree that Support is primarily a break/fix but we do, in some instances, try to help where we can.

     

    Hope it goes well Mark!