Enterprise Vault Restore Issues
Have a very strange problem regarding EV v11.0.0.1470. My task is to restore all archived EV data to a new share. I am running the following FSAUtility commands: FSAUTILITY -t -s "\\oldserver\share...
Forum Discussion
Hi cornishtechie,
As GertjanA stated this could be from users moving the shortctus from one folder to another. If this is done on the same volume the items are not recalled and the recalls will work properly. EV does not perform moved item reconcilliation on FSA archiving so EV would only know the original location of the items and the FSAUtility command would restore the items to that location path and not the current location path.
Since there is only one file in the archive at that location that is the only one that would be restored to that folder. If you perform a search for the other 9 items in EV Search or view in Archive Explorer/EVS view you should be able to find the those files original location.
Regards,
Patrick
Thank you you both GertjanA and plaudone1 for taking the time to reply in good detail.
As an example, so I understand you correctly;
- A file is created on the \\server\share1
- EV archives file based on archive criteria
- Replaces file with a placeholder
- 6 months later, user opens the placeholder to restore the file
- File is successfully restored by EV and opened by end user.
- The file is then moved to a new location \\server\share2
- EV then runs the archive task
- File is then rearchived, but the file location in the EV DB stays as the original share \\server\share1 ?
I have searched for one of the files, and as you mention, it has been restored to what looks like its original location. Is there an attribute attached to a file that tells EV 'this file has already been archived and lives here in the DB' (technical way of putting it!) ?
My concern now, is that if User A has spent 2 years reorganising folder structures in the share that EV is archiving, then I come along and restore EV data, EV then restores as it was 2 years ago, users are not going to be able to find there data as its technically undoing the folder structure and reverting back 2 years.
Please correct me if I am wrong...
Many thanks in advance.
Hi,
That is mostly correct, expect if a user recalls an item and then moves it to another folder, it will be archived in that location as well. The item would appear in both folders, however should only be one full item on storage if it has not changed.
The issue is when users move the shortcuts(placeholder) from folderA to folderB. If the folder is within the same volume(such as their user share) then a recall will not be performed. Since the item is still a placeholder and has the offline bit and reparse data(used to recall the item from EV) it is ignored during archiving. EV would only know that it existed in folderA and that is where it would show in search and what FSAUtility would restore. The moved placeholder will still open the item as it is only a pointer to the item in EV and not contingent on the folder location.
A restore would undo any moves that the user performed of the shortcut items. Currently FSA does not reconcile changes on the file system the way it does with mail items. It would be better to recall the data using the -b option as that will search for items in the current location on the file server and then restore to that location. The data could then be moved/re-archived and EV will have the pointer to the current folder. This would maintain the re-organized folder/item structure.
Regards,
Patrick
Hello again,
The below is also possible, and is what I am meaning.
1.A file is created on the \\server\share1
2.EV archives file based on archive criteria
3.Replaces file with a placeholder
4.6 months later, user moves the placeholder to 'somewhere else'
5.The file location in the EV DB stays as the original share \\server\share1You wrote initially that you looked in the archive, and saw that 1 file. This indicates that what you see on the share means the shortcuts have been moved. and yes, if a user reorganized structure, your restore will totally mess that up :-). See answer from Plaudone however, use an option to restore item to the location where the shortcut is.(if possible seeing diskspace etc)
If you have in a folder 6 shortcuts, but only one item in the archive, this means 5 items are in another archive. You should be able to find (see entry earlier in thread) in which archive (i.e. location) the items are.
Thanks again to you both for replying. I understand what you are saying.
My problem is that our shared drive (where EV has been archiving for the past 3 years) is out of space and our aim is to decommision EV due to other infrastructure plans. I do not have enough room to restore all archived data via the -b switch to the current drive.
To add insult to injury, previous IT guys formatted the drive as MBR not GPT so I cannot just add additional drive space.
Trying to find the right method to move data to a new volume and then restore EV data (keeping current folder structure\file location) is prooving to be very complicated for such a simple task.
I need to find the time to test this, but would a restore using the -b switch to a temporary NAS restore all EV data with the current folder structure? Or does -b only restore to the placeholder location?
Example:
FSAUtility -b -s \\server\oldshare -recurse -d \\server\newshare
Thanks
