ADSM-L

Re: Migrating TSM (5.3.2.0) to new Windows box

2006-06-01 11:01:03
Subject: Re: Migrating TSM (5.3.2.0) to new Windows box
From: Ben Bullock <bbullock AT MICRON DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Thu, 1 Jun 2006 09:00:38 -0600
Sorry, I should have been more specific. I am moving from old AIX
systems to a new AIX systems. In the past we have done just as you
suggest, we attached the drives to the new system, mirrored the db and
removed the old storage.

 The old disks are SSA and the new disks are on a SAN and I am unable to
attach the SSA drives to the new system (no compatible adapter), and I
am unable to attach the SAN to the old hardware (no available PCI
slots).

Ben 

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Paul Zarnowski
Sent: Thursday, June 01, 2006 8:43 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Migrating TSM (5.3.2.0) to new Windows box

Ben,

You don't say, but are you moving to a newer AIX system, or a different
OS?  If you are staying with AIX, do you have the option of connecting
the new disks to the older system?  If so, you could mirror the old DB
onto the new disks, remove the old mirrors, then export/importvg the
disks to the new server.  I've migrated from older AIX servers to newer
ones several times and have never resorted to a DB BACKUP/RESTORE.  I've
always just unplugged the disks from the older server and plugged them
into the newer one.  Of course, I always do a DB BACKUP just in case.

AFAIK, it's not possible to backup/restore a db from one OS to another.
Someone correct me if the think this is incorrect.

..Paul

At 10:23 AM 6/1/2006, you wrote:
>         This methodology has me really interested.
>
>I am about to try to move a 100GB AIX TSM database to another host. The

>disks are totally incompatible, so my option is a db backup and
restore.
>I assumed I was going to have to disable all sessions, drain all the 
>disk pools to the tapes, run a db backup, restore the db to the new 
>host, recreate the diskpools and then let the customers in.
>
>         On a 100 GB db on slow disks, I was thinking 6 hours or so of 
>no customer access.
>
>         Your suggestion of doing a db restore and then an incremental 
>has me thinking.
>
>         when you do the restore of the full DB backup to the new TSM 
>server, do you just leave off the "commit=yes" option?
>
>         Then, once I have all the disk pools drained, I could do an 
>incremental backup, run a DB restore of the incremental DBbackup on the

>new host with the "commit=yes" option and then I could bring up the new

>server?
>
>         It should know that all the client data that is on the tapes, 
>and know that the disk pools are empty when it comes up, right? So I 
>should not need to audit any volumes.
>
>Thanks,
>Ben
>
>
>-----Original Message-----
>From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf 
>Of Remco Post
>Sent: Wednesday, May 31, 2006 2:24 PM
>To: ADSM-L AT VM.MARIST DOT EDU
>Subject: Re: Migrating TSM (5.3.2.0) to new Windows box
>
>Dennis, Melburn W IT743 wrote:
> > Our old TSM server is EOL and we are replacing it with a new one.
> > They are both W2K3.  What is the safest/best way to migrate?  I was 
> > planning on installing TSM on the new box and then using a recent 
> > database copy on tape to restore the db on the new box using a point

> > in time restore (since the log volumes will not be on the new box).
> > Is this a valid way to do this?  Am I missing something?
> >
>
>what I've done just yesterday is:
>
>on the new box:
>format log and db volumes
>restore most recent full dbbackup
>copy over start/stop scripts and dsmserv.opt
>
>old server:
>stop and start with 'DISABLESCHEDS YES' and 'NOMIGRRECL' in dsmserv.opt

>disable sessions empty out all disk and file volumes delete them all 
>make incremental dbbackup halt old server
>
>new server:
>retore incermental on new box (commit=yes) start tsm on the new box 
>recreate disk and file volumes
>
>We usually only do full dbbackups, so I had no intermediate 
>incrementals...
>
>If you empty out all you disk/file volumes before you restart your 
>server, your downtime might be as short as one incremental backup and 
>one incremental resore, minutes....
>
>
> >
> > Mel Dennis
> > Systems Engineer - IT743
> > Siemens Power Generation
> > 4400 Alafaya Trail
> > Orlando, FL 32826
> > MC Q1-108
> > Tel:  (407) 736-2360
> > Win:  439-2360
> > Fax: (407) 243-0260
> > Email:  melburn.dennis AT siemens DOT com
>
>
>--
>Met vriendelijke groeten,
>
>Remco Post
>
>SARA - Reken- en Netwerkdiensten
http://www.sara.nl
>High Performance Computing  Tel. +31 20 592 3000    Fax. +31 20 668
3167
>PGP Key fingerprint = 6367 DFE9 5CBC 0737 7D16  B3F6 048A 02BF DC93 
>94EC
>
>"I really didn't foresee the Internet. But then, neither did the 
>computer industry. Not that that tells us very much of course - the 
>computer industry didn't even foresee that the century was going to 
>end." -- Douglas Adams


--
Paul Zarnowski                            Ph: 607-255-4757
Manager, Storage Systems                  Fx: 607-255-8521
719 Rhodes Hall, Ithaca, NY 14853-3801    Em: psz1 AT cornell DOT edu

<Prev in Thread] Current Thread [Next in Thread>