Backup Central

We are making plans for the upgrade from 5.5 -> 6.2 this Spring. One, of many, thing that's causing much headscratching is consistency.

I know that the Library Manager must be first. Since it has no clients, no problems with the conversion. However, the LAN-FREE storage agents, which must be at the same level as the LM, are all on our largest instance, which I'd prefer to leave till last in the conversion schedule. We think that the client level for those machines must also be at the same level as the LM. Also on that instance are the datamovers using NDMP. We're not sure if those must also be at the same level as the LM. We think the approach should be : 1. Upgrade the LM, 2. Upgrade the necessary agents and clients, and 3. Tackle a less complicated instance to convert completely.

Are we thinking in the right track here? All thoughts appreciated.

Another unanswered question is whether we can do the conversion directly into 6.2, or do we have to go 6.1.0 -> 6.2? If the latter, will we have to pass quickly thru 6.1.2? I hope this will be addressed in the documentation, whenever that becomes available.


Fred Johanson
TSM Administrator
University of Chicago

773-702-8464

Hi Fred,

See technotes 1053218 and 1302789 you may find usefull :
http://www-01.ibm.com/support/docview.wss?uid=swg21053218
http://www-01.ibm.com/support/docview.wss?uid=swg21302789
(this second one has not been updated with TSM 6.2 yet)

--
Best regards / Cordialement / مع تحياتي
Erwann SIMON

Le 04/03/2010 23:18, Fred Johanson a écrit :

Quote:

We are making plans for the upgrade from 5.5 -> 6.2 this Spring. One, of many, thing that's causing much headscratching is consistency.

I know that the Library Manager must be first. Since it has no clients, no problems with the conversion. However, the LAN-FREE storage agents, which must be at the same level as the LM, are all on our largest instance, which I'd prefer to leave till last in the conversion schedule. We think that the client level for those machines must also be at the same level as the LM. Also on that instance are the datamovers using NDMP. We're not sure if those must also be at the same level as the LM. We think the approach should be : 1. Upgrade the LM, 2. Upgrade the necessary agents and clients, and 3. Tackle a less complicated instance to convert completely.

Are we thinking in the right track here? All thoughts appreciated.

Another unanswered question is whether we can do the conversion directly into 6.2, or do we have to go 6.1.0 -> 6.2? If the latter, will we have to pass quickly thru 6.1.2? I hope this will be addressed in the documentation, whenever that becomes available.


Fred Johanson
TSM Administrator
University of Chicago

773-702-8464

Fred,
According to the table at:

http://www-01.ibm.com/support/docview.wss?uid=swg21302789

the TSM library master could be at 6.1, and the storage agent left
behind at 5.5 or even 5.4.

You are remembering outdated information, I think. So this should
simplify your plans.

This was very good news for us, too. We have one library master that
serves 9 other TSM servers, plus 5 Lan-free agents. The thought of
having to upgrade ALL of them on the same day was daunting indeed. But
thankfully, we can do them in groups. Because we have as many as 4
instances on one server, we will be forced by the upgrade requirements
to upgrade all of those on the same day. At least, I think that is
true. When I upgraded a test server from 5.4 to 6.1 a couple weeks ago,
I was told to uninstall 5.4 before installing 6.1, and that they could
not exist on the same server. Am I understanding this correctly?

Best Regards,

John D. Schneider
The Computer Coaching Community, LLC
Office: (314) 635-5424 / Toll Free: (866) 796-9226
Cell: (314) 750-8721



-------- Original Message --------
Subject: [ADSM-L] 5.5 -> 6.2
From: Fred Johanson <Fred < at > UCHICAGO.EDU>
Date: Thu, March 04, 2010 4:18 pm
To: ADSM-L < at > VM.MARIST.EDU

We are making plans for the upgrade from 5.5 -> 6.2 this Spring. One, of
many, thing that's causing much headscratching is consistency.

I know that the Library Manager must be first. Since it has no clients,
no problems with the conversion. However, the LAN-FREE storage agents,
which must be at the same level as the LM, are all on our largest
instance, which I'd prefer to leave till last in the conversion
schedule. We think that the client level for those machines must also be
at the same level as the LM. Also on that instance are the datamovers
using NDMP. We're not sure if those must also be at the same level as
the LM. We think the approach should be : 1. Upgrade the LM, 2. Upgrade
the necessary agents and clients, and 3. Tackle a less complicated
instance to convert completely.

Are we thinking in the right track here? All thoughts appreciated.

Another unanswered question is whether we can do the conversion directly
into 6.2, or do we have to go 6.1.0 -> 6.2? If the latter, will we have
to pass quickly thru 6.1.2? I hope this will be addressed in the
documentation, whenever that becomes available.


Fred Johanson
TSM Administrator
University of Chicago

773-702-8464

----- "John D. Schneider" <john.schneider < at > COMPUTERCOACHINGCOMMUNITY.COM> wrote:

Quote:

This was very good news for us, too. We have one library master that
serves 9 other TSM servers, plus 5 Lan-free agents. The thought of
having to upgrade ALL of them on the same day was daunting indeed.
But
thankfully, we can do them in groups. Because we have as many as 4
instances on one server, we will be forced by the upgrade
requirements
to upgrade all of those on the same day. At least, I think that is
true. When I upgraded a test server from 5.4 to 6.1 a couple weeks
ago,
I was told to uninstall 5.4 before installing 6.1, and that they
could
not exist on the same server. Am I understanding this correctly?

The problem with upgrading from v5 to v6 is that you do indeed need to uninstall one before installing the other - not like from 5.4 to 5.5 at all. The upgrade process involves a database dump and import a bit like an unload/reload and unfortunately about as slow - the speed stated by IBM for the import is about 5GB/hour and from my experience that's about right from disk and from LTO-3 tape.

The best way to upgrade in my opinion, unless your database is tiny, is to put the new version on a new bit of hardware, and use the 'export server' command to move config from the old to the new, then combine full backups to the new server and 'export node filed=all' to get the data across, finally deleting the nodes from the old server when you're comfortable with it. Regardless, it's a bunch of tape mounts and time, but at least it's a well controlled process and doesn't take down the TSM servers meantime.

Let the list know how you got on!

On 5 mrt 2010, at 02:44, Xav Paice wrote:

Quote:

----- "John D. Schneider" <john.schneider < at > COMPUTERCOACHINGCOMMUNITY.COM> wrote:

Quote:

This was very good news for us, too. We have one library master that
serves 9 other TSM servers, plus 5 Lan-free agents. The thought of
having to upgrade ALL of them on the same day was daunting indeed.
But
thankfully, we can do them in groups. Because we have as many as 4
instances on one server, we will be forced by the upgrade
requirements
to upgrade all of those on the same day. At least, I think that is
true. When I upgraded a test server from 5.4 to 6.1 a couple weeks
ago,
I was told to uninstall 5.4 before installing 6.1, and that they
could
not exist on the same server. Am I understanding this correctly?

The problem with upgrading from v5 to v6 is that you do indeed need to uninstall one before installing the other - not like from 5.4 to 5.5 at all. The upgrade process involves a database dump and import a bit like an unload/reload and unfortunately about as slow - the speed stated by IBM for the import is about 5GB/hour and from my experience that's about right from disk and from LTO-3 tape.

The best way to upgrade in my opinion, unless your database is tiny, is to put the new version on a new bit of hardware, and use the 'export server' command to move config from the old to the new, then combine full backups to the new server and 'export node filed=all' to get the data across, finally deleting the nodes from the old server when you're comfortable with it. Regardless, it's a bunch of tape mounts and time, but at least it's a well controlled process and doesn't take down the TSM servers meantime.

huuh????, I know some of us have huge TSM database, but export/import for all node data for such a server is highly unlikely to complete in our lifetime.

I'd say, either go for the downtime, or just build a new server (maybe export server) and then just point your clients to the new server. You need bigger faster hardware anyway for TSM 6.....

Quote:

Let the list know how you got on!

--

Met vriendelijke groeten/Kind regards,

Remco Post

On Thursday 04 Mar 2010 11:46 pm, John D. Schneider wrote:

Quote:

Because we have as many as 4
instances on one server, we will be forced by the upgrade requirements
to upgrade all of those on the same day. At least, I think that is
true. When I upgraded a test server from 5.4 to 6.1 a couple weeks ago,
I was told to uninstall 5.4 before installing 6.1, and that they could
not exist on the same server. Am I understanding this correctly?

John,

the problem of co-existence - at least on AIX - is actually at installation
time. On test and beta-test systems we successfully ran 6.1 and 5.5
servers. If my memory serves me, installing 6.1 trashed the existing 5.5
code - so, copy the code /usr/tivoli/tsm/server/bin to a separate area
before installing 6.1, and point your environment variables - DSMSERV_DIR
and DSMSERV_CONFIG - appropriately.

Of course, this leaves you unable to upgrade 5.5 on this box, but if you
have another LPAR / machine available, you can always install the upgrade
version there and copy across the binaries.

As I said, we ran this in a test environment, its not something I'd
willingly do in a production one, but sometimes needs must when the devil
drives ...

Ian Smith
Oxford University Computing Services

----- "Remco Post" <r.post < at > PLCS.NL> wrote:

Quote:

huuh????, I know some of us have huge TSM database, but export/import
for all node data for such a server is highly unlikely to complete in
our lifetime.

I'd say, either go for the downtime, or just build a new server (maybe
export server) and then just point your clients to the new server. You
need bigger faster hardware anyway for TSM 6.....

Most people with larger databases cannot cope with the downtime, measured in days, that it takes to import the database. There are ways to import on a new server whilst leaving the old server running (restore db, new storage pool to leave the old one untouched, export the new data when everything is done) which might be more palatable, but I've not tried them.

Mostly I'm finding now that people don't just want to migrate to a new server if they have a massive database - they want to combine that action with splitting into more instances to reduce the db size. Export/import is a good way to achieve that.

I'd be keen to try to do a full backup of nodes to the new server, so long as the client can complete that within a reasonable time. If it takes 3 days to make a full backup then the node has no valid backup for 3 days. Typically the client is the slow point rather than the server. I'd be concerned if the amount of time taken to migrate the node data to a new server using 'export node' is too long - that's a background process which can be done in advance of moving the node, but note that it should take only a bit longer than the restore of that node. If it takes a week to restore a node that would be well outside of SLA would it not?

The other issue with just doing full backups to the new server is the historical data that still lives on the old server. If it takes a year (or more) for that old data to expire, then surely that means keeping old instances of TSM hanging around for history? Many clients also don't want that as they must return hardware for lease expiry, trade-in, etc. let alone having to maintain yet another box. Not a problem if your RETONLY is 10 days and archives are only kept for a month, but if your archives are there for 7 years you have no choice but to move stuff around somehow.

The result is that you must pick the migration method on a per node basis - there are many factors to decide which method is chosen, none of which are ideal.

On 7 mrt 2010, at 23:37, Xav Paice wrote:

Quote:

Most people with larger databases cannot cope with the downtime, measured in days, that it takes to import the database.

I fully agree with you on this one. Having a larger than recommended database is now a challenge to these customers.

---8<---

Quote:

Mostly I'm finding now that people don't just want to migrate to a new server if they have a massive database - they want to combine that action with splitting into more instances to reduce the db size. Export/import is a good way to achieve that.

I partly agree. Splitting the database makes a lot of sense in the TSM 5 era, with TSM 6, there is less reason to do so, provided that IBM will never ever make us go through such an upgrade again.

Quote:

I'd be keen to try to do a full backup of nodes to the new server, so long as the client can complete that within a reasonable time. If it takes 3 days to make a full backup then the node has no valid backup for 3 days. Typically the client is the slow point rather than the server. I'd be concerned if the amount of time taken to migrate the node data to a new server using 'export node' is too long - that's a background process which can be done in advance of moving the node, but note that it should take only a bit longer than the restore of that node. If it takes a week to restore a node that would be well outside of SLA would it not?

A full backup and a full restore of a node should ideally take about the same amount of time. With a restore, there is of course a bit more tape-handling going on. An export, OTOH, needs to crawl through all active and inactive objects, rather than only the active objects. This may take quite some extra time. You are right, one could run a partial export and incrementally export a node if an export takes to long.

Quote:

The other issue with just doing full backups to the new server is the historical data that still lives on the old server. If it takes a year (or more) for that old data to expire, then surely that means keeping old instances of TSM hanging around for history?

Backup data retention of more than a few months is a problem. I know a lot of people have a hard time convincing customers that this data should most likely be archived, and I know that such retentions exists. And yes, in such cases, one would need either to export/import or keep the data around in the old server for such a long period.

Quote:

Many clients also don't want that as they must return hardware for lease expiry, trade-in, etc. let alone having to maintain yet another box. Not a problem if your RETONLY is 10 days and archives are only kept for a month, but if your archives are there for 7 years you have no choice but to move stuff around somehow.

so, export the archive data (usually, if you're smart that's just a small bit), and restart your backups.

Quote:

The result is that you must pick the migration method on a per node basis - there are many factors to decide which method is chosen, none of which are ideal.

I prefer to do a 5.4 to 5.5 upgrade over anything to do with 6.1...


--
Met vriendelijke groeten/Kind regards,

Remco Post
r.post < at > plcs.nl