ADSM-L

Re: [ADSM-L] Migration for Windows-based installation

2009-10-12 19:17:34
Subject: Re: [ADSM-L] Migration for Windows-based installation
From: Kurt Buff <kurt.buff AT GMAIL DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Mon, 12 Oct 2009 16:16:20 -0700
I'll have to work through a fair amount to understand what you've
outlined, but it seems doable. I think pruning volhist and devconfig
first might be a good idea, if for no other reason than to cut down on
the confusion.

Thanks for the input. I'll most likely be back for more information.

Kurt

On Mon, Oct 12, 2009 at 14:03, Ochs, Duane <Duane.Ochs AT qg DOT com> wrote:
> For my last migration to new hardware I built a new system and used 
> export/import server to server.
> Worked very well. Doesn’t work if you have only one library though.
>
> However, you are looking for an alternate method.
>
> I'd recommend upgrading to TSM 5.5 first. Especially if you run into problems 
> and have to call IBM for support.
>
>
> This is a really simplified step by step.
> Build your new system:
> Install the same version of TSm that you have on the old system.
> On old server:
> Perform a DB backup to a blank tape. Two for redundancy.
> Backup volhist.
> Backup devconfig
> Take down TSM on your old TSM server
> Document all tape drive/library information and drivers.
>
> Copy db files to the new system, reclog volumes and diskpool volumes.
> If you are really familiar with TSM you can minimize the amount of diskpool 
> volumes to be copied first.
> Copy the contents of your server directory to the new system.
>
> Verify that your copied dsmserv.dsk file reflects the new location of the DB 
> files and log files.
>
> If everything was done correctly and verified properly you should be able to 
> start up your TSM database.
>
> Then you will have to redefine your library and drives.
>
>
> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf 
> Of Kurt Buff
> Sent: Monday, October 12, 2009 3:37 PM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: Migration for Windows-based installation
>
> Disk for the current TSM server is IDE/PATA in a RAID5 array internal
> to the machine - though the OS is on a (eep!) single IDE/PATA drive
> connected to the motherboard.
>
> Kurt
>
> On Mon, Oct 12, 2009 at 13:19, David McClelland <tsm AT networkc.co DOT uk> 
> wrote:
>> Okay, another fun question for you Kurt, investigating some alternative 
>> lines of simply migrating your current TSM server instance to new hardware: 
>> is the disk upon which your current TSM database/recovery log/storage pool 
>> live internal to your old server, or is it instead hosted upon external disk 
>> and thus (potentially) relatively feasible to 'introduce' to your new 
>> hardware?
>>
>> /DMc
>>
>> -----Original Message-----
>> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf 
>> Of Kurt Buff
>> Sent: 12 October 2009 21:09
>> To: ADSM-L AT VM.MARIST DOT EDU
>> Subject: Re: [ADSM-L] Migration for Windows-based installation
>>
>> So, what happens to all the tapes I have offsite at Iron Mountain, and
>> the archives I have stored in my basement vault, etc.
>>
>> I'll be perusing the archives as you suggest, but this isn't exactly
>> crystalline to me just yet.
>>
>> A complicating factor that I hadn't realized until I did a bit of
>> digging just now is that the current database holds references to a
>> *really* old set of 8mm (AIT2) tapes from a Spectralogic Treefrog that
>> we migrated from some years ago.
>>
>> Would the procedure you're suggesting clean that up?
>>
>> Kurt
>>
>> On Mon, Oct 12, 2009 at 12:10, Kelly Lipp <lipp AT storserver DOT com> wrote:
>>> Start from scratch.  Install TSM at the level you would like, move and 
>>> configure the library. Point the clients at the new server and go.  That 
>>> first backup will necessarily be a full.  Will take longer than usual, but 
>>> easy.
>>>
>>> This method allows you go "clean up" your database.
>>>
>>> Keep the old server around until the data expires.
>>>
>>> Clearly, there are more details, especially since you are going to re-use 
>>> the library on the new STORServer (oops, I mean TSM Server).  The overall 
>>> concept is sound. For sites of your size I like this method as it is simple 
>>> and gets me a brand new, pristine database.  This will become important 
>>> next year when you migrate to TSM 6.2.  Besides, a clean start is always a 
>>> good thing.
>>>
>>> This topic has been covered earlier and in much more detail.  You might 
>>> peruse the archives to see what you can find.  My name will show up along 
>>> with others like Wanda who have been through this many times.
>>>
>>> Thanks,
>>>
>>> Kelly Lipp
>>> Chief Technical Officer
>>> www.storserver.com
>>> 719-266-8777 x7105
>>> STORServer solves your data backup challenges.
>>> Once and for all.
>>>
>>>
>>> -----Original Message-----
>>> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On 
>>> Behalf Of Kurt Buff
>>> Sent: Monday, October 12, 2009 1:02 PM
>>> To: ADSM-L AT VM.MARIST DOT EDU
>>> Subject: Re: [ADSM-L] Migration for Windows-based installation
>>>
>>> I'd prefer to be able to migrate server data as much as possible,
>>> including the diskpool, but if it it would be an incredibly difficult
>>> maneuver (or take inordinate amounts of time, say on the order of more
>>> than a 4-day weekend) and/or the downside of losing the diskpool is
>>> relatively minor, I could potentially live without it.
>>>
>>> I would also contemplate keeping the current TSM server version on the
>>> new machine and upgrading immediately after implementation if that
>>> would be of benefit.
>>>
>>> We back up fewer than 10 servers, but one is our Exchange 2003 server
>>> at roughly 200gb and is a full backup every night, and the other is
>>> our file server at over 2tb, though on a nightly  basis it normally
>>> does around 25-50gb.
>>>
>>> Does that answer your question?
>>>
>>> Kurt
>>>
>>> On Mon, Oct 12, 2009 at 11:18, David McClelland <tsm AT networkc.co DOT uk> 
>>> wrote:
>>>> Are you looking purely at a lift and shift hardware change here, or at a 
>>>> clean installation of TSM Server (at 5.5.3 for example) and migrating 
>>>> clients into the new instance?
>>>>
>>>> Cheers,
>>>>
>>>> /David Mc
>>>> London, UK
>>>>
>>>> -----Original Message-----
>>>> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On 
>>>> Behalf Of Kurt Buff
>>>> Sent: 12 October 2009 18:54
>>>> To: ADSM-L AT VM.MARIST DOT EDU
>>>> Subject: [ADSM-L] Migration for Windows-based installation
>>>>
>>>> All,
>>>>
>>>> We have a TSM server that's running out of steam, and nearing the end
>>>> of its expected reliable life. We have Version 5, Release 3, Level 4.6
>>>> installed, with various levels of clients installed on our servers.
>>>> The server has 1gb RAM, roughly 2tb of disk storage, but it's old/slow
>>>> PATA, and the OS is Win2k Pro. Definitely not ideal.
>>>>
>>>> The tape robot is a Spectralogic T50, with two LTO3 drives and 25
>>>> slots, out of which we expect to get much more life.
>>>>
>>>> We expect to replace the server with a new Dell server with 3tb of
>>>> SATA disk, 3gb RAM, Win2k3 (32bit), and use the current tape robot.
>>>>
>>>> I'd like to get to the newest in the 5.x series on the new server,
>>>> since the talk on this list about moving to 6.x indicates to me that
>>>> we'd be better off staying at 5.x for now.
>>>>
>>>> I've been casting about, and can't seem to find documentation on how
>>>> to migrate the setup to the new machine.
>>>>
>>>> Does anyone have a pointer to good documentation on doing this?
>>>>
>>>> Frankly, we've been given a quote by a VAR, and though the number of
>>>> hours they are quoting seem reasonable, the price they're asking to
>>>> work with us on this is beyond our budget.
>>>>
>>>> Thanks
>>>>
>>>> Kurt
>>>>
>>>> No virus found in this incoming message.
>>>> Checked by AVG - www.avg.com
>>>> Version: 8.5.421 / Virus Database: 270.14.3/2415 - Release Date: 10/12/09 
>>>> 04:01:00
>>>>
>>>
>>
>> No virus found in this incoming message.
>> Checked by AVG - www.avg.com
>> Version: 8.5.421 / Virus Database: 270.14.3/2415 - Release Date: 10/12/09 
>> 04:01:00
>>
>