Did you remember to check the box  Overwrite existing files ?

A bit more information would be handy ....

NetBackup versions, type of restore (file system, exchange, VM etc.)

On the client you ran the restore from go to the BAR console and click on the View Status button

In the box that opens up click the verbose radio button and then refresh

If you could them copy and paste all of the details for the restore onto here is will give us a better idea of what is going on

Thanks

Not if it is a new empty folder - as long as you have write rights on the client

Please post details as per my earlier request so that we can see what exactly is going on here

It may well be the stuff above that I need to see

And No, I am not sure what you mean about the drives not being visible on the client?

If you mean that this is a cluster and you are running the restore to a shared drive then it needs to be directed to either the virtual name of the active node for it to work

Can you set up a \netbackup\logs\tar\ directory on the client and run the restore again and then post the resulting log (all of it please)

Thanks

Yes, more details needed.  You're restoring from backup of H: which I guess is a shared drive. 

Is this "restored Data" on local drive? 

* edit*  oh, I see more posts now.  Why is the forum so slow to refresh today?  * edit *

Anyway, still need more details as Mark and I suggested.

There is no evidence in the info provided that Restore folder was specified as destination folder.

Please ensure that tar log exists on client as well as bprd on the master server. (NBU needs to be restarted after creating the bprd folder.)

Please do screenshot of restore destination screen and post as attachment.

Please also post client's tar log and master's bprd as attachments.

Hi Guys

Thanks for all the input yesterday, as per usual i got dragged away to "a more important" issue...some day i wanna be the guy that decides the importance of these things :), anyways ill get to work on gather that info and many thanks for the help!!!

Declan

Hi Guys

Ive put together the info as asked, or at least i hope as asked!!

Everything is attached..any advice on these logs is appreciated, ive never encountered restore issues from these file servers before, normally its never an issue!!

Declan

Seems as if something is going wrong with the 'rename' file. Does ALTPATH exist in the logs folder on the client?

Please find this file one the client and post contents:

D:\Veritas\NetBackup\logs\ALTPATH\.rename.9348

As well as these 2 files on the master:

E:\Veritas\NetBackup\Logs\user_ops\cld1\noonan_d1\logs\jbpCFC3.tmp.log

E:\Veritas\NetBackup\Logs\user_ops\cld1\noonan_d1\logs\jbpCFC3.tmp.chg

I dont like the sound of this :)

Thanks for getting back, ive uploaded the files you requested, well ive tried...it doesnt seem to play nice with these types of files!!

of course zipping it would never occur to me.....my apologies :)

It may be how I am reading things but you say restore to H:\....

But when tar does its initial check if finds C, D, E etc., but no H drive:

10:11:00.151: [6160.9372] <2> ov_log::V_GlobalLog: INF - DumpDleInfo() DLE Device Name: C:
10:11:00.151: [6160.9372] <2> ov_log::V_GlobalLog: INF - DumpDleInfo() DLE Device Name: D:
10:11:00.151: [6160.9372] <2> ov_log::V_GlobalLog: INF - DumpDleInfo() DLE Device Name: E:
10:11:00.151: [6160.9372] <2> ov_log::V_GlobalLog: INF - DumpDleInfo() DLE Device Name: Microsoft Terminal Services
10:11:00.151: [6160.9372] <2> ov_log::V_GlobalLog: INF - DumpDleInfo() DLE Device Name: Microsoft Windows Network
10:11:00.151: [6160.9372] <2> ov_log::V_GlobalLog: INF - DumpDleInfo() DLE Device Name: Symantec SNAC Network Provider
10:11:00.151: [6160.9372] <2> ov_log::V_GlobalLog: INF - DumpDleInfo() DLE Device Name: Shadow?Copy?Components
10:11:00.151: [6160.9372] <2> ov_log::V_GlobalLog: INF - DumpDleInfo() DLE Device Name: System?State
10:11:00.151: [6160.9372] <2> ov_log::V_GlobalLog: INF - DumpDleInfo() DLE Device Name: Active Directory Application Mode

Have you directed the restore to the correct client and to the correct location as it doesnt look from the TAR log like it has a H drive

Hi Mark

The H: drive would be a san attached drive so not local, if i log on to the client i see the disks as in the picture ive attached. Also in the policy it has no issues in backing up H:\, so i kinda presumed it wouldnt have an issue restoring to it...how wrong i was!!

OK lets just try a couple of things

1. on eadfop062v check that it has a valid temp / tmp directory (type "path" in a command window and make sure the locations given actually exist.

2. Try the restore running it from the client itself using its BAR GUI

Let me know how this goes

Hi Mark

here's the results of the "path"

C:\Users\noonan_d1>path
PATH=C:\Windows\system32;C:\Windows;
C:\Windows\System32\Wbem;
C:\Windows\System32\WindowsPowerShell\v1.0\;
C:\Program Files (x86)\Dell\SysMgt\oma\bin;
C:\Program Files (x86)\Windows Imaging\;
D:\PROGRA~1\BMCSOF~1\Patrol3\bin;C:\xpyv\;C:\xpyv\Scripts;
C:\Program Files\XIV\host_attach\bin\;
D:\Veritas\Volmgr\bin\;D:\Veritas\NetBackup\bin\admincmd\;
D:\Veritas\NetBackup\bin\;

C:\Users\noonan_d1>

Also when i start up the BAR from the client the only available drives are as in the screen attached, i think this is because when i log onto the client headfop062v, its just bringing me to the physical its hosted on in the cluster, in this case the physical is headfop011c.So from here i can not select the H drive, i normally do it from the master java as i think this is where the cluster config was done so that where i can see the H: from, another thing that may help, is that i went up a couple of levels to here "H:\Groups_H\Networks_H\cs_psm" and i could run a restore using my normal method with no issues...could it be some security setup on the folder??

First apologies for giving the wrng comand to check the temp variable - it should have been "set"

It could be a security issue - being a user operation it will perform the restore as yourself locally or as the NBU Client service if done from the Master.

If you can run it at a higher level then check to see what the NBU Client service account is running as (if anything) - just interesting that the backups are successful - this indicates that it has read rights but not write rights to that level.

I have seen issue similar to this with Winodws 2008 where a local or domain admin seems to mean nothing if specific righst have been placed on a folder

Did you actually create the Restored_Data directory before running the restore? Perhaps it just cannot create the directory?

No i never create the restored_data folder, i just name it as the destination and it always creates itself, im completely stumped as other restores from the same drive are working fine......nightmare!!

Can you actually log on to the server and create it?

Does the NBU client service use a specific account?

The nbu service uses the local account, like all our nbu services, im not thinking its the service as other restores from the same drive have no issues, Im going to create a "restored data" folder now and see if it drops the file into it

ok, now this makes no sense to me...none...but here goes :)

I went and created a restored data folder, and ran the restore and it didnt work, this much we know.

so what i did was try to restore another file along with the actual file i want......but from a folder listed higher up the same directory, so the file i want is in "hr_folders" and the other file ive selected is in "call_out_register" as per attachment

Unbelieveably the 2 sets of folders have dropped into the "restored data" folder, its almost like the file i want has piggy backed its way to where we want it...............im am baffled......anyone any ideas to save my sanity??

i have the file i need...but how...and why..and how do i explain why its taken me over a day to get a restore :)

I can only assume that this is caused by the folder hierarchy in some way.

I am surprised it would not restore to the newly created restore_data folder though

On its own it would restore the file to that folder - with multiple files it would restore to sub folders under that folder (is that how it did it?)

must be something to do with that  - but all does seem very odd!

I will give it more thought and get back to you if i have a flash of inspiration

Thanks Mark

Just to clarify...on its own it would not restore to the restored data folder.

With another file also selected in the BAR it restored to the restored data folder just fine...can we call this a workaround :)

AH! A "Feature"

I would still like to see a debug level 5 of the tar log for the restore that doesnt work - but only if you have time

Are there any mount points under the H: drive?

Does the logon account for the NBU Client Service have write permission on these folders?

Morning Guys

Marianne, yes there is a mount point under the H drive, under the H: drive you will see a shortcut to MP_H which is the mount point drive, i didnt include the mount point in my original explanation as the restore was coming from the regular H, do you think it could have an impact?

And yes the nbu client service is using the local account which all the way down the drive directory has write permissions, and my own admin account which im performing the restore from has access all the way too!!

Mark

Ill get the debug level up to 5 and run it again...expect a log shortly!

Folks

I switched the verbose on the client to 5...hope thats all that was needed, file attached!

Not much in the log apart from:

GENERAL Log Level: 0

TCP Log Level: 0

Where did you change the logging level?

I changed it in the client, troubleshoot properties and set ver bose to 5, do i need to set anything else?

Set general to 2 and verbose to 5

Then connect to its host properties from the Master Server to make sure it shows 5 - if not then it is connecting to the wrong client

gotcha.....setting it up now!

:)

now that looks a little better

The only thing that sticks out is that it says :

12:38:01.541: [4100.11456] <2> tar_base::V_vTarMsgM: MNR - The following file was kept:

12:38:01.541: [4100.11456] <2> tar_base::V_vTarMsgM: UTF - H:\Groups_H\Networks_H\hr_folders\HR Activity\Resource Planning\Reviews & Analysis\2012\JAN10th 2012 MASTER LIST excl VS.xls

Which indicates that it did not accept the rename to your alternate location or ignored it - which is odd as it does mention the rename file:

D:\Veritas\NetBackup\logs\ALTPATH\.rename.12016

which indicates it intends doing a rename - everything else looks ok really - have you tried changing the netbackup client service account to see if that affects it? As i said earlier I have seen some odd things with rights issues on 2008 - or set the destination as HEADFOP011C (which I assume is the active node name) as it does a lot of disk checking in the log to see what is valid and what is not so perhaps the virtual cluster is causing issues - although why selecting a second batch of files overcomes this works is something else

Last questions - are these backups from normal file system backups or snapshot / flashbackup backups? and do you have any exlcusions set on the nodes

 Any exclusions set

OK so ive put the logging back up and ran 3 more attempts

headfop062v to headfop062v

headfop062v to headfop011c using a different account for the client service

headfop062v to headfop062v using a different account for the client service

and ive attached the tar log which should contain all 3 attempts.

Ive also attached the exclusion list which to my knowledge is pretty default.

And these are just your average run of the mill bog standard ms-windows policies apart from the cluster being invloved the netbackup setup couldnt be more basic :)

Ok, as Marianne suggested initially I am going to suggest that this is being caused by the mountpoint

The log reads:

14:11:13.743: [11528.9548] <4> UnpackerTAR::processDataHeader(): INF - Object LF type is (84).
14:11:13.743: [11528.9548] <2> tar_base::V_vTarMsgM: TAR - H:\Groups_H\Networks_H\hr_folders\HR Activity\Resource Planning\Reviews & Analysis\2012\JAN10th 2012 MASTER LIST excl VS.xls
14:11:13.743: [11528.9548] <2> tar_base::V_vTarMsgM: MNR - The following file was kept:
14:11:13.743: [11528.9548] <2> tar_base::V_vTarMsgM: UTF - H:\Groups_H\Networks_H\hr_folders\HR Activity\Resource Planning\Reviews & Analysis\2012\JAN10th 2012 MASTER LIST excl VS.xls

LF type (84) indicates the mountpoint and there are know issues in restoring data to mount points.

This doc covers it (without resolution) http://www.symantec.com/docs/TECH158950 and although covers recovering an entire volume I think this is where the issue lies

I still cannot explain the change when you restore two files to the mount point directory but I have the feeling that you should be able to restore it almost anywhere except to that directory!

Unless anyone has any other ideas I guess the only way to know for sure (if ever) is to log a call with Symantec

Hope this helps - sorry I couldn'd do more.