I am in the process of testing a Netbackup Master server DB migration
from Solaris to Red Hat Linux (64bit). The servers are running Netbackup
5.1 MP5 (NDMP MP5). The Linux Master server is keeping the same host
name as the Solaris Master server. Below are migration steps I
performed:

 

1)       Back up the catalog on the Solaris Master server to an NFS
mount point.

2)       Shut down Solaris Master.

3)       Connect tape drives and robot attached to the Solaris Master to
the Linux Master

4)       Power on Linux Master (note: it is already loaded with NBU 5.1
MP5)

5)       Shutdown Netbackup on the Linux server

6)       Mount the NFS mount point containing the catalog backups on the
Linux server.

7)       Restore the DB with the "bprecover -dpath" command"

8)       Remove the following files on the Linux server:

a.       rm /usr/openv/volmgr/database/globDB

b.       rm /usr/openv/volmgr/database/ltidevs

c.       rm /usr/openv/volmgr/database/robotic_def

9)   "./vmglob -set_gdbhost hostname"

10)   Restart Netbackup on Linux server

11)    "./set_ndmp_attr -auth netapps" to reconfigure NDMP authorization

12)   Configure Robot and tape drives

 

The above steps worked fine. The environment looked identical to the
Solaris Master server. I could see all the media, volume pools, clients,
policies, drives and the robot. I was able to restore several files to
different Windows and Unix clients in the backup environment. I was also
able to restore files from the NDMP backups which were in Unix based
Netapp volumes. 

The only problem I am running into is with NDMP restores of files from
Windows (NTFS) based Netapp volumes. When I perform a restore, the
restore job states the files were restored successfully and returns a
status 0; however, the files restore with 0 bytes and a date of December
31st, 1969. I also noticed there is a red circle with a line through it
on the NDMP Netapp windows files when I am browsing through the
Netbackup restore menu. Has anyone come across a similar issue? I am
stumped.

                        Thanks,

                                    Mike

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
http://mailman.eng.auburn.edu/pipermail/veritas-bu/attachments/20061206/34a4deea/attachment-0001.html