Showing posts with label Upgrade. Show all posts
Showing posts with label Upgrade. Show all posts

Thursday, January 24, 2013

Upgrading A TSM 5.5 Library Manager to 6.x

I just helped (sort of) perform an upgrade of two TSM library managers from TSM 5.5 to TSM 6.2. First off I'd like to say that the process involved was really not worth the time it took. Our library manager had a 1GB DB and contained no client data. When the library controller contains no client data you can easily move from 5.x to 6.x without all the headaches of a DB upgrade through the extract and insert process (which took 1 hour to complete once we started the insert). Here are the basic steps to easily upgrade a TSM library manager:
  • Backup the TSM library manager DB
  • Backup Volhist and Devconfig
  • Copy all define statements from devconfig into a TSM macro
  • Uninstall TSM 5.5
  • Install TSM 6.x
  • Follow the steps to create a new TSM 6.x server
  • Start the TSM 6.x server
  • Run the macro to redefine all the servers, devclasses, libraries, drives, and paths
  • Check-in the tapes to the library
  • Run audit library from each of the library clients
It might seem like a lot, but once you've got the TSM 6.x server up and running, defining the other items is easy and will take a lot less time than running the upgrade process.

NOTE: This only works if you do not perform ANY backups (Client or NAS) to the library manager.

Tuesday, July 31, 2012

TSM 5.5 to 6.2.4 Upgrade

I recently did a network based upgrade of a 270GB DB. Previously TSM could take days to due the upgrade of a DB so large, but my experience with performing upgrades for other companies and some suggestions from my Tivoli Consultant had me convinced it could be done in under 24 hrs. The network method is kind of a misnomer here since we used the loop-back address, so the upgrade was done in place on the server. After allocating additional disk space (a lot of disk space) and defining the user ID TSM would run under, I started the upgrade process by running the dsmupgrd preparedb process. The upgrade took less than an hour and completed successfully. I copied our devconfig and volhist files to an alternate location and then started the insert under the id of the new TSM 6.2.4 instance. I then switched back to root, cd'd to the upgrade directory, set my environmental variables accordingly, and then started the extract.

The extract took 5 hours and ran without issue. The insert ran for 11 hours and completed without errors. The overall time from start of the upgrade to end was 13 hours. My reason for testing was to verify the time frame needed so the applications that rely on TSM for log offloading could add to their additional log space ahead of time. If anyone has suggestions on how I can make the extract/insert performance even better feel free to post a comment.

Tuesday, December 6, 2011

TSM 6.x Client Deployment

Has anyone used TSM's client deployment process/function?  How well does it work? Is it worth the effort? I have a lot of servers we need to install TSM too and would like to utilize it if it will work.

Friday, June 10, 2011

TSM Server V6 AIX Install/Upgrade Gotchas

So after setting up numerous TSM 6.1 and 6.2 servers here are a few of the things that have been little gotchas. They were never upgrade stoppers but they did cause some headaches as we determined what was causing the errors.

  • Check the ATAPE version (recommend 11.x)
  • Check your xlC C++ runtime level (recommend 9.0.0.8 or greater)
  • With AIX you must have IOCP set to available or else you'll have to update the OS setting and reboot the server.
  • Make sure the user id that the TSM 6.x instance is running under has ulimit set to unlimited. Real pain when you go to create disk volumes and you forgot to set the ulimit. It was my absentminded moment!
  • Don't forget that the tsmdbmgr.log file ownership needs to be the new ID not root.
  • Also when using RAW disk volumes for TSM diskpools chown the device file (example: /dev/rtsmdata01) to the new user id or TSM will say it's unavailable.
  • With a recent upgrade we could not get the TSM DB backup to execute without an error. It turned out the TSM client's dsmtca file ownership had been accidentally changed to the TSM server's user ID and it MUST BE OWNED BY ROOT for the backup of the TSM DB to execute successfully.
If you have anything you've experienced you consider a "GOTCHA" , whether it be UNIX or Windows, then leave a comment and help others who might run across the same issue(s).

    Wednesday, November 3, 2010

    TSM 6.1...Finally!!!

    So I have landed on my feet as a contractor and where I am currently working they are migrating to 6.1.4 TSM from 5.x versions. In their testing they found a 36GB DB took 14 hours for the complete migration of the DB. This time includes completing storage pool migration, stopping all processes, and bringing down the original TSM server clean.  So I am not looking forward to the large 100+GB DB's.  I also find it interesting how many companies have not migrated to version 6. The only reason they are going  to 6.1.x is that it has been tested and 6.2 has not (their testing process is long and tedious).  So what has everyone else seen as their average migration time from 5.x to 6.x?

    Thursday, March 18, 2010

    Obstacles Upgrading to 6.1

    I have a server with 8 instances of TSM running on it. The first instance is the library controller and the other seven are production instances. So the problem has been how to best reconfigure everything for TSM 6.1 since IBM says it's best not to run multiple instances on the same server unless they are in their own LPAR. So what I have been trying to figure out is how best to migrate to 6.1 with the least impact. I figure I will need to merge the 7 production instances into 3 or 4, but then what would be the best procedure for dividing up the hardware (i.e. NICs and HBA's) for the other LPARs. Any suggestions?

    Thursday, May 14, 2009

    TSM 6.1 Upgrade - Need To Know!

    So In researching the TSM 5.5 to 6.1 upgrade I have come across a number of issues that should have been compiled into a complete list to keep admins informed. So here it goes.

    Things to know about TSM 6.1:
    • Although stated that the 6.1 DB should be the same size as the 5.5 DB the TSM community is claiming as much as 4x the space is required
    • It does not support RAW volumes for the TSM DB and Log
    • It has added archive logging to the existing log process (i.e. more disk space required to run)
    • It cannot generate or define backupsets at this time
    • It does not support NAS or Backupset TOC's at this time
    • It will not allow a DB upgrade if TOC's or Backupsets exist on the current TSM server
    • NQR (No Query Restore) is now slower due to how 6.1 processes the data before sending it to the client
    I have been hearing of upgrades taking an extremely long time so be aware that if doing an upgrade the TSM source instance has to be down to allow the upgrade when doing it across the LAN or on the same server.  Even with the media method your source instance has to be down to perform the DB dump since 6.1 cannot use a standard TSM DB backup.


    Tuesday, May 5, 2009

    TSM 6.1 Upgrade - FYI

    For those of you looking to upgrade your current TSM instances to 6.1 take note of this issue with upgrading the DB.

    At this time a database containing backup sets or tables of contents (TOCs) cannot be upgraded to V6.1. The database upgrade utilities check for defined backup sets and existing TOCs. If either exists, the upgrade stops and a message is issued saying that the upgrade is not possible at the time. In addition, any operation on a V6.1 server that tries to create or load a TOC fails.

    When support is restored by a future V6.1 fix pack, the database upgrade and all backup set and TOC operations will be fully enabled.


    I haven't heard if this will be fixed in the first patch of 6.1 but keep it in mind when considering upgrading your system rather than starting from scratch.

    Sunday, March 2, 2008

    Tivoli Storage Manager v5.5...

    REPOST: I think this article from Flex is a good one to keep on the front page since TSM 5.5 migrations are only going to continue. Check the comments for solutions to this problem.

    Today afternoon I had a little time and tried the brand new v5.5 client on MS Windows platform (x32) and got this error message in the dsmerror.log:
    "ANS1009W An error occurred processing the operating system include/exclude statements.
    The error was detected while processing: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\BackupRestore\FilesNotToBackup\DRM. RC = 13."

    I didn't want to believe what I saw. This funny message still exists.
    Here is the solution from IBM: ANS1009W DRM FilesNotToBackup RC 13
    /* Edit the registry manually... this is the solution in the 21st century... */

    Do you have this problem? Here in Hungary, all Windows servers are affected...

    I like the TSM concepts itself but I don't even want to think about what ISC 5.5 will be like... ;-)

    I really miss the 64bit HSM and Journal on MS Windows (we got only Online image and Open file), where is the IBM 3494 support on HP-UX Itanium (I don't understand why this is a problem for a developer? Someone could really explain it...), on the fly db reorg function (ESTIMATE DBREORGSTAT - What a solution? ), ... but the restartable server-to-server export/import sounds good.

    Cheers!

    Friday, November 16, 2007

    TSM 5.5 Available Today + TSM 5.4 Upgrade (or not) + The End is Nigh for TSM 5.3

    Howdy folks,

    Further to Chad's post, here's the full announcement on www.ibm.com (worth a look as it's pretty comprehensive):

    >>> http://www-01.ibm.com/common/ssi/cgi-bin/ssialias?subtype=ca&infotype=an&appname=iSource&supplier=877&letternum=ENUSZP07-0476


    (I spy this link is also hidden away in one of the comments below)

    TSM 5.5 is available for download for Passport Advantage customers as of today (Friday 16th of November 2007), and media is available from 14th December 2007.

    There's also an IBM Redbook for TSM 5.5 being written at this very moment and there's likely to be a draft available mid-December (thanks for the info Craig).

    Finally for now, it's worth noting that after a touch over three years in service, TSM 5.3 goes out of support at the end of April 2008 - time to exercise those upgrade muscles as I'm sure many shops haven't even taken the leap up to TSM 5.4 yet.
    However, if this all seems too daunting too soon, I understand that IBM are offering extended support for 5.3 for two further years (at cost).
    Over and out...

    David McClelland
    London, UK

    Wednesday, February 14, 2007

    5.4 Upgrade Yes/No?

    After Geoffrey's post I thought I would ask all of you if anyone is planning on upgrading to the 5.4.0 release of TSM. When I was with IBM we tended to wait til the first point release, so I am wondering if anyone is really going to upgrade at this point? Also for those playing with the new release, did they improve the ISC or is it still a mess?

    Tuesday, July 19, 2005

    TSM Server Upgrade Issue

    Just this last week I and a co-worker were trying to get a TSM 5.3 upgrade working. The server kept saying it needed the dsmserv upgradedb command run against it. Everytime we tried the DB upgrade failed with an TIVGUID error. Since it was eating into backup times we rolled back to 5.2.4. Unfortunately the dsmserv upgrade caused 5.2.4 to state that the DB was higher level and TSM could not work with it. This happened even though the upgrade on 5.3 failed. Since support had not responed at this time we restored the DB from a full+inc that was taken just before the upgrade (WHEW! LUCKY WE HAD THAT!). When Tivoli finally responded this is what we were told:

    This is a know problem with the 5.3.0 upgrade.

    From TSM Support:

    The problem that you are probably experiencing is a known problem with the 5.3 upgrade. If an admin has an expired password, or if a password is too short for the 5.3 password enforcement, then the upgrade can fail. Here are some steps that usually fix the problem:

    1) Disable AES using the hidden option AllowAES No in dsmserv.opt file.
    2) Re-initiate the upgrade db
    3) Start the server. Preferably lock out all sessions & other activity
    4) Use show node to identify admin & node ids that have expired or have passwords that are too short. Fix these.
    (4 Alternative) Set the minimum password length to 0
    5) Halt the server
    6) Remove the AllowAES option
    7) Start the server -- this will upgrade the passwords to AES encryption in the background

    If you follow these steps then the upgrade db will probably continue successfully.

    After this, start the server in background as usually and run a db backup.


    SO ALL THIS OVER A PASSWORD!