We did an upgrade of 5.5 to 6.2 in 2010 with a database in excess of 200 GB and the conversion process was well under 48 hours. Overall the upgrade process was painless and problem-free, so I'll add my voice to the chorus and say that if you can swing the outage, it's very worthwhile to go down the upgrade path.
Matthew McGeary Technical Specialist PotashCorp - Saskatoon 306.933.8921 From: Roger Deschner <rog...@uic.edu> To: ADSM-L@VM.MARIST.EDU Date: 03/27/2013 11:43 PM Subject: Re: [ADSM-L] TSM 6.3.3 Sent by: "ADSM: Dist Stor Manager" <ADSM-L@VM.MARIST.EDU> 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 rog...@uic.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@VM.MARIST.EDU] On Behalf Of Erwann Simon >> Sent: 27 March 2013 09:20 PM >> To: ADSM-L@VM.MARIST.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.swa...@computacenter.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é. >
