• Please help support our sponsors by considering their products and services.
    Our sponsors enable us to serve you with this high-speed Internet connection and fast webservers you are currently using at ADSM.ORG.
    They support this free flow of information and knowledge exchange service at no cost to you.

    Please welcome our latest sponsor Tectrade . We can show our appreciation by learning more about Tectrade Solutions
  • Community Tip: Please Give Thanks to Those Sharing Their Knowledge.

    If you receive helpful answer on this forum, please show thanks to the poster by clicking "LIKE" link for the answer that you found helpful.

  • Community Tip: Forum Rules (PLEASE CLICK HERE TO READ BEFORE POSTING)

    Click the link above to access ADSM.ORG Acceptable Use Policy and forum rules which should be observed when using this website. Violators may be banned from this website. This notice will disappear after you have made at least 3 posts.

TSM Server migration from v5.5 to 6.2

k3t5

Active Newcomer
#1
Hi,

Currently I have 1 server that has a working TSM Server V5.5, and I have another new server that is going to have a new installation of TSM Server v6.2. I need to know how and what procedures to take to migrate everything from TSM Server v5.5 to the new system that has TSM Server v6.2.

many thanks.
 

moon-buddy

ADSM.ORG Moderator
#2
Hi,

Currently I have 1 server that has a working TSM Server V5.5, and I have another new server that is going to have a new installation of TSM Server v6.2. I need to know how and what procedures to take to migrate everything from TSM Server v5.5 to the new system that has TSM Server v6.2.

many thanks.
Search the forum as there are many posts about this.
 

chad_small

ADSM.ORG Moderator
#3
You have three options
1. Upgrade over LAN
2. Upgrade using tape media (extract/insert method)
3. Start from scratch and migrate all clients to new server

The first two are discussed in the TSM migration instructions.
 

k3t5

Active Newcomer
#5
Hi Buddy, I could do with some advise on this please. These servers are AIX servers. We are first planning to do a test run of this before we go live is this possible. Can you give me some steps on how I can perform this migration.

Thanks.
 

k3t5

Active Newcomer
#6
You have three options
1. Upgrade over LAN
2. Upgrade using tape media (extract/insert method)
3. Start from scratch and migrate all clients to new server

The first two are discussed in the TSM migration instructions.
Hi Chad, I have sent you an email please if you get a moment can you check this. Really could do with some advice.
 

moon-buddy

ADSM.ORG Moderator
#7
Hi Buddy, I could do with some advise on this please. These servers are AIX servers. We are first planning to do a test run of this before we go live is this possible. Can you give me some steps on how I can perform this migration.

Thanks.
Since you have a new AIX server, if I am the one doing the migration, I would do this:

1. Setup the new server for TSM 5.5 - same version as the existing one
2. Import the DB from the exisiting to the new one - note for settings like TCP/IP, server name, etc.
3. Update the new server to 6.2.x, and stop all TSM operations on the old one
4. Move all peripeherals to the new server
 

k3t5

Active Newcomer
#8
Since you have a new AIX server, if I am the one doing the migration, I would do this:

1. Setup the new server for TSM 5.5 - same version as the existing one
2. Import the DB from the exisiting to the new one - note for settings like TCP/IP, server name, etc.
3. Update the new server to 6.2.x, and stop all TSM operations on the old one
4. Move all peripeherals to the new server
Hi Buddy,

Am currently reading this link:

http://pic.dhe.ibm.com/infocenter/t...m.itsm.srv.install.doc/t_srv_inst_overvu.html

The new server has an installed version of TSM 6.2
 

k3t5

Active Newcomer
#9
Since you have a new AIX server, if I am the one doing the migration, I would do this:

1. Setup the new server for TSM 5.5 - same version as the existing one
2. Import the DB from the exisiting to the new one - note for settings like TCP/IP, server name, etc.
3. Update the new server to 6.2.x, and stop all TSM operations on the old one
4. Move all peripeherals to the new server
Hi Buddy,

Am quiet confused about upgrading the database on the original TSM server v5.5 not sure what the means.
 

moon-buddy

ADSM.ORG Moderator
#10
Hi Buddy,

Am quiet confused about upgrading the database on the original TSM server v5.5 not sure what the means.
If you update the exiting 5.5 to 6.2, the database needs to be upgraded to the full blown DB2 along the way. This is what it means.

Since my proposal is to essentially duplicate the existing 5.5 into the new server, you are also practically doing the same: upgrading the database.
 
Last edited:

k3t5

Active Newcomer
#11
If you update the exiting 5.5 to 6.2, the database needs to be upgraded to the full blown DB2 along the way. This is what it means.

Since my proposal is to essentially duplicate the existinf 5.5 into the new server, you are also practically doing the same: upgrading the database.
For my scenario I have the original tsm server v5.5 and a new system with tsm v6.2 installed, Initially I want to just do a test upgrade process to see how long it takes, to upgrade and that we don't encounter any issues. How would I be able to do this without losing my original server or any data loss. I want to keep my original server functioning. Do I still have to use the DSMUPGRD utility on original server.

Thanks appreciate your help.
 

rvining

Active Newcomer
#12
Hi, k3t5,

If you want to keep your existing v5.5 server running, you can do that. All you need to do is stop all backup operations on the old server and start them on the new server. Keep the old server running for restores of the old data. Hopefully you have expiration policies set for the old data in the old server, and once all that old data is expired, you can retire the old server.

We see a lot of shops using this model when the expiration period for the old data is a reasonable length of time (less than the expected service life of the server).
 

k3t5

Active Newcomer
#13
Hi, k3t5,

If you want to keep your existing v5.5 server running, you can do that. All you need to do is stop all backup operations on the old server and start them on the new server. Keep the old server running for restores of the old data. Hopefully you have expiration policies set for the old data in the old server, and once all that old data is expired, you can retire the old server.

We see a lot of shops using this model when the expiration period for the old data is a reasonable length of time (less than the expected service life of the server).
Hi Rvining,

For my scenario I have the original tsm server v5.5 and a new system with tsm v6.2 installed, Initially I want to just do a test upgrade process to see how long it takes, to upgrade and that we don't encounter any issues. How would I be able to do this without losing my original server or any data loss. I want to keep my original server functioning. Do I still have to use the DSMUPGRD utility on original server.
 

rvining

Active Newcomer
#14
Sorry, I didn't understand your original post. Yes, you should be able to run the upgrade process, which basically copies the TSM v5.5 database records into the new TSM v6.x database and terminate it at some point to see how many db records/minute are being migrated.
 

k3t5

Active Newcomer
#15
Sorry, I didn't understand your original post. Yes, you should be able to run the upgrade process, which basically copies the TSM v5.5 database records into the new TSM v6.x database and terminate it at some point to see how many db records/minute are being migrated.
Thanks, I just don't seem to understand after I have done the extraction why I need to restore the original server database. Have you done an upgrade.
 

rvining

Active Newcomer
#16
No, I haven't done an upgrade - I am with the IBM Tivoli Storage worldwide product management team. The steps that you will need to perform will depend on the upgrade method you choose. It only seems complicated because we replaced the internal database in v6.1, now using a highly scalable DB2 database.

If you use the included upgrade utility, it simply copies the old database (legacy proprietary TSM internal DB) to the new database (DB2), then you configure your clients and policies on the new server, and start running from there. The old server can be decommissioned at that time - there is no need to restore anything on the old server. No backup data needs to be copied or migrated either - it will all be available on the new server. Your TSM downtime during the upgrade will be largely a factor of how long it takes to migrate the database content.

The second choice is as I described earlier - configure and start using the new server (start with a full backup of all your clients). Use the old server simply to restore older versions of backup files until all files on that server expire. This method results in almost no downtime but you will have to manage 2 backup systems for some period of time.

There is another option, leveraging our recently acquired Butterfly Migration Engine. This service performs the database migration in the background while you continue to use your old system. There is a fee for this service, but it provides the most seamless, no downtime option for performing the upgrade. Your sales rep or business partner can provide you more info on this option.

I hope this helps.
 

sgabriel62

ADSM.ORG Senior Member
#17
K3t5;
Since you are having a bit of trouble understanding the upgrade process - and since you have the new TSM Server already created and running - I would recommend you redirect your nodes to the new TSM server - establish - New fulls and incrmentals - and allow the original server to be used for historical or long term data - restores.
Once all the data has been expired or if you choose to export between servers - then you can shut down the original TSM Server.

There has been testing of upgrades with the clientelle I support - one took 36 hrs based on its size and table space restructuring. Another group did it in a weekend which included the db2 reorg.
In your test - Id do whats already suggested --- import the DB on the test server run the upgrade utility and take down some numbers. If you are please with this result - and want to use it straight away then redirecting your tape libraries and such. If this is your first time - then use it as a learning experience.

Good luck
 

Advertise at ADSM.ORG

If you are reading this, so are your potential customer. Advertise at ADSM.ORG right now.

UpCloud high performance VPS at $5/month

Get started with $25 in credits on Cloud Servers. You must use link below to receive the credit. Use the promo to get upto 5 month of FREE Linux VPS.

The Spectrum Protect TLA (Three-Letter Acronym): ISP or something else?

  • Every product needs a TLA, Let's call it ISP (IBM Spectrum Protect).

    Votes: 17 19.5%
  • Keep using TSM for Spectrum Protect.

    Votes: 53 60.9%
  • Let's be formal and just say Spectrum Protect

    Votes: 10 11.5%
  • Other (please comement)

    Votes: 7 8.0%

Forum statistics

Threads
31,468
Messages
134,115
Members
21,565
Latest member
Chrescht
Top