ADSM-L

[ADSM-L] Ang: Migrating from AIX to Linux (again)

2011-11-16 11:07:33
Subject: [ADSM-L] Ang: Migrating from AIX to Linux (again)
From: Daniel Sparrman <daniel.sparrman AT EXIST DOT SE>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Wed, 16 Nov 2011 16:57:05 +0100
Hi John

Not sure where you've read that crossplattform migration by db backup/restore 
has been possible previously. Since TSM was called ADSM 3.1, exporting nodes 
has been the only available option to do a crossplattform move of TSM.

Previously, you could only export nodes to sequential media, but in newer 
version (I think it was somewhere around v5), you are now able to do a export 
directly to a target server.

Most of my customers has chosen 1. below due to the amount of historical data 
that needs to be kept for a long. However, if your versioning and save times 
are short, redirecting backups to the new TSM server and just deleting the old 
one when new historical data has been built up in the new one is a viable 
option. However, most people want to get rid of the old TSM server as fast as 
possible, since it holds up storage. So make sure that the timeframe for 
building up historical data in your new TSM server is fairly short.

Regards

Daniel 


Daniel Sparrman
Exist i Stockholm AB
Växel: 08-754 98 00
Fax: 08-754 97 30
daniel.sparrman AT exist DOT se
http://www.existgruppen.se
Posthusgatan 1 761 30 NORRTÄLJE

-----"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> skrev: -----
Till: ADSM-L AT VM.MARIST DOT EDU
Från: "Dury, John C." 
Sänt av: "ADSM: Dist Stor Manager" 
Datum: 11/16/2011 16:48
Ärende: Migrating from AIX to Linux (again)

Our current environment looks like this:
We have a production TSM server that all of our clients backup to throughout 
the day. This server has 2 SL500 tape libraries attached via fiber. One is 
local and the other at a remote site which is connected by dark fiber. The 
backup data is sent to the remote SL500 library several times a day in an 
effort to keep them in sync.  The strategy is to bring up the TSM DR server at 
the remote site and have it do backups and recovers from the SL500 at that site 
in case of a DR scenario.

I've done a lot of reading in the past and some just recently on the possible 
ways to migrate from an AIX TSM server to a Linux TSM server. I understand that 
in earlier versions (we are currently at 5.5.5.2) of the TSM server it allowed 
you to backup the DB on one platform (AIX for instance) and restore on another 
platform (Linux for instance) and if you were keeping the same library, it 
would just work but apparently that was removed by IBM in the TSM server code 
to presumably prevent customers from moving to less expensive hardware. (Gee, 
thanks IBM! <sigh>).
I posted several years ago about any possible ways to migrate the TSM Server 
from AIX to Linux.
The feasible solutions were as follows:

1.       Build new linux server with access to same tape library and then 
export nodes from one server to the other and then change each node as it's 
exported, to backup to the new TSM Server instead.  Then the old data in the 
old server can be purged. A lengthy and time consuming process depending on the 
amount of data in your tape library.

2.       Build a new TSM linux server and point all TSM clients to it but keep 
the old TSM server around in case of restores for a specified period of time 
until it can be removed.

There may have been more options but those seemed the most reasonable given our 
environment. Our biggest problem with scenario 1 above is exporting the data 
that lives on the remote SL500 tape library would take much longer as the 
connection to that tape library is slower than the local library.  I can 
probably get some of our SLAs adjusted to not have to export all data and only 
the active data but that remains to be seen.

My question. Has any of this changed with v6 TSM or has anyone come up with a 
way to do this in a less painful and time consuming way? Hacking the DB so the 
other platform code doesn't block restoring an AIX TSM DB on a Linux box? 
Anything?

Thanks again and sorry to revisit all of this again. Just hoping something has 
changed in the last few years.
John