12-13-2013 01:37 AM
Hi All,
I am currently nearing the end of a export from Enterprise Vault from the FSA side.
I have been using fsautility -t with a separate destination.
The question I have is: Is there any reason why the numbers "Number of files queued for restore" does not match the number of indexed items / number of items in the usage page?
I am seeing up to nearly 1k items difference for some archives.
The export successfully runs against the number stated in the fsautility and the number of items exported to the destination matches.
However, I fear there are items in the archive that are not even being attempted to be exported?
Cheers
CD
Solved! Go to Solution.
12-19-2013 03:56 AM
I have came to the conclusion, after painstakingly going through the files exported to PST versus files exported to the destination that the difference in numbers is due to de-duplication.
EG: 2 files called desktop.ini
Oldest file writes to destination
Newer file writes over old file.
Happy with this discovery. Even though it was painful to find out. Would be nice if this was documented.
12-13-2013 01:52 AM
I have ran fsautility -t and -c in report mode and all the numbers match up to each other but still not to the number of items listed in the usage page or number of items indexed.
12-13-2013 02:23 AM
Sorry to keep commenting on my own thread.
I have just ran a export to PST using the archive export wizard and this exports the entire archive (The same number as stated in the usage page).
Although there is a way to ensure all files are returned using this. This is not a viable solution. As it will be very time consuming and involve a lot of man hours, will it not?
Does anyone know of any way that the FSAutility -t will export all the files available?
Cheers
CD
12-16-2013 06:29 AM
In FSA, most of the times huge files do not get Indexed and only the metadata of the file is Indexed. The Index engine has a retry count of 3 and if it cannot index the item, it will skip and proceed to the next.
I suppose, that would be the reason for the numbers not matching.
http://www.symantec.com/business/support/index?page=content&id=TECH204591
You can check with support as there is an internal script(FSARecall) to recall files in bulk.
12-16-2013 06:45 AM
Hi,
Have you checked the index volumes for this FSA archive to confirm if there are items waiting to be indexed and/or to be removed? If you have issues with the indexes on this archive, then the results will not be accurate:
How to determine why deleted items are still being shown in Enterprise Vault (EV) Search results
http://www.symantec.com/docs/HOWTO56258
12-16-2013 06:46 AM
Also, if the PST export matches the FSA restore, I would think that something is not right with the index.
12-17-2013 03:30 AM
Hi Guys,
Gabe, I have synchronised, upgraded and rebuilt the indexes of any affected archive. Also, the PST export exports a larger number to the FSA utility (the required amount).
I am going through these PSTs looking for discrepancies and so far it looks like the difference is caused by FSA utility de-duplicating any items with the same name.
However, I am yet to prove this as there is 1 archive with a 900 item difference, so If I can determine that all these are duplicates, I will be happy.
However, in response to Varghese - There are a number of archives where your suggestion seems to add to the problem.
1 particular file is 12.5MB and I can not open this through archive explorer. I am currently looking into a reg key that will allow me to open and then export files such as this succesfully
Cheers for your help guys.
12-19-2013 03:56 AM
I have came to the conclusion, after painstakingly going through the files exported to PST versus files exported to the destination that the difference in numbers is due to de-duplication.
EG: 2 files called desktop.ini
Oldest file writes to destination
Newer file writes over old file.
Happy with this discovery. Even though it was painful to find out. Would be nice if this was documented.