In our situation, the tapes are being written to a remote SL3000 located in another of our datacenters. They will be read by the same tape units that wrote them because the DR site is an LPAR in that same center. We have tested the process and are well within the limits established for us. The main consideration we have regarding the time is the impact to the users during the backup. We have a global user community and the overnight (for us in the Americas) period is sometimes as busy as is our daytime shift.
Regards, Richard Schuh ________________________________ From: The IBM z/VM Operating System [mailto:[email protected]] On Behalf Of Alain Benveniste Sent: Thursday, April 30, 2009 4:25 AM To: [email protected] Subject: Re: Packing Methods Richard, You have the same questions I had when I started to put in place our DR solution. We also have 3590E drives and I never tried to remove the hard drive default compaction. I don't see a reason for that. Now choosing software compaction is a must if you have enough cpu to do the work for backup and ALSO for restore. For us we can spend more time to use software compaction because we know that we have enough cpu to do the work at restore time offsite. The gain at restore justifies to take more time at backup processing. It's true too that software compaction takes less tapes than with no compaction. If you have many dasds to backup and a time constraint to restore i would suggest you to both use hard and software compactions. Our idea is to say that when we restore in a DR test the cpu is used ONLY for restore. Why not fully using it ! Regards Alain Benveniste Le 29/04/09 20:46, « Schuh, Richard » <[email protected]> a écrit : We are working on a DR process. I notice that the defaults for a Hidro backup include the PACK option which tells Hidro to pack, or condense in some fashion, its output. The output is being written to 3590E drives. It appears that there are three choices we can make for condensing the data: software only, hardware only, or a combination of the two (uncompacted was purposely omitted from the list). Which is likely to give the best results? Does software compaction produce consistently lower output volumes than letting the drive do it? Is there anything to be gained by using both h/w and s/w? Obviously, software compaction costs in terms of cpu time. The question is, is it worth the time spent? Regards, Richard Schuh
