Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.

File System Archive retrieval and Shadow Copy

Created: 25 Jul 2013 • Updated: 14 Aug 2013 | 12 comments
This issue has been solved. See solution.

Howdy folks, I have been looking at a problem involving FSA, and the retreival of a .DOC file

The problem includes the variable of Volume Shadow Copy

In short then, a .DOC is archived and a placehodler left in situ. Placeholder is accidentally deleted by user, but to mitigate this, Shadow Copy is being used to provide redundancy

So user recovers Placeholder from Shadow Copy and tried to retrieve item and is faced with the following error:

VSS_0.PNG

Has anyone got any pointers for this one

I can see from Google and the EV compatibiltiy list that VSS is support (EV9 & 10)

I looked at Pass Through Recall, but it was greyed out at the server level and I couldn'ty see anything at the site level

I guess my first question is, do I start troubleshooting this from the Shadow Copy perspective first? If I dTrace, what Task Category should I use - Storage?

Operating Systems:

Comments 12 CommentsJump to latest comment

JesusWept3's picture

The item is definitely in the Archive still right?
I mean do you have anything like Delete on Delete where you delete the placeholder, it deletes the archived tiem? so if you went to AE  or Search, can you see the item and open it?
 

Pradeep_Papnai's picture

The errors seems to coming due to shadow copy on but pass throw recall is enabled (http://www.symantec.com/docs/TECH170289) Now as you said, pass-through recall is gred out, This particul problem comes due to DCOM, EV licenses,...etc issues.

Can you please take dtrace on MMC and go to file server's properties from VAC?

GabeV's picture

This issue seems to be the same TN that EV-Conselor pointed out. A dtrace of the EvPlaceholderService in the Windows file server should be sufficient to confirm that issue and to determine if you need Pass-Through Recall enabled, Also, you can try to use FSAUtility to restore the placeholders as a workaround.

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

casini's picture

I've overlooked something rather basic here (I'm a little embarrsed to admit)

In answer to question 1, I haven't actually looked for whether it still exists

Let me confirm this and move to the other suggestions thereafter - I'll report back shortly

Many thanks for your help

Pradeep_Papnai's picture

Dtracing on EvPlaceholderService is definately useful to know exact error (most probably it would be 'Error 0x800710FE')

Before going to file server, I would say to fix "Pass through recall" option greyed out perspective as this is requirement for file server where Shadow copy is enable.

Dtracing simply on 'MMC' on EV would be sufficient to know exact issue, In order to reproduce it, start dtrace on MMC and open VAC (Vault admin console) on EV server, right click on file server's properites and close VAC.

I had two issue recently due to same problem, one was resolve by applying correct license and secnod was resolve after fixing DCOM errors. Following lines in dtrace can be seen if pass-through is grey out.

CAUIFileServerGeneralPage::EnablePassThroughIfSupported - IsPassThroughSupported() unable to determine if Pass-through recall supported on this file server

You can upload dtrace if further assistance require.

casini's picture

Hi folks, I have done some more work on this case and can report the following:

DTrace of MMC and EVPlaceHolderService attached

Ran Dtrace through Jiggle, which didn't throw any errors EV~ errors - I've attached a copy anyway

BUT there are references to - Failed to get .exe name for pid [4] using IPlaceholderSvcHelper, error: 0x80070005

I checked Pass through recall - Site/Target/File Server/Specific Server/Right Click/General and contrary to the Admin who rasied it with me, this config is NOT greyed out. That being said though, it's not configured either, so I tried adding a few paths, but this didn't resolve the issue

Also, I suggested to the customer they restore the file using FSA Utility, but we received the following:

120px_FSA Utility.jpg

I'm assured the item should still be available, as policy is to allow Placeholder deletions but not files, so I'm thinking the next thing I should do is take the saveset ID's registered in the DTrace and use that to try and find the file in SQL using the following query:

USE EVVSYourVaultStore_01
SELECT IdTransaction, ArchivedDate, idDateTime FROM Saveset WHERE idTransaction = ' valid transaction ID, it needs to be 36 characters, and is formatted like 8-4-4-4-12'

Worth mentioning as well there are no Errros/Warnings in the event log either

That should demonstrate if the file even exists right? If it does, can anyone suggest some next steps to try, before I log a Symantec case?

AttachmentSize
818920_31072013_Fraser_3.txt 20.17 KB
Pradeep_Papnai's picture

I do see expected lines in EVPlaceholder dtrace, However I would also suggest you to take dtrace on W3WP, StorageOnlineOpns from EV server & EVPlaceholder component on FS then reproduce this issue.

Logging case with support with above information would be worth.

The best way to confirm if file exist or not is via Archive explorer.

casini's picture

Update to this as follows:

Ran the following in DumpSaveSet

DumpSaveset 1B0D4A94F6DC33D4F987CCCB2DA5DA54D1210000EVSERVER2 201202088660790~201102020952090000~Z~006A1B89B9A700FF7F7C3189C9939F01 -o C:\test

I got a positive result and can therefore prove the file exists - so the error is not down to the file being deleted

Symantec recommended the following as next step

Then if the file IS still there then I would suggest recreating the placeholder with FSAUtility, sometimes FSAUtility needs to use the FQDN of the file server, plus it also has to match the entry in the SQL tables, to find out what that is run the below query:-

use enterprisevaultdirectory

select DnsName, UncName, PassThroughDiskCacheLocation

from fileserverentry

this gets me the FQDN of fraser.lesoco.local

So the next step once this has been reviewed by Symantec is to recreate the placeholder [using FSAUtility] using the now established FQDN

When I have further information, I'll post here until solution 

Pradeep_Papnai's picture

Thanks for update Casini, you can get information on recreating placeholders from TN http://www.symantec.com/docs/HOWTO37834

Run it against few test folders to see if placeholder can be recall, Example syntax

FSAUtility -c -s \\myserver\users -l 0 -r

I hope the similar suggestion would come from support as well.

Regards

EV-C

Ben Watts's picture

The above is correct.

Usually FSAUtility references the FileServerEntry table to convert the Servername to FQDN name so if we are tripping up there then we will need to look into the entries in that particular table.

Similarly, if you are still having issues in recalling the file with FSAUtility, if it is ONLY that single file that you need, now that we have recalled the file via Dumpsaveset, simply restore that file over the placeholder.

Ben Watts's picture

Just to add to the above, when you are trying to recall via a Shadow Copy placeholder you need Pass-Through recall enabled.

Try changing the location of the Pass-Through folder to C:\PassThrough (no spaces), restart the Placeholder service (as a precaution) and try again.

About Pass-Through Recall  -  http://www.symantec.com/docs/HOWTO49546

SOLUTION
casini's picture

Morning all,

What seems to have sorted this issue is the last recommendation - I went back to the Pass Through Recall configuration and followed the provided TechNote. This was something I had previously looked at and tried configuring, but didn't work - it looks likely I made a mistake somewhere

By going back, following the Technote (but also changing the temporary restore folder) immediately resolved this problem

Thank you very much for all help