Anker,
I too am very afraid of HSM and always approach any HSM-related upgrade
( even an OS patch ) with a mixture of fear and loathing :)
By way of background: We moved our HSM data ( c 20 filesystems ) across
physical hosts _and_ from 5.2.x client level to 5.3.0.
We also kept the same client identity on the TSM server - and I'm
not clear what you will gain by renaming the client as you propose ?
Anyway, some general points:
First - the AIX client as of 5.3.0 is JFS2 only - the procedure for
migrating from JFS to JFS2 is documented in the TSM 5.3.0 AIX client
README_hsm_enu.htm file.
( Note that this procedure advises you to create the JFS2 FS and add
HSM management to it _before_ restoring the stub files. )
Second - I personally would not use scp to copy the files - I would
use dsmc to restore the (stub) files to the target filesystems.
If you keep all the operations within the tsm client then you reduce
the risk of accidental corruption by utilities 'outside' of TSM / HSM.
Third - Create a test FS with as much data as you can create and then
dry-run with this before messing with your live data.
Your challenge is ultimately to ensure that the migrated data transfers
successfully and uncorrupted. How do you ensure this ? Well, as a first
step _before_ migrating files on the source system, I would take
the md5sum signatures of a number of random files and save this to
a file. Then proceed as per the README_hsm_enu.htm file and at the end,
recall these files and compare their md5sum signatures to those pre-move.
Our md5sums, unfortunately weren't the same ... because we ran into
APAR IC50103 ( to be fixed in TSM 5.3.5 ) - this occurs only when all
of the following occur:
a) a file is a sparse file with a hole (or more than 1023-zero bytes)
at the end of the file
b) the file size is not block-aligned
c) the stub file has been restored via 'dsmc restore' using the options
RESToremigstate Yes" and "MAKesparsefile Yes" (the default).
Can you see why I have the fear now ?
Anyway, the easy way out of this is to add 'MakeSparseFile No' to the
dsm.opt file.
The other gotcha is when you finish. All your files will have a different
inode number. This does not normally occasion a fresh incremental backup of
the file in the standard TSM client. However, it does with the HSM client !
This won't occur until you run dsmreconcile across the Filesystems, but when
you do, you will see that every single file is updated on the server. We are
told that this updates the inode info for the migrated copy but not the
backup copy. So once this has happened, the next backup will perform an
'inline' ( i.e. server-side only ) backup of each file from migrated stgpool
to backup stgpool - all 4TB in yours ( 6TB in ours ) cases.
Apparently this is Working As Designed ......
Apart from that, it's easy - that README_hsm_enu.htm file is your friend.
HTH
Ian Smith
Oxford University Computing Services
England.
On Thursday 08 Feb 2007 9:51 pm, Anker Lerret wrote:
> 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
|
