cancel
Showing results for 
Search instead for 
Did you mean: 

FSA - query to count files in an archive

kleetuss14
Level 3

Hello Everyone,

I have an old EV9.0.2 (I know, I know...super old) environment that I'm trying to restore ALL of the files back to a Windows Server.  Just want to get the data out of EV.

I noticed that if I look at the Vault Store Usage report OR perform a search of an archive the 'total' number of files does not match what is being restored from FSAUtility.

For example if I search a target archive "USERS" with EV Search and use * the total results is 120,890 however after using FSAUtility to restore the archive I end up with only 105,019 files. The command runs with no major errors and not 15,000 errors for sure) Is this difference due to file versioning within the archive? Meaning is there possibly several versions of a given file and FSAUtility only restores 1 version of the file.

Is it possible to query the EV VS DB and get an accurate count of the items that would be restored? My goal is to prove that 'a version' of every single file was restored from the archive...I don't care about the other versions (i.e. older revs, etc) of these files just want to be sure that each unique file was restored.

many thanks in advance.

JOE

1 ACCEPTED SOLUTION

Accepted Solutions

Hi,

There are 89 entries that will have to be added since each is a separate archive. I will go through one example from the data that was received.  

Use the following to add the volume to archive reference.  Only the second number will change as the volume is the same(F$).  This is example for entry 1 in the csv file.  

INSERT INTO [EnterpriseVaultDirectory].[dbo].[FileServerVolumeArchiveEntry]

           ([VolumeEntryId]

           ,[ArchiveVEID])

     VALUES

           ('1A0F39F88C54253459E178FA0082C5CE51011000EVARCHIVE'

           ,'182BC02E515AA5F47833A4F1211F5D5F11110000EVARCHIVE')

GO

 

Once the above is run you should be able to run FSAUtility using the following format:

 

FSAUtility -t -s  "\\sint02.SAFETYINSURANCENET.COM\F$\user\Clmccormac" -d "\\sint06.safetyinsurancenet.com\F$\user"

The -d path can be any location and does not need to be an FSA target.  This should restore all of the data from that archive to the destination path as -t is always recursive.  If files exist with the same name in the path they will not be overwritten unless the -f switch is used.  However, using this could cause partial data loss if the item has been updated, but not re-archived, since the archived copy would be older and replace the updated file.  

 

Then repeat the process for each of the other archives modifying the INSERT to update the second value for ArchiveVEID.  

 

After all is complete you can remove the source volume and target.  You can also delete the archives for each of the ones that was restored to clear up storage space.  

 

Regards,

Patrick 

View solution in original post

16 REPLIES 16

VirgilDobos
Moderator
Moderator
Partner    VIP    Accredited Certified

Hi Joe,

Have you tried the options in this article: https://www.veritas.com/support/en_US/article.000017500 ?

--Virgil

Hi,

The FSA file versions would typically be the reason for this as FSAUtility will only restore the latest version of the file.  Each version will have its own entry in the SaveSet table so a count of that alone will not be correct.  The versions are not tracked with a "version" column, but by path, name, and modified date.  

You could use the attached query to show the files within the archive and then export to Excel.  You should then be able to filter by the folderpath and name to get all the unique files within the archive.  

This query works for all versions of EV, however post EV 11 the Properties value in the SavesetProperty table was modified to reduce the size.  It no longer uses XML format which reduced the entry by about 75% on average.  The case lines have been commented out for 11.x or higher.  

Regards,

Patrick 

 

I used the query you provided and exported all of the rows out to investigate.

After restoring each of the (3) folder targets I have 1,349,929 files.

The query results in a total files of 1,535,689.

The results from the query also show an old server target that was migrated off of some time ago.  The current Prod Server is SINT06.  Query results showing additional files under SINT02. These files (~92k) appear to have NOT been restored.  SINT02 is no longer configured within EV Admin Console.

Thoughts on how I can restore these from the archive?

Hi kleetus14, 

We can get the data out, however if the target is no longer in the VAC it makes using FSAUtility an issue since it will look for a target matching the name supplied.  We can use a tool to export the data or you can add the server back as a target and then the volume target.  Once that is done we can set the volume to archive association and run FSAUtility.  

A VQA output with All data from the EV server after the target and volume are added would help.  http://www.veritas.com/docs/000095758 

We can then redirect a restore using FSAUtility -t command so that it restores to a target of your choosing. 

Regards,

Patrick 

Patrick,

Thanks that sounds like a good plan to me. The old server is still on the network, I re-added it to Enterprise Vault and along with the volume (F$) that I'm looking to restore. FSAUtility gave the error "\\Server\F$" is not associated with an archived volume. Ran the VQA and attached the report.

 

Hi,

Could you also return the results of the following query as it will show the archives that should be associated to the new volume? The table is not gathered since it could be extremely large. 

USE EnterpriseVaultDirectory
SELECT RootIdentity, FolderPath, ParentFolderRootIdentity,ArchiveVEID
FROM ArchiveFolderView
WHERE FolderPath like '\\sint02.safetyinsurancenet.com\%'
AND ParentFolderRootIdentity is NULL

I will gather that now.

Quick question, would upgrading to EV 10.0.4 resolve this issue?

I just got the go ahead to upgrade it if needed to support the restore process.

Here is the output from the query.

Odd thing is this output seems to be light on folders as I only see F$\user but the other output had additional results showing F$\common and F$\everyone.

An upgrade would not resolve as the issue is with references in the DB that do not exist.  I will review the output and get back to you. 

Regards,

Patrick 

Hi,

There are 89 entries that will have to be added since each is a separate archive. I will go through one example from the data that was received.  

Use the following to add the volume to archive reference.  Only the second number will change as the volume is the same(F$).  This is example for entry 1 in the csv file.  

INSERT INTO [EnterpriseVaultDirectory].[dbo].[FileServerVolumeArchiveEntry]

           ([VolumeEntryId]

           ,[ArchiveVEID])

     VALUES

           ('1A0F39F88C54253459E178FA0082C5CE51011000EVARCHIVE'

           ,'182BC02E515AA5F47833A4F1211F5D5F11110000EVARCHIVE')

GO

 

Once the above is run you should be able to run FSAUtility using the following format:

 

FSAUtility -t -s  "\\sint02.SAFETYINSURANCENET.COM\F$\user\Clmccormac" -d "\\sint06.safetyinsurancenet.com\F$\user"

The -d path can be any location and does not need to be an FSA target.  This should restore all of the data from that archive to the destination path as -t is always recursive.  If files exist with the same name in the path they will not be overwritten unless the -f switch is used.  However, using this could cause partial data loss if the item has been updated, but not re-archived, since the archived copy would be older and replace the updated file.  

 

Then repeat the process for each of the other archives modifying the INSERT to update the second value for ArchiveVEID.  

 

After all is complete you can remove the source volume and target.  You can also delete the archives for each of the ones that was restored to clear up storage space.  

 

Regards,

Patrick 

Patrick,

Thanks very much this is working. There are also a decent number of entries on SINT02 for the common and everyone folders also....but I noticed the last query didn't have any results for them. Is that a query selection issue or are they invalid entries for data in the archive?

Hi,

I believe these would be restored in the \\sint02.safetyinsurancenet.com\F$ path and 112DD1295064C264891C3F8EBEDA4A34B1110000EVARCHIVE ArchiveVEID as those folders would fall under that path.  This is number 65 in the output.  

Regards,

Patrick 

Ah ok I wasn't sure what to do with that one...retrying the restore against that root folder.

Thanks again for all the help!

Patrick,

So the restore finished and only 29,648 new files were restored. 

I did some spot checks between what has been restored to the file system and what shows up in the original query (from FSA_items.txt) output and found missing files.

From what I can tell there is another 154,865 files that I need to restore.

I tried running FSAUtility -t -s \\sint02\f$ -d \\sint07\e$ but only files in USER were restored. The output shows 65,470 files under various subfolders in USER but only 29,648 came back.

Thoughts?

Hi,
The query would list all versions of the files so it is likely more than what would be restored to the file system as only the latest version is restored.  You could take the results and put them in Excel and then remove duplicates to see how many unique items are listed.  

Regards, 

Patrick 

Oh I didn't realize the output contained the other versions of files. I'll have a look at the output and let you know what I find.