ADSM-L

Migrating an HSM filesystem

2007-02-08 16:52:23
Subject: Migrating an HSM filesystem
From: Anker Lerret <ADSM-L AT LERRET DOT US>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Thu, 8 Feb 2007 16:51:01 -0500
We need to move an HSM-enabled filesystem from one TSM client node to
another.  The old client node is a venerable S70 (Regatta class machine)
running AIX 5.2 with a 5.2.2.0 TSM client.  The new client node will be
running AIX 5.3 with (unless I hear recommendations to the contrary from
the list) the latest TSM client compatible with the server (I think that
will be 5.3.4.0.).  The TSM server is running AIX 5.3 with TSM 5.3.3.0.

After some poking around in the list archives, I get the impression that
we have two options.  The first is to setup the new TSM client and then
copy the files across (scp, I suppose?).  This would cause each file to be
recalled, transferred across the network and then re-migrated.  It would
have the advantage of leaving a pristine copy on the old client, in case
of disaster or even of questions about the veracity of the copy.  The
disadvantage is that we're talking about 4 terabytes of data, so it could
take a while.

The second option is to issue RENAME NODE OLDCLIENT NEWCLIENT and restore
the stub files on the new client.  Richard Sims outlines the technique in
http://www.mail-archive.com/adsm-l AT vm.marist DOT edu/msg56480.html .  Here's
my understanding of what Richard proposes:

Step 1: Unmount the HSM filesystem on OLDCLIENT, exposing the stub files.
Step 2: RENAME NODE OLDCLIENT NEWCLIENT on the TSM server.
Step 3: Use something (scp or tar) to move the stub files to NEWCLIENT.
Step 4: Mount the HSM filesystem on NEWCLIENT.

Do I have the steps right?
Has anyone done this successfully?
What problems did you have?

One last note: We are deeply, almost superstitiously, afraid of HSM.  We
have had numerous problems with HSM and have never felt comfortable with
it.  Our only wholesale loss of TSM data involved HSM; our users still
remember it and still have unkind feelings toward TSM because of it--and
it happened five years ago.  We generally keep all of our software quite
current, but you will notice that we are running this TSM client at quite
an old level--because we finally found a level that made HSM behave well
and we're terrified to change it.  Can anyone say anything that would make
me feel confident about what we're about to do?

Thanks,
anker

<Prev in Thread] Current Thread [Next in Thread>