At 12:08 PM +0200 2/23/03, Zlatko Krastev/ACIT wrote:

- HSM client sends the data in a storage pool. That storage pool can be
backed up to a copypool. If this is a storage hierarchy within the server
(diskpool migration to tapepool), backup the diskpool first then backup
the tapepool to same copypool. Voila.

OK .. but even if I copy the diskpool and tapepool to a copypool,
isn't there some client data that never gets migrated to the
diskpool? I need a solution that allows me to recover the data if the
client machine gets burned up.  Will the HSM pools contain all the
necessary directory structure information to rebuild the client data?
I need to read the manuals some more, but from what I've been told,
the answer is No.

- management class for HSM client has parameter migrequiresbkup
(defaulting to yes). Thus if MIGDESTination of the class and DESTination
of the backup copygroup point to different pools - you again can have two
copies. Plus the copypool one can be even more.

Yes, I can have to copies; the migration copy and the backup copy.
But they'll both be in a primary storage pool. True, creating the
copy pool gives me "even more".  But the objective is not to see how
MANY copies of the data I can create; it's to see how FEW I can
create and still have the ability to completely restore the client
from the offsite tapes.

- usage of HSM client does not prevent filesystem to be backed up using
B/A client.

True.  But again, we're trying to keep the total number of backups to
a minimum.  We have to pay for tapes.

How afterwards off-site tape management is to be done is just another
story solvable in many ways - through DRM, AutoVault, TSMManager, etc.

Well, maybe it's just another story; but the answer to that story has
a major impact on the first story.  EG  DRM requires the use of
copypools to move tapes offsite.  I've been told AutoVault does not,
so that's something I need to look at. But that opens up some more
questions (aside from the cost, how is reclamation of offsite tapes
done, etc)


At 7:58 AM -0500 2/23/03, Richard Sims wrote:

I would approach it this way:  Via dsmmigfs, defined the stub size to be
512 to eliminate leading file data from the stub, to force all files to
be eligible for migration.

OK, but even if I force all files to migrate, does the migration pool
contain enough info about the client directory structure to allow me
to restore the complete client data directory in the event of a
disaster?
--


Matt Simpson --  OS/390 Support
219 McVey Hall  -- (859) 257-2900 x300
University Of Kentucky, Lexington, KY 40506
<mailto:msimpson AT uky DOT edu>
mainframe --   An obsolete device still used by thousands of obsolete
companies serving billions of obsolete customers and making huge obsolete
profits for their obsolete shareholders.  And this year's run twice as fast
as last year's.