cancel
Showing results for 
Search instead for 
Did you mean: 

FSA Utility "Number of files queued for restore"

ChayDouglas
Level 4
Partner Accredited

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

1 ACCEPTED SOLUTION

Accepted Solutions

ChayDouglas
Level 4
Partner Accredited

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.

View solution in original post

7 REPLIES 7

ChayDouglas
Level 4
Partner Accredited

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
Level 4
Partner Accredited

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

VargheseR
Level 3
Employee Accredited

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.

GabeV
Level 6
Employee Accredited

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

GabeV
Level 6
Employee Accredited

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

ChayDouglas
Level 4
Partner Accredited

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
Level 4
Partner Accredited

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.