Having just done an upgrade of a 120 GB TSM 5.5 server to 6.2, IBM's
time estimates were surprisingly accurate. The process was long and
labor intensive, but in the end it worked. You can see my notes in the
archives of this list from the end of December.
We're even considering altering our strategy for our oldest 5.5 server
with its bloated 300 GB database and 1000 clients. Plan A was to put up
the new V6 server alongside it and do exports and new backups, like
you're planning. That process is underway, but it may take a whole year,
and I want to junk the old hardware before then. Plan B is to get the
database of the 5.5 server down from 300 GB to about 150 GB by exporting
or doing new backups of the easy, large clients, and then do an upgrade
for the rest using the new system/media method to another instance on
the new hardware. The largest savings in my Plan B would be in not
having to change anything on most of those 1000 clients, which sit on
the desktops of professors, researchers, and deans, some of whose
offices I'd probably have to visit in person. That terrible prospect of
spending weeks walking around campus switching client nodes one at a
time, makes the long and somewhat excruciating TSM upgrade process look
like a walk in the park. Instead I will just have to change one DNS
definition after the upgrade is done.
In summary, do the upgrade. I think it will be easier for you.
Roger Deschner University of Illinois at Chicago rogerd AT uic DOT edu
======I have not lost my mind -- it is backed up on tape somewhere.=====
On Wed, 27 Mar 2013, Alex Paschal wrote:
>Hi, Jerome. I've found IBM's quote of 5GB/hr is pretty accurate across
>a variety of hardware architectures, OSs, and disk arrays. Figure your
>200GB database would take 40-ish hours to upgrade, possibly less if you
>feel a reorg would shrink your database significantly. That means you'd
>probably miss two nights' backups, IF you left the old system down.
>Here are some thoughts.
>
>Migration takes a lot of work and time. If you can possibly swing the
>40-hour upgrade, I highly recommend it. To help convince management,
>figure the time you'd spend migrating and how much that would cost in
>consultant time, vs 2-3 days of consultant time for just the upgrade.
>Try to convince them your time isn't free and should be factored in
>because, while you're migrating, there's other stuff you aren't doing.
>
>If you use the New System/Media method, which is my personal preference,
>you can even bring your 5.5 server back up after the extract is
>complete, which means you can take backups and be able to do restores
>for those two days. This will not be possible if you use the Network
>method. This covers the "what if someone needs a restore during those
>two days" and the "that leaves us unprotected for two days" complaints.
>You would want to make sure your reusedelay is set correctly, though,
>and don't bother with reclamation. You would have to manually track
>volumes that are sent offsite during those two days, but maybe you could
>just skip the offsite process those two days.
>
>If you can convince management to abandon that two days' worth of
>backups to the old 5.5 server, e.g. shut down the 5.5 server, switch
>production to the 6.x server, resume incrementals with a 2-day gap, this
>is just as good because you don't have to do any migration. Again, save
>time, effort, and years of premature aging. Try using business phrases
>like: "migration cost not commensurate with the benefits", "migration
>increases risk", "lost opportunity cost of the migration time", and any
>other BS-Bingo terms you can repurpose for the fight against evil.
>
>If you can't convince management to abandon that two days' worth of
>backups, see if you can convince them there's only a few nodes that you
>can't abandon. If you can limit it to just a few nodes, you could do an
>"export node filedata=all fromdate= fromtime= todate= totime=" to skim
>only the data from the time of the extract and import it into the new
>server. That will drastically reduce the amount of data you have to
>migrate. If you took those backups to new media, like a new library
>partition or something, or a bunch of spare disk (if there is such a
>thing), you could do it server-to-server. If not, simply export to
>tape, shut down the 5.5 server, and import those tapes into the new server.
>
>If all of the above falls through, only then consider the migration.
><shudder> But since you have only 60 servers, it might be worth
>considering doing the export node fromdate/fromtime for all 60, rather
>than migrating all that historical data. One other thing - since you're
>getting a new system, extract the DB, then test the upgrade a few times
>before doing it for real.
>
>Good luck, and may your management be amenable.
>
>Oh, and for all you other TSM consultants out there (and my sales guys),
>I apologize; I know those migration engagements are mighty lucrative. :-)
>
>Alex
>
>
>On 3/27/2013 12:26 PM, Swartz, Jerome wrote:
>> Thanks Erwann,
>>
>> Currently just over 200GB. I know it's big and was planning doing a reorg
>> but the new DB2 will take care of that.
>>
>> -----Original Message-----
>> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf
>> Of Erwann Simon
>> Sent: 27 March 2013 09:20 PM
>> To: ADSM-L AT VM.MARIST DOT EDU
>> Subject: Re: [ADSM-L] TSM 6.3.3
>>
>> Hi Jerome,
>>
>> What is the current size of the TSM database ? If it's moderate, it's far
>> simpler and faster to do an upgrade following one of the methods presented
>> in the upgrade guide.
>> I'll really advise you to do this.
>>
>> Regards,
>> Erwann
>>
>>
>> "Swartz, Jerome" <Jerome.Swartz AT COMPUTACENTER DOT COM> a écrit :
>>
>>> Hi fello TSM'ers,
>>>
>>> I need the advice of my fellow Backup admins :)
>>>
>>> With TSM 5.5 nearing EOL support and my customer going the Exchange
>>> 2010 the hand has finally been forced to go with TSM 6.x
>>>
>>> My current setup;
>>> Server: w2k3
>>> TSM version 5.5.6 - I have about 60 servers being backed all windows
>>> based. Quite a bit of historical data going back 7 years for my yearly
>>> backups.
>>>
>>> I would like to know how best to approach this upgrade?
>>>
>>>
>>> 1. What I am thinking is to build a new 2008 R2 server.
>>>
>>> 2. Do a fresh 6.3.3 TSM install
>>>
>>> 3. Export the dev/config files
>>>
>>> 4. Export the nodes
>>>
>>> The above might be incorrect as I am still exploring options.
>>>
>>> Or should I be looking at Migrating TSM 5.5 onto a new 2008 R2 server
>>> and then upgrading from there. I am looking at the shortest possible
>>> way of achieving this.
>>>
>>> Regards,
>>>
>>> Jerome Swartz
>>>
>>>
>>>
>>>
>>>
>>>
>>> **********************************************************************
>>> COMPUTACENTER PLC is registered in England and Wales with the
>>> registered number 03110569. Its registered office is at Hatfield
>>> Business Park, Hatfield Avenue, Hatfield, Hertfordshire AL10 9TW
>>> COMPUTACENTER (UK) Limited is registered in England and Wales with the
>>> registered number 01584718. Its registered office is at Hatfield
>>> Business Park, Hatfield Avenue, Hatfield, Hertfordshire AL10 9TW
>>> COMPUTACENTER (Mid-Market) Limited is registered in England and Wales
>>> with the registered number 3434654. Its registered office is at
>>> Hatfield Business Park, Hatfield Avenue, Hatfield, Hertfordshire AL10
>>> 9TW COMPUTACENTER (FMS) Limited is registered in England and Wales with
>>> the registered number 3798091. Its registered office is at Hatfield
>>> Business Park, Hatfield Avenue, Hatfield, Hertfordshire AL10 9TW
>>>
>>> The contents of this email are intended for the named addressee only.
>>> It contains information which may be confidential and which may also be
>>> privileged.
>>> Unless you are the named addressee (or authorised to receive mail for
>>> the addressee) you may not copy or use it, or disclose it to anyone
>>> else.
>>> If you receive it in error please notify us immediately and then
>>> destroy it.
>>> Computacenter information is available from:
>>> http://www.computacenter.com
>>> **********************************************************************
>> --
>> Envoyé de mon téléphone Android avec K-9 Mail. Excusez la brièveté.
>
|
