01-07-2014 09:49 AM
We are currently having an issue when restoring backups of our NDMP connected NetApp. We have successfully backed up the data, but there seems to be an issue with any restore of that data.
We have confirmed that the NDMP resource is reachable:
C:\Program Files\Veritas\Volmgr\bin>tpautoconf -verify plumfas02
Connecting to host "plumfas02" as user "netbackup"...
Waiting for connect notification message...
Opening session--attempting with NDMP protocol version 4...
Opening session--successful with NDMP protocol version 4
host supports MD5 authentication
Getting MD5 challenge from host...
Logging in using MD5 method...
Host info is:
host name "plumfas02"
os type "NetApp"
os version "NetApp Release 8.1.2 7-Mode"
host id "1574505273"
Login was successful
Host supports LOCAL backup/restore
Host supports 3-way backup/restore
We have confirmed that the NDMP is listed with the FQDN:
C:\Program Files\Veritas\Volmgr\bin>nbemmcmd -listhosts -verbose
NBEMMCMD, Version: 7.6.0.1
The following hosts were found:
plumnbu01
MachineName = "plumnbu01"
FQName = "plumnbu01"
MachineDescription = ""
MachineNbuType = server (6)
plumnbu01.plumbedford.local
ClusterName = ""
MachineName = "plumnbu01.plumbedford.local"
FQName = "PLUMNBU01.PlumBedford.local"
GlobalDriveSeed = "VEND:#.:PROD:#.:IDX"
LocalDriveSeed = ""
MachineDescription = ""
MachineFlags = 0x17
MachineNbuType = master (3)
MachineState = active for tape and disk jobs (14)
NetBackupVersion = 7.6.0.1 (760100)
OperatingSystem = windows (11)
ScanAbility = 5
plumfas02
MachineName = "plumfas02"
FQName = "plumfas02.PlumBedford.local"
MachineDescription = ""
MachineFlags = 0
MachineNbuType = ndmp (2)
plumfas01
MachineName = "plumfas01"
FQName = "plumfas01.PlumBedford.local"
MachineDescription = ""
MachineFlags = 0x1
MachineNbuType = ndmp (2) (snapvault)
Command completed successfully.
However, we continue to receive failures whenever a restore is attempted:
1/7/2014 10:37:33 AM - begin Restore
1/7/2014 10:37:34 AM - 1 images required
1/7/2014 10:37:34 AM - media 000278 required
1/7/2014 10:38:07 AM - restoring image plumfas02_1388786329
1/7/2014 10:38:07 AM - Info bpbrm(pid=8828) PLUMNBU01.PlumBedford.local is the host to restore to
1/7/2014 10:38:07 AM - Info bpbrm(pid=8828) telling media manager to start restore on client
1/7/2014 10:38:08 AM - Info bpbrm(pid=936) PLUMNBU01.PlumBedford.local is the host to restore to
1/7/2014 10:38:08 AM - Info bpbrm(pid=936) start tar32 on client
1/7/2014 10:38:08 AM - Info tar32(pid=10600) Restore started.
1/7/2014 10:38:08 AM - connected
1/7/2014 10:38:08 AM - Error bptm(pid=11008) NBJM returned an extended error status: Requested NDMP machine does not have credentials or is not configured in NetBackup (2108)
1/7/2014 10:38:08 AM - Error ndmpagent(pid=10600) NDMP restore failed from path UNKNOWN
1/7/2014 10:38:08 AM - Info bpbrm(pid=8828) got ERROR 252 from media manager
1/7/2014 10:38:08 AM - Info ndmpagent(pid=10600) done. status: 150: termination requested by administrator
1/7/2014 10:38:08 AM - Info bpbrm(pid=8828) terminating bpbrm child 936 jobid=22048
1/7/2014 10:38:08 AM - requesting resource 000278
1/7/2014 10:38:08 AM - Error nbjm(pid=6016) NBU status: 2108, EMM status: Requested NDMP machine does not have credentials or is not configured in NetBackup
1/7/2014 10:38:08 AM - Error nbjm(pid=6016) NBU status: 2108, EMM status: Requested NDMP machine does not have credentials or is not configured in NetBackup
1/7/2014 10:38:09 AM - restored image plumfas02_1388786329 - (extended error status has been encountered, check logs(252)); restore time 0:00:02
1/7/2014 10:38:09 AM - end Restore; elapsed time: 0:00:36
Restore error(2850)
This seems to occur no matter where we try and restore the data to, even back to the original location. Any advice?
-JD
Solved! Go to Solution.
01-08-2014 12:28 PM
One of our other technicians just performed some maintenance on our robot (removed jammed tape from gripper) and rebooted our robot and the NetBackup server. After this reboot, all of my NDMP restores seem to be working to the NetApp, either to the original location or another location on the same appliance. I'm not sure if the issue was with the robot, the NBU server, or user error (as I was unable to restart my restores until the maintenance finished to reproduce same-location recovery.
My thanks to all of you for all of you help on this case.
-JD
01-07-2014 10:06 AM
is the restore failing with both short or fqdn names?
are u restoring it to same host?
01-07-2014 10:21 AM
I've actually tried multiple combinations. Alias and FQDN. Restoring to the same host, to a separate host, to a separate network share on another device, and to the desktop of the NetBackup server itself. All methods fail, unfortunately.
-JD
01-07-2014 10:40 AM
Have you tried this?
http://www.symantec.com/business/support/index?page=content&id=HOWTO91827&profileURL=https%3A%2F%2Fsymaccount-profile.symantec.com%2FSSO%2Findex.jsp%3FssoID%3D1389119963651oyQfJgH2iBZ0GCigw3193QkXrM0fm4KRK1L19
01-07-2014 10:52 AM
Yes. Unless I ran the command incorrectly. I ran:
nbemmcmd -machinealias -addalias -alias plumfas02 -machinename plumfas02.plumbedford.local
Also, it appears backups of this device have been working smoothly, with no errors reported. It only seems to be the restore of these backups which fail.
-JD
01-07-2014 11:04 AM
Take a look at your Storage Servers in the GUI. Are all your expected media servers displayed for the storage server in question?
01-07-2014 11:40 AM
Are you restoring from the Netapp to the master server ?
I may be wrong, but I think you are only able to restore backup to the NAS. Cross OS restore is in general not supported in Netbackup but it may work in some scenarios (NDMP not one of them).
In general the data format used by NDMP appliances are proprietary. NDMP is a control protocol not data format. You are also not able to restore from one vendor to another e,g. Netapp vs. EMC.
1/7/2014 10:38:07 AM - Info bpbrm(pid=8828) PLUMNBU01.PlumBedford.local is the host to restore to
01-07-2014 12:19 PM
Correct. Have to restore to plumfas02 (or other qualified NDMP host).
01-07-2014 02:20 PM
Yes, we only have one media server and it is visible.
-JD
01-07-2014 02:26 PM
Sorry, that was just the grab from the last attempt. I have tried restoring to the NetApp as well. Let me grab those messages to upload.
-JD
01-08-2014 12:59 AM
We need more info about where backup was done and where you are trying to restore to.
As per Nicolai's post - you can only restore NDMP backup to the same type of filer.
We see name of NAS host: plumfas02.PlumBedford.local
But you are trying to restore to PLUMNBU01.PlumBedford.local.
The restore will not work.
Please ensure that bprd log folder exists on the master server. If not, create folder and restart NBU.
Create bprm and bpbrm log folders on the media server configured as NDMP media server.
After next failed restore attempt, copy these logs to .txt files (e.g. bprd.txt) and upload as File attachments.
Please also take screenshots of restore selection and destination path selection.
01-08-2014 01:42 AM
Besides, if your use case is restoring NDMP data to the NetApp filer volume, then ensure the destination path preservation is correctly use (e.g. presumed your input destination is akin of /vol/volume001/folder01/... ), as of some backup application by default shown level-1 from the backup root directory.
Other backup software/vendor, may allow to restore NDMP data onto a Non-NDMP-filer platform, such as Windows OS directory, provided the OS platform has installed the designated's backup software agent (e.g. "NDMP-restore-enabler").
01-08-2014 05:50 AM
Sorry, the last attempt (the one I have in the main post) was trying to restore to the local machine. I have run multiple attempts against the same NetApp it was backed up from, however those failed as well, both with providing a new path and trying to recover to the same path.
Please ensure that bprd log folder exists on the master server. If not, create folder and restart NBU.
Create bprm and bpbrm log folders on the media server configured as NDMP media server.
I have created the bprd folder to start capturing these logs on our NetBackup server. The only media server we have configured as a media server is the NetBackup server. I have created the requested folders for those logs as well.
After next failed restore attempt, copy these logs to .txt files (e.g. bprd.txt) and upload as File attachments.
Please also take screenshots of restore selection and destination path selection.
Will do. Our robot went down overnight last night, so all backups/restores are currently failing. As soon as this is corrected, I will provide the screenshots and logs for the NDMP -> NDMP restore.
-JD
01-08-2014 05:58 AM
Besides, if your use case is restoring NDMP data to the NetApp filer volume, then ensure the destination path preservation is correctly use (e.g. presumed your input destination is akin of /vol/volume001/folder01/... ), as of some backup application by default shown level-1 from the backup root directory.
Yep. My first series of attempts (which I don't have the logs or messages for unfortunately) were attempts to restore to a new path on the same device and recover to the same path on the same device. Unfortunately, I wasn't aware of the inherint issue with restoring from NDMP to Windows OS, so that was the messaging I grabbed, which wouldn't have worked no matter what.
-JD
01-08-2014 12:28 PM
One of our other technicians just performed some maintenance on our robot (removed jammed tape from gripper) and rebooted our robot and the NetBackup server. After this reboot, all of my NDMP restores seem to be working to the NetApp, either to the original location or another location on the same appliance. I'm not sure if the issue was with the robot, the NBU server, or user error (as I was unable to restart my restores until the maintenance finished to reproduce same-location recovery.
My thanks to all of you for all of you help on this case.
-JD
01-08-2014 12:31 PM
Glad to see it fixed.
And thanks for providing a solution to the issue.
01-08-2014 09:12 PM
Hi JD,
With regards to the rebooting problem went away scenario. My hunch (guessing) about the culprit is the SCSI reservation/release...
http://oreilly.com/catalog/sansnas/chapter/ch04.html
01-09-2014 07:32 PM
Re-posted (edited)
01-10-2014 06:27 AM
Thanks! I'll definitely give it a read.
-JD