Veritas-bu

[Veritas-bu] Migrating master from Windows to Solaris

2003-10-07 11:14:05
Subject: [Veritas-bu] Migrating master from Windows to Solaris
From: fahnoe AT FahnoeTech DOT com (Larry Fahnoe)
Date: Tue, 7 Oct 2003 10:14:05 -0500
So this morning on the new Solaris master I used tpconfig to delete
references to the shared drives, but left the robot definition and
volume database host pointing to the Solaris master.  The Win2K master
is up and running now so I do not want to have conflicts here.  On the
Solaris master I removed all servers but the Solaris master; on the
other servers I removed references to the Solaris master.  With this
done I brought the daemons up on the Solaris master.  It complained
that there were no drives available, but vmd and tldcd came up
allowing me to use vmquery and vmadd to verify the volume database.

vmquery -a shows all volumes
vmadd [...] allows adding media

So, this combined with my earlier moving of the media from standalone
to robotic residence using media manager seems to say that volDB is in
fact okay.  Based upon the errors I showed in my original message,
there is still something wrong as while I can see the media, see the
catalog, and do restores, I cannot expire media or write backups.  I
have turned on volmgr debugging and am trying to make sense of those
logs.  It was these that originally got me thinking that it was volDB
that was corrupt, but maybe it is not.  

David's line of questioning seems to be driving at configuration
errors.  To my mind, the shared storage option is the best candidate
for being in error, but clearly it was working well enough to allow
restores from multiple media servers.

Any way of validating volmgr/database/globDB?

--Larry

On Mon, Oct 06, 2003 at 04:13:44PM -0500, Larry Fahnoe commenced mumbling:
> I have not tried to add media, however I did use the robotic inventory
> to update all the media from standalone to robotic.  The implication
> here is that I can see all the media using media management: all the
> pool, expiration and use data is still available.  This suggests that
> netbackup/db/mediaDB is fine.  Doing things like bpexpdate -d 0 -ev ID
> will cause failures.  Tomorrow I can attempt to add media and report
> back the results.
> 
> I'm wondering if anyone has the record layout for volDB, and if I
> couldn't whip up a little code to do the conversion.  Veritas support
> has so far been silent on my migration questions.
> 
> 
> On Mon, Oct 06, 2003 at 02:09:53PM -0600, David Chapa commenced mumbling:
> > In 4.5 FP3 there is an unsupported utility you can use to validate your
> > configuration, unfortunately that's not going to help you right now.
> > 
> > Have you been able to "add" media to your configuration?
> > 
> > David A. Chapa * Technical Advisor, Technical Marketing * ADIC *
> > 720.249.5836 * david.chapa AT adic DOT com
> > 
> > Pathlight VX - Integrated Disk-to-Tape Backup - http://www.adic.com
> > 
> > 
> > From: Larry Fahnoe [mailto:fahnoe AT FahnoeTech DOT com] 
> > Sent: Monday, October 06, 2003 11:48 AM
> > To: David Chapa
> > Cc: veritas-bu AT mailman.eng.auburn DOT edu
> > Subject: Re: [Veritas-bu] Migrating master from Windows to Solaris
> > 
> > Just to clarify, the Win2K master is a media server and also the
> > volume database host for the SSO environment.  This environment has a
> > single STK L700 owned by the master and accessed by the master/media
> > and media servers.
> > 
> > Again, my sense is that the volmgr/database/volDB file is the one
> > having problems.  I have not found anything, but am wondering if there
> > are any tools to allow the "export" of the VolMgr data to a new host
> > on a different platform, or tools to perform validation and repair
> > once the VolMgr data has been moved.
> > 
> > 
> > On Mon, Oct 06, 2003 at 09:45:02AM -0500, Larry Fahnoe commenced
> > mumbling:
> > > Yes, the W2K box was a master/media.
> > > 
> > > 
> > > On Mon, Oct 06, 2003 at 08:35:21AM -0600, David Chapa commenced
> > mumbling:
> > > > Was the W2K server also a media server, in other words was it
> > > > responsible for "writing" backup jobs to tape?  
> > > > 
> > > > 
> > > > 
> > > > David A. Chapa * Technical Advisor, Technical Marketing * ADIC *
> > > > 720.249.5836 * david.chapa AT adic DOT com
> > > > 
> > > > Pathlight VX - Integrated Disk-to-Tape Backup - http://www.adic.com
> > > > 
> > > > 
> > > > From: Larry Fahnoe [mailto:fahnoe AT fahnoetech DOT com] 
> > > > Sent: Sunday, October 05, 2003 1:49 PM
> > > > To: veritas-bu AT mailman.eng.auburn DOT edu
> > > > Subject: [Veritas-bu] Migrating master from Windows to Solaris
> > > > 
> > > > Greetings,
> > > > 
> > > > I'm in the process of migrating from a Win2K master server running
> > > > 3.4.1 to a freshly installed Solaris 9 3.4 master server.  This is a
> > > > SSO environment with 5 media servers (4 Win2K, 1 Solaris) and an
> > L700
> > > > controlled by the master server.  My ultimate goal is to get the
> > whole
> > > > environment upgraded to 4.5.
> > > > 
> > > > Thus far I have not been successful, though the attached message
> > from
> > > > W. Curtis Preston has provided me with both hope and a helpful
> > road-map
> > > > toward partial success.  I have been able to get the catalog data
> > > > migrated and have been able to query it and do restores using
> > multiple
> > > > media servers.  I have not been able to do backups or otherwise
> > modify
> > > > volumes.  My sense is that the volDB is corrupt as I'm getting the
> > > > following sorts of errors:
> > > > 
> > > >  - bptm Media Manager could not deassign media id 000159, retaining
> > it
> > > > in
> > > >    NetBackup database
> > > > 
> > > >  - bptm Media Manager error 8, invalid media ID
> > > > 
> > > >  - bptm short read occurred reading media database, bytes = 93
> > > > 
> > > >  - bptm Media Manager error 94, volume is not in specified pool
> > > > 
> > > > Here is how I have performed the migration thus far:
> > > > 
> > > > 1) Install Solaris 9, and NetBackup 3.4 with patch NB_34_6.  This
> > > > server's name is Osiris
> > > > 
> > > > 2) Configure Osiris to be a media server in the existing SSO
> > > > environment so that I have access to the drives for bprecover
> > > > 
> > > > 3) Get a database backup from the current server (named stptape1m)
> > and
> > > > stop scheduling
> > > > 
> > > > 4) Move all the media to standalone
> > > > 
> > > > 5) Using bprecover, restore the \Program Files\VERITAS\NetBackup\db
> > to
> > > > /usr/openv/netbackup/db-restore on the Solaris server
> > > > 
> > > > 6) Since the media has been moved to standalone after the database
> > > > backup, copy \Program Files\VERITAS\Volmgr\poolDB ruleDB and volDB
> > to
> > > > /usr/openv/volmgr/database-restore on the Solaris server
> > > > 
> > > > 7) Shut down Win2k master, reconfigure Solaris as master.  The
> > Solaris
> > > > machine name does not change, however it does get the addresses of
> > the
> > > > Win2k server (I'll address the name change using W. Curtis'
> > procedure
> > > > below).
> > > > 
> > > > 8) Fix the record termination in the NetBackup catalog using
> > dos2unix
> > > > 
> > > > 9) Fix the record termination in volmgr/poolDB and volmgr/ruleDB
> > with
> > > > dos2unix.  Leave volDB alone as it does not look like a text file.
> > > > 
> > > > 10) Bring up daemons on the Solaris server
> > > > 
> > > > 11) Recreate volmgr/ltidevs, globDB, and robotic_def
> > > > 
> > > > 12) Move the media from standalone to robotic residence
> > > > 
> > > > 13) Use bpimage to change the master server's name
> > > > 
> > > > 14) Update the media servers and clients with the new master's name
> > > > 
> > > > As there is about 35GB of data in 31K files in the catalog the
> > > > restores and repair of DOS line termination takes a while, but
> > > > otherwise things seem to be quite good.  It is only when I get to
> > the
> > > > point of actually changing volume metadata that I begin to see
> > errors
> > > > like those listed above, so I feel I need to convert the volDB from
> > a
> > > > Win2K form to a Solaris form.  Yes, I know these are documented as
> > > > binary files, but I'd like to get the catalog migrated and not have
> > to
> > > > re-read all my tapes.  Since the migration attempt was not
> > successful,
> > > > I have rolled back to my previous config.
> > > > 
> > > > Any hints or suggestions from the wise ones?  Many thanks!!
> > > > 
> > > > 
> > > > On Mon, Mar 24, 2003 at 10:56:13AM -0800, W. Curtis Preston
> > commenced
> > > > mumbling:
> > > > > There is an unsupported migration procedure available from
> > Veritas.
> > > > > It's REALLY not that hard, and I'm not sure why they make it so
> > hard
> > > > to
> > > > > find.  Steps 1-13 are pretty self-explanatory, and will vary from
> > site
> > > > > to site.  They key is step 14, where you use the bpimage command
> > to
> > > > > modify the name of the master server in all the image files, and
> > step
> > > > 15
> > > > > where you change all the client's master server name.  (Step 15
> > would
> > > > be
> > > > > easier to do if you did it if you used bpgp or bpsetconfig to add
> > the
> > > > > new master as a media server from the old master, then use bpgp or
> > > > > bpsetconfig to make it the master server once it's moved over, but
> > > > this
> > > > > procedure doesn't mention that.)
> > > > > 
> > > > > 1. Backup everything on the OLD master server.
> > > > > 
> > > > > 2. Perform an immediate NetBackup database backup from the
> > NetBackup
> > > > > Administration GUI on the OLD master server.
> > > > > 
> > > > > 3. Use the "Media Management" GUI on the OLD master server to move
> > all
> > > > > the robotic tape volumes to non-robotic. (Highlight one or more
> > > > > mediaIDs, right click, select "move")
> > > > > 
> > > > > 4. On the OLD master, stop the NetBackup daemons
> > > > > (/usr/openv/netbackup/bin/goodies/bp.kill_all) and permanently
> > disable
> > > > > them from automatically starting.  (mv /etc/rc2.d/S77netbackup
> > > > > /etc/rc2.d/s77netbackup; mv /etc/rc0.d/K77netbackup
> > > > > /etc/rc0.d/k77netbackup)  
> > > > > 
> > > > > NOTE: unless otherwise specified, the following steps should all
> > be
> > > > > carried out on the NEW master server.  It is assumed that the
> > > > NetBackup
> > > > > daemons on the OLD master server are now permanently disabled.
> > > > > 
> > > > > 5. Physically remove the robot and drives from the OLD master
> > server
> > > > and
> > > > > install them on the NEW master server.
> > > > > 
> > > > > 6. Perform the configuration steps specific to the platform to
> > ensure
> > > > > that the newly installed robot and drives are known to the
> > operating
> > > > > system after it boots.  In Solaris, for example, this involves
> > booting
> > > > > with the -r option, after physical installation of robots and
> > drives
> > > > on
> > > > > the scsi bus. 
> > > > > 
> > > > > 7. Create the system device files for the drives and the robotic
> > > > > control, as required by the specific platform.  Refer to the Media
> > > > > Manager Device configuration Guide to get specific information on
> > this
> > > > > procedure for each supported platform.
> > > > > 
> > > > > 8. Install NetBackup on the NEW master server along with whatever
> > > > > NetBackup patches are currently installed on the OLD master
> > server.
> > > > > After the installation is complete, stop the NetBackup daemons on
> > the
> > > > > NEW master server.
> > > > > 
> > > > > 9. Copy the following from the OLD master server to the NEW master
> > > > > server:
> > > > > /usr/openv/netbackup/db (directory)
> > > > > /usr/openv/volmgr/database/poolDB
> > > > > /usr/openv/volmgr/database/volDB
> > > > > /usr/openv/volmgr/database/ruleDB
> > > > > 
> > > > > 
> > > > > 10. Start the NetBackup software (e.g. run
> > > > > /usr/openv/netbackup/bin/goodies/S77netbackup).
> > > > > 
> > > > > 11. Modify any defined storage units to refer to the NEW master
> > > > server.
> > > > > 
> > > > > 12. Recreate your robot and tape drives using the Device
> > Management
> > > > GUI.
> > > > > 
> > > > > 13. Use the "robot inventory" option in the Media Management GUI
> > to
> > > > > update the NBU media databases with the proper robotic location of
> > > > your
> > > > > tapes.
> > > > > 
> > > > > 14. Change ownership of all backup images from the old master
> > server
> > > > > name to the new master server name by running the following
> > command:
> > > > > 
> > > > >    /usr/openv/netbackup/bin/admincmd/bpimage -newserver
> > > > > <NEW-master-name>  -oldserver <OLD-master-name>
> > > > > 
> > > > > 15. Modify the bp.conf file on EVERY host in the NetBackup
> > > > configuration
> > > > > to correct any references to the OLD master server.
> > > > > 
> > > > > 15. Run backups and restores to verify success.
> > > > > 
> > > > > _______________________________________________
> > > > > Veritas-bu maillist  -  Veritas-bu AT mailman.eng.auburn DOT edu
> > > > > http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
> > 
> 

-- 
Larry Fahnoe, Fahnoe Technology Consulting, fahnoe AT FahnoeTech DOT com
952/925-0744      Minneapolis, Minnesota       www.FahnoeTech.com