Restoring NBU 6.0 MP6 Catalog

[AQasir]

I am running NBU 6.0 MP6 on my Master and media servers with all servers running Windows 2003 EE R2.

My NBU Master server does not have a directly attached tape drive so I have one of the media servers backup the catalog (while the NBU database is up [I think this is called a HOT backup]).

I recently built a Virtual Machine in VMWare for quality assurance testing purposes and presented it two stand alone tape drives. The Virtual Machine is also running Windows 2003 EE R2 and has NBU 6.0 MP6 installed acting as a Master Server.

When I try to restore the production catalog (by right clicking on the Catalog icon in the left pane of the GUI and choosing "Restore Netbackup Catalog") into the QA Virtual Machine I have two issues.

1. Since in production I backup the catalog using a media server instead of the master server...I am told during the restore that the client cant be found. I have entered restore failover information into the master server properties so I dont understand why this is still giving me a problem. I can over come this obsticle in one of two ways. I can either add an entry to the systems local host file so that the media server is pointing to the master server ip address or I can go into the DRFile and change the media server name to the master server name.

2. Once issue # 2 is overcome I attempt the catalog recovery and this time the job errors out. Here is what the error shows :

9/24/2008 2:31:44 PM - mounting VMB844
9/24/2008 2:31:42 PM - requesting resource VMB844
9/24/2008 2:31:42 PM - granted resource VMB844
9/24/2008 2:31:42 PM - granted resource HP.ULTRIUM2-SCSI.001
9/24/2008 2:31:49 PM - mounted; mount time: 00:00:05
9/24/2008 2:31:49 PM - positioning VMB844 to file 7
9/24/2008 2:33:24 PM - positioned VMB844; position time: 00:01:35
9/24/2008 2:33:24 PM - Error bptm(pid=5908) ERR - Error occurred reading TIR information, More data is available. .media read error(85)

Below is the DR File information :

PROTOCOL_VERSION 2
START_TIME 0
END_TIME 0
SNAP_TIME 0
KBYTES 46702190
NUM_FRAGMENTS 2
COPIES 1
VERSION 7
CLIENT_TYPE 35
RETENTION_LEVEL 4
SCHEDULE_TYPE 0
COMPRESSION 0
ENCRYPTION 0
FILES_FILE_COMPRESSED 0
MPX 0
TIR_INFO 2
TIR_EXPIRATION 1220968980
PRIMARY_COPY 1
IMAGE_TYPE 0
ELAPSED 5379
EXPIRATION 2147483647
NUM_FILES 187942
EXTENDED_SECURITY_INFO 0
REQUEST_PID 0
IND_FILE_RESTORE_FROM_RAW 0
IMAGE_DUMP_LEVEL 858994739
FILE_SYSTEM_ONLY 0
PREV_BLOCK_INCR_TIME 0
BLOCK_INCR_FULL_TIME 0
STREAM_NUMBER 0
CATARC 0
BACKUP_COPY 0
BACKUP_STATUS 0
JOB_ID 96874
NUM_RESUMES 0
RESUME_EXPIRATION 0
PFI_TYPE 0
IMAGE_ATTRIBUTE 0
PARENT_IMAGE_ID Catalog_Backup_1220709601_FULL
NUM_DR_MEDIAS 1
# FRAG: c# f# K rem mt den fn id/path host bs off md dwo f_flags f_unused1 exp mpx rl chkpt rsm_nbr seq_no media_subtype i_unused3 i_unused2 i_unused1
FRAGMENT 1 -1 25857 0 2 14 7 VMB844 csfsuslic-001 131072 660657 1212847236 2 0 *NULL* 0 0 0 0 0 0 1 0 0 0
FRAGMENT 1 1 46676333 0 2 14 6 VMB844 csfsuslic-001 131072 295996 1212847236 2 0 *NULL* 2147483647 0 65540 0 0 0 1 0 0 0
#DR_MEDIA_REC: ver rtype mtype/den host c# p# classes# classes kbytes nimg vimg hsize off unused4 unused3 unused2 unused1 id/path id_ext
DR_MEDIA_REC 0 0 14 csfsuslic-001 1 1 0 37885562 5 5 1024 295996 0 0 0 0 VMB844 VMB844L2
BACKUP_ID csapuslic-003_1220709780
CREATOR NetBackup
SCHED_LABEL WEEKLY_FULL
FILES_FILE Catalog_Backup_1220709780_FULL.f
FILES_FILE_SIZE 26475172
HISTO_INFO -1 -1 -1 -1 -1 -1 -1 -1 -1 -1

[Omar_Villa]

that error 85 doesnt look good, can be a bad tape or a least a dirty drive, check this first and ensure your media is healthy.

[AQasir]

I have checked the tape and the tape drive - both are healthy.

In researching this on my own I found a few articles that talk about block size differences and Scatter/Gather list settings when a tape has been written over a HBA that has a large block size and then attempting to read the tape over a SCSI device.

In production I have servers attached to tape drives on a SAN via QLogic HBAs but in my QA environment I have a windows virtual machine on a VMWare box directly attached to a SCSI tape drive. The VMware presents a vmscsi driver to the windows virtual machine and I dont this this supports scatter/gather settings. Not all physical SCSI cards support this setting also so I will try to come up with a better QA environment to test some of my things.

[Michael_Blizzar]

When trying to restore the catalog,  make sure there are no overides set in the master servers proerties.

[Flappyhead]

Hello there

We are having pretty much the exact same problem here.

I am trying to restore the catalog from our prod environment to a newly built NetBackup server in our R&D environment. We are running NetBackup 6.0 MP4 on Windows 2003 SP1. The catalog was backed up over fibre, and I'm trying to restore from the tape from a drive that is connected via SCSI.

In our R&D environemnt, I have the exact same server name and IP address for our master server, so I didn't have to place any overides in place, so my problem is the same as your recovery problem. Same log as you. Same error.

I have tried changed touch files etc in \NetBackup\db\config\ but none of this worked. Unless I have missed something...

Can someone out there please give me the magic answer to my woes? I will buy you a beer ;)

*sigh*

[Andrew_Ribeiro]

Did you ever find a solution to this problem?

I am having almost an identical problem except in our production environment and our R&D environment we are usuing 6.5.4. Production is using FC and R&D is using SCSI.

Thank you in advance for any advice you may have.

[Andy_Welburn]

As this discussion was started (& last commented on) over a year ago, it is quite likely that you may not get any response from the original participants (they may no longer utilise NetBackup or even have had the good sense to leave IT as a whole!).

I would suggest you start a new post & include all the relevant info of your environment, the errors you are encountering & any other pertinent information from any logs etc. This will also enable you to mark any post as the solution should that be appropriate.