- 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:[EMAIL PROTECTED]> 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.
