Video Screencast Help

FSA Utility "Number of files queued for restore"

Created: 13 Dec 2013 • Updated: 19 Dec 2013 | 7 comments
ChayDouglas's picture
This issue has been solved. See solution.

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?



Operating Systems:

Comments 7 CommentsJump to latest comment

ChayDouglas's picture

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.

ChayDouglas's picture

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?



VargheseR's picture

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.

You can check with support as there is an internal script(FSARecall) to recall files in bulk.

GabeV's picture


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

“Success is not final, failure is not fatal: it is the courage to continue that counts.”–Winston Churchill

GabeV's picture

Also, if the PST export matches the FSA restore, I would think that something is not right with the index.

“Success is not final, failure is not fatal: it is the courage to continue that counts.”–Winston Churchill

ChayDouglas's picture

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.

ChayDouglas's picture

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.