Pour DR solution is based on a point of synchro¹ means that everthinhgis shutdown. Then we clone our prod DASD with Timefinder (EMC2). It¹s take no time to do the work. Then we backup our clone DASD, sure this way everthing is clean. That¹s how we reduce impact to the users (shutdown + REIPL). This solution costs money as you could think and you are certainly aware of such a solution. To get back to your questions, I had one I never got answer : what software compaction does hardware doesn¹t. Is the algorithm different?
Regards Alain Benveniste Le 30/04/09 18:16, « Schuh, Richard » <[email protected]> a écrit : > 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 >>> >>> >>> >>> >> >
