The bootstrap:

When dsmserv starts, it looks in dsmserv.opt.

Dsmserv.opt has the location of the devconfig and volhist.
If the location isn't correct, you'll need to fix it before you run the
DSMSERV RESTORE DB.

dsmserv looks in the volhist for the name and devclass of the DB backup
tape(s). (The volhist isn't required, you can specify the volser and
devclass on the DSMSERV RESTORE DB command).

Then dsmserv reads the devconfig for the definitions for your tape library,
drives & paths (if applicable), devclass, slot number where the tape is
located (if applicable), etc.  (The devconfig from your old server isn't
required either, if you want to configure everything manually on your new
server, which will create a new devconfig that is correct.)













On 2/15/08, Zoltan Forray/AC/VCU <zforray AT vcu DOT edu> wrote:
>
> Thanks for all the suggestions/ideas.  However, I seem to be missing
> something (e.g. the "lightbulb" hasn't come on yet.
>
> I am ready to actually try this, expecially since the old server is
> starting to experience hardware problems and really, really needs to be
> put out of it's misery.
>
> I was checking the book for various examples of the DSMSERV RESTORE DB
> command.  But no matter what example I found, I seem to be missing how the
> restore process finds the shared tape library (the old and new servers are
> library clients).  Given that I have both a copy of the devconfig and
> volhist, how does this new, virgin TSM server know where to get the tape
> with the DBBackup on it, from?
>
> Do I need to fully configure the new server with cross communications with
> the library manager server ?
>
>
>
>
> Wanda Prather <wprather AT JASI DOT COM>
> Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
> 02/06/2008 02:03 PM
> Please respond to
> "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
>
>
> To
> ADSM-L AT VM.MARIST DOT EDU
> cc
>
> Subject
> Re: [ADSM-L] Recommendations/suggestions for moving a TSM server
>
>
>
>
>
>
> Thanks for the tips. I wasn't sure about the mis-matched release, but
> suspected as much.
>
> Unfortunately, we can't upgrade the existing server to anything higher due
> to OS requirements, which is the main reason we want to move it (besides
> being underpowered), so we will have to downgrade the replacement server.
>
> The tape drives are already connected via SAN.
>
> Can I assume the disk LZ needs to be completely empty since the target
> system would have a completely empty storagepool
>
> ==> Good catch! I left that out my original post.  UNLIKE a true DR, you
> want to empty your disk pools out to tape before doing your DB backup, so
> nothing is orphaned on the disk of the old server.  After you do your
> DSMSERV RESTOREDB, and your server comes up, it will complain that it
> can't
> find any disk volumes.  Since they will be empty, you just delete them and
> define new ones.
>
> I assume you mean a standalone DSMSERV RESTOREDB for which I need the
> volhistory/devconfig file from the existing server (so I need to do a
> "backup volhist" and "backup devconfig" first).
>
> ==> Yes, a RESTOREDB.  Whether you use the deconfig & volhist is up to
> you;
> I don't, I just configure the devices myself and run the RESTORE DB
> specifying what volume to use.  (You'll find in the ADMIN REF at the back
> under SERVER UTILITIES different versions of RESTORE DB, and how to do
> them
> with and without the devconfig and volhist.)
>
> If you use the devconfig, remember to check it to make sure your new
> devices
> are the same dev special names as the old ones, or modify the devconfig
> accordingly (usually more of an issue on Windows than *IX).
>
> Many ways work; Do it whichever way you plan to do it at DR..
>
> Just let me know if you have more questions.  The nice thing here, you can
> do it many times, many ways as long as you have a "new" clean server,
> without breaking your old one.  Great opportunity to test!
>
> Wanda
>
>
>
>
>
>
> Wanda Prather <wprather AT JASI DOT COM>
> Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
> 02/06/2008 12:22 PM
> Please respond to
> "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
>
>
> To
> ADSM-L AT VM.MARIST DOT EDU
> cc
>
> Subject
> Re: [ADSM-L] Recommendations/suggestions for moving a TSM server
>
>
>
>
>
>
> Just think of it as an opportunity for a DR test.
>
> First, TSM does not SUPPORT restoring a TSM DB from a lower level TSM to a
> higher level server.  ("does not support" means they don't test it.  I'm
> sure some people have gotten it to work, but the recommended way is quick
> anyway.)
>
> But the recommended procedure is to
>
> 1) upgrade your old TSM in place from 5.3 to 5.5.   I haven't done it on
> Linux, but on Windows and AIX the 5.3 to 5.5 upgrade is very quick and
> straightforward.
>
> 2) run a DB backup  (not unload)
>
> 3) move your tape drive connections to your new TSM box & configure
>
> 4) RESTORE the TSM db to your new box.
>
> 5) Switch your IP addresses/DNS alias or whatever so your clients point to
> the new box.
>
> Your DR recovery is complete!
>
> There are other things you can do, like running the backup to disk instead
> of tape if you have SAN connections to the disk, or import the disk with
> the
> DB to the new system, depending on your hardware config.
>
> But I prefer to do it as a DR drill, if only to give the instructions a
> workout.  Especially good exercise if you have junior admins that have
> never
> done it...
>
>
>
> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf 
> Of
> Zoltan Forray/AC/VCU
> Sent: Wednesday, February 06, 2008 10:58 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: [ADSM-L] Recommendations/suggestions for moving a TSM server
>
> I need to completely replace my old RH3 Linux TSM server (5.3) by moving
> the contents to a newer, beefier, RHEL4 box. I also want to upgrade the
> server to 5.5.
>
> Of course, the replacement process needs to be completely transparent.
> Basically a push-pull.
>
> Can someone point me to docs/references/cookbooks to perform such a task?
>
> Is a DSMSERV UNLOADDB/LOADFORMAT/RESTOREDB the way to do this?
>
> Currently, the replacement machine is up and fully running with V5.5
> server running.
>