The other data center is ours, just not a twin of the center where VM resides. Contractual first rights are not a consideration.
The idea of two different VM:Backup machines and jobs might not be so far fetched. There is no requirement that the two backups be identical or nearly so. The requirement is that each backup must be a complete logical backup. Twinning tapes does this, but it is not the only solution. Regards, Richard Schuh > -----Original Message----- > From: The IBM z/VM Operating System > [mailto:[EMAIL PROTECTED] On Behalf Of Mike Walter > Sent: Friday, June 06, 2008 5:14 PM > To: [email protected] > Subject: Re: VM:Backup: Twinning Tapes to Remote Tape Unit > > We're doing similarly with a Sun/STK peered VTS for > VM:Archiver. It creates the duplicate virtual volsers in the > other campus without any work by VM:Backup (which does > VM:Archiver tape I/O). Makes tape access for D.R. painlessly > automatic. VM:Backup tapes are still twinned to external > 3590 magStar carts in both data centers because z/OS has > primary "rights" to the dual, peered VTS's. > > BTW, one thing to consider is dual data centers. It *is* > costly to set up, but if you have nearly equal > development/test vs production resource requirements, the > cost justification becomes much simpler given that there is > no D.R. provider cost, and recovery (assuming mirrored DASD) > is very, very quick. Our z/VM system is ready for use about > 15 minutes after we have the LPAR. The myriad z/OS systems > are up in a few hours (DB2 recovery slows that down). > Compare that to restore at a D.R. provider - presuming that > it's just your data center that's lost. If it's a regional > disaster and you're not first to declare the disaster, or the > others have a contractual "first dibbs" - well, it could be > 'a while'. Food for thought. > > Mike Walter > Hewitt Associates > > > ----- Original Message ----- > From: "Marcy Cortes" [EMAIL PROTECTED] > Sent: 06/06/2008 06:44 PM EST > To: [email protected] > Subject: Re: VM:Backup: Twinning Tapes to Remote Tape Unit > > > > Another option would be a peered VTS. > At the moment that's how we're getting all the linux volumes > there (although z/OS is doing the dumping and restoring of > those w/DFDSS and not us using vm utilities). > > Marcy > > "This message may contain confidential and/or privileged > information. If you are not the addressee or authorized to > receive this for the addressee, you must not use, copy, > disclose, or take any action based on this message or any > information herein. If you have received this message in > error, please advise the sender immediately by reply e-mail > and delete this message. Thank you for your cooperation." > > > > ________________________________ > > From: The IBM z/VM Operating System > [mailto:[EMAIL PROTECTED] On Behalf Of Llewellyn, Mark > Sent: Friday, June 06, 2008 4:06 PM > To: [email protected] > Subject: Re: [IBMVM] VM:Backup: Twinning Tapes to Remote Tape Unit > > > This was actually our first option - remote shadow imaging. > The high cost involved and the fundamental requirements of an > actual disaster recovery eliminated the proposal. > > ________________________________ > > From: The IBM z/VM Operating System > [mailto:[EMAIL PROTECTED] On Behalf Of Colin Allinson > Sent: Friday, June 06, 2008 1:09 AM > To: [email protected] > Subject: Re: VM:Backup: Twinning Tapes to Remote Tape Unit > > > > Thinking laterally about this, there is always another solution. > > Have you thought about long-distance remote PPRC for your DASD. > > I am not sure if the official IBM PPRC-XD product can cope > with 3000 miles but there are solutions that can. > > > Colin Allinson > > Amadeus Data Processing GmbH > > > > The information contained in this e-mail and any accompanying > documents may contain information that is confidential or > otherwise protected from disclosure. If you are not the > intended recipient of this message, or if this message has > been addressed to you in error, please immediately alert the > sender by reply e-mail and then delete this message, > including any attachments. Any dissemination, distribution or > other use of the contents of this message by anyone other > than the intended recipient is strictly prohibited. All > messages sent to and from this e-mail address may be > monitored as permitted by applicable law and regulations to > ensure compliance with our internal policies and to protect > our business. E-mails are not secure and cannot be guaranteed > to be error free as they can be intercepted, amended, lost or > destroyed, or contain viruses. You are deemed to have > accepted these risks if you communicate with us by e-mail. >
