ADSM-L

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

2009-10-12 19:13:43
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:12:27 -0700
Yeah, as I dig into this it becomes more complicated.

We have a number of pools:
     Disk Pools:
          diskpool
     Sequential Access Storage Pools:
          ltopool
          8mmpool1 (which needs to die)
          archivepool
          ltoarchive
          reclaimpool
     Copy Storage pools:
          copypool
          ltocopy

We have several devclasses, too:
     Disk Device Class
          Disk
     File Device Class
          ReclaimClass
     8MM Device Clases
          8mmclass1
     LTO Device Class
          LTO

The 8mm stuff really needs to go away, I think, especially since
Treefrog we had was traded in to get the T50.

We also have data that is archived on the LTO tapes, and that we'll
need for at least 4 more years - financial stuff, doncha know.

Kurt


On Mon, Oct 12, 2009 at 13:24, Bob Levad <blevad AT winnebagoind DOT com> wrote:
> When we migrated to a new server and LTO4 from LTO1, we installed all of the
> new stuff and tested the hardware with the TSM version we were running.
> When that was working well, we drained all of the disk pools, backed up the
> database from the existing server, shut it down, attached the old tape
> drives to the new server, restored the database, brought it up, deleted all
> of the old disk pools, defined new disk pools for the new hardware, defined
> the new tape drives, set up new devclasses and storage pools, changed the
> domains to point to the new devices and migration hierarchy, tested backups
> and restores, and set up move data jobs to move data from the LTO1's back to
> disk pools where it would then migrate to the new LTO4s.  Once the LTO1's
> were empty, we detached the library and recycled the old tapes.  The upgrade
> to a newer TSM could occur on the old server or the new, but best probably
> not at the same time as the hardware cutover.
>
> Starting from scratch was not an option for us as we have files with
> multi-year retentions.
>
> Bob.
>
> PS - If you have references to tapes that no longer exist, there are methods
> (google is your friend) to delete references to them.  The method of
> deletion may depend on how the data was stored
> (primary/copypool/backupset/db backup/other).  Once the references are gone,
> you should delete the storage pools and device classes that are obsolete.
>
> -----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:09 PM
> 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
>>>
>>
>
> This electronic transmission and any documents accompanying this electronic 
> transmission contain confidential information belonging to the sender.  This 
> information may be legally privileged.  The information is intended only for 
> the use of the individual or entity named above.  If you are not the intended 
> recipient, you are hereby notified that any disclosure, copying, 
> distribution, or the taking of any action in reliance on or regarding the 
> contents of this electronically transmitted information is strictly 
> prohibited.
>