Matt,

- If you want to have the lowest possible number of tapes you should not
do any backups (single copy).
- If you want something quick, cheap and dirty - migration goes to one
primary pool, B/A client backups to another primary. Latter goes offsite
without any copypools (2 copies).
- If you want to do it by the book with higher safety - migration pool,
backup pool and copypool (3 copies).
I cannot (and do not want to) force you, just can make a hint.

Zlatko Krastev
IT Consultant






Matt Simpson <msimpson AT UKY DOT EDU>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
24.02.2003 17:21
Please respond to "ADSM: Dist Stor Manager"


        To:     ADSM-L AT VM.MARIST DOT EDU
        cc:
        Subject:        Re: Need ideas for offsite copy of HSM tapes


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.