Re: VM:Backup: Twinning Tapes to Remote Tape Unit
Marcy, What is your network configuration like? Do you know what type of network hardware has been in place for the channel extension? -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Marcy Cortes Sent: Thursday, June 05, 2008 2:34 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: VM:Backup: Twinning Tapes to Remote Tape Unit FWIW, backing up about 360G of disk on the smaller system of our 2 traditional VM/CMS systems with HIDRO (uses 4 tapes, 2000 miles) takes a little less that 10 hours. The network is being beefed up. Then we will do full XRC mirroring instead (or too?). The restores are faster with HIDRO as well. Since we do monthly disaster tests, fast is good... (JR and Fran will tell you that too :) I figure too that using both vmbackup and hidro is some protection against sw bugs too that might corrupt both the primary and the secondary at the same time. 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. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Llewellyn, Mark Sent: Thursday, June 05, 2008 2:19 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] VM:Backup: Twinning Tapes to Remote Tape Unit That's another option I'll add to the list. The remote site is disaster-recovery only - it doesn't necessarily have to be pretty right off the bat. I'll have to figure out how it knows which tapes to call for where - it'll be a few months before we start real testing. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Marcy Cortes Sent: Thursday, June 05, 2008 2:06 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: VM:Backup: Twinning Tapes to Remote Tape Unit We run VM:Backup to local tapes and HIDRO to remote tapes. HIDRO is much faster and doesn't chew the CPU the way VM:Backup does. But the users are used to getting their stuff out of the much prettier vmbackup interface. If you twin remotely and locally, how does the restores work? Do you have to code to just use the local drives for that? Marcy Cortes 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. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of O'Brien, Dennis L Sent: Thursday, June 05, 2008 1:53 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] VM:Backup: Twinning Tapes to Remote Tape Unit If you do a tape-to-tape copy, make sure your local and remote tape volsers match. VM:Backup has the tape volsers in its catalog. If you don't have the correct volsers at your remote site, you have a problem. You could probably get away with different volsers if you code VM:Backup's tape mount user exit to translate the local volser to the remote volser. VM:Backup will probably want to check the tape label, so you'll need to make sure that was copied as part of your tape copy. You'll need to mount the tapes with BLP at the remote site if you do this. Note: I haven't tested any of this. We run a separate backup job, from a separate VM:Backup service machine, for our DR backups. Dennis O'Brien Don't worry about biting off more than you can chew. Your mouth is bigger than you think. -- CVW-11 chaplain, Carrier -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Mark Post Sent: Thursday, June 05, 2008 13:38 To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] VM:Backup: Twinning Tapes to Remote Tape Unit On Thu, Jun 5, 2008 at 4:12 PM, in message [EMAIL PROTECTED], Mark Llewellyn [EMAIL PROTECTED] wrote: -snip- Our other option is to simply run two backup jobs, one to the local drive and one to the remote, but that effectively doubles the hit of the backup jobs. Not if you do the backup to local tape drives, and then do a tape-to-tape copy to the remote drives. Mark Post
Re: VM:Backup: Twinning Tapes to Remote Tape Unit
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: IBMVM@LISTSERV.UARK.EDU 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: IBMVM@LISTSERV.UARK.EDU 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: IBMVM@LISTSERV.UARK.EDU 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: IBMVM@LISTSERV.UARK.EDU 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.
Re: VM:Backup: Twinning Tapes to Remote Tape Unit
Or make local twins, then copy one tape-to-remote tape.. problem solved, always at least two backups. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] Behalf Of Mark Post Sent: Thursday, June 05, 2008 5:02 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: VM:Backup: Twinning Tapes to Remote Tape Unit On Thu, Jun 5, 2008 at 4:44 PM, in message [EMAIL PROTECTED], Hughes, Jim [EMAIL PROTECTED] wrote: The auditors may have a stroke when they realize there is a larger window where no copies exist. Auditors can have all the strokes they want, if management is willing to sign off on the exposure. The technical deficiencies of catalogs not matching is far more of a problem. Mark Post
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
Re: VM:Backup: Twinning Tapes to Remote Tape Unit
We do it and have been doing it for years. Works well. This message w/attachments (message) may be privileged, confidential or proprietary, and if you are not an intended recipient, please notify the sender, do not use or share it and delete it. Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Merrill Lynch. Subject to applicable law, Merrill Lynch may monitor, review and retain e-communications (EC) traveling through its networks/systems. The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or error-free. This message is subject to terms available at the following link: http://www.ml.com/e-communications_terms/. By messaging with Merrill Lynch you consent to the foregoing.
Re: VM:Backup: Twinning Tapes to Remote Tape Unit
Put a VTS in your DR site connected to you as the site for the twin tapes. No movement of tapes now. Physical tape shipment is scrutinized here. Tapes must either be encrypted or hand-carried by a Bank employee to their destination. We'll probably be moving to an all-VTS environment in a year or two, which makes shipment even more of a problem. When I implemented the remote DR process, I added the capability to fall back to local tapes. After a few years of never using it, I took the code out and we freed up the tape range for something else. If the channel extension is down, the offsite backups just wait for it to come back up. Dennis O'Brien Don't worry about biting off more than you can chew. Your mouth is bigger than you think. -- CVW-11 chaplain, Carrier This message w/attachments (message) may be privileged, confidential or proprietary, and if you are not an intended recipient, please notify the sender, do not use or share it and delete it. Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Merrill Lynch. Subject to applicable law, Merrill Lynch may monitor, review and retain e-communications (EC) traveling through its networks/systems. The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or error-free. This message is subject to terms available at the following link: http://www.ml.com/e-communications_terms/. By messaging with Merrill Lynch you consent to the foregoing.
Re: VM:Backup: Twinning Tapes to Remote Tape Unit
Put a VTS in your DR site connected to you as the site for the twin tapes. No movement of tapes now. In fact, our remote site has a VTS for DR backups. Our local backups are still in an STK silo. My comment about tape movement was in context with David's suggestion of a fallback when the channel extension link is down: make a second local backup and send the tapes offsite. A VTS at the DR site doesn't help there. Dennis O'Brien Don't worry about biting off more than you can chew. Your mouth is bigger than you think. -- CVW-11 chaplain, Carrier -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Stracka, James (GTS) Sent: Friday, June 06, 2008 08:25 To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] VM:Backup: Twinning Tapes to Remote Tape Unit Put a VTS in your DR site connected to you as the site for the twin tapes. No movement of tapes now. Physical tape shipment is scrutinized here. Tapes must either be encrypted or hand-carried by a Bank employee to their destination. We'll probably be moving to an all-VTS environment in a year or two, which makes shipment even more of a problem. When I implemented the remote DR process, I added the capability to fall back to local tapes. After a few years of never using it, I took the code out and we freed up the tape range for something else. If the channel extension is down, the offsite backups just wait for it to come back up. Dennis O'Brien Don't worry about biting off more than you can chew. Your mouth is bigger than you think. -- CVW-11 chaplain, Carrier This message w/attachments (message) may be privileged, confidential or proprietary, and if you are not an intended recipient, please notify the sender, do not use or share it and delete it. Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Merrill Lynch. Subject to applicable law, Merrill Lynch may monitor, review and retain e-communications (EC) traveling through its networks/systems. The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or error-free. This message is subject to terms available at the following link: http://www.ml.com/e-communications_terms/. By messaging with Merrill Lynch you consent to the foregoing.
Re: VM:Backup: Twinning Tapes to Remote Tape Unit
Same here - we are operating on the scenario of our primary data center being destroyed and not coming back. If the offsite copy is a few hours older than the onsite, it's not a show-stopper. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of O'Brien, Dennis L Sent: Thursday, June 05, 2008 7:12 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: VM:Backup: Twinning Tapes to Remote Tape Unit No one has told us that the two backup runs have to be the same. The DR backups are only used if the primary data center is a pile of rubble. Who cares if they're a few hours older or newer than a set of tapes that is now unusable, and may be irrecoverable? The disaster time is unpredictable. The backup tapes may be 2 hours old or 22 hours old. In either case, the users get what they get. We don't make backups when most of the users are doing their work, but beyond that, it really doesn't matter when they're made. The other advantage of separate onsite and offsite backup jobs is that your onsite backups aren't held up when your channel extension equipment is down. I'm certainly not advocating BLP. I was just pointing out one of the issues with a tape copy solution. Dennis O'Brien Don't worry about biting off more than you can chew. Your mouth is bigger than you think. -- CVW-11 chaplain, Carrier -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of David Boyes Sent: Thursday, June 05, 2008 18:24 To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] VM:Backup: Twinning Tapes to Remote Tape Unit This concept was considered, but is really last on the list - it's a bit of a mine field. Running two VM:Backup service machines has potential, though, instead of running two backups serially on the same machine. And how...there be dragons, big time. Two VM:Backup runs (even simultaneous runs) have a high probability of being different enough to drive auditors berserk. The system isn't the same as it was with the first set, and you can't stand up and give evidence that the two backups contain the same data, particularly if the system is live during the backup runs. Also, anything that uses BLP tape options is pretty much automatically suspect (and your tape librarians are probably going to get hostile as well -- things like that tend to mess with their worldview of having One True Identifier That Is Immutable In the Whole Enterprise).
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: IBMVM@LISTSERV.UARK.EDU 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: IBMVM@LISTSERV.UARK.EDU 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
Re: VM:Backup: Twinning Tapes to Remote Tape Unit
Mark Llewellyn wrote on 06/05/2008 03:12:50 PM: Our other option is to simply run two backup jobs, one to the local drive and one to the remote, but that effectively doubles the hit of the backup jobs. The (I/O) performance hit on this might not be as high as you think. If you ran the two backup jobs concurrently (allowed by VM:Backup), the second job (they won't be exactly in sync) can benefit by drafting (for all you NASCAR fans) behind the other through the magic of minidisk caching. In such a scenario, VMBACKUP should probably have OPTION NOMDCFS in its directory definition. This is also assuming that: 1) one job doesn't get too far out of sync with the other (ex remote tape drives much slower than local) 2) you have sufficient storage for MDC, to make it worthwhile as a tradeoff for I/O. That said, I would still avoid this option. Restores will be based (generally) on the last backup in the catalog, which will likely be associated with the slowest-running backup job. Meaning tapes at the remote (aka slowest) location will be used. You could adjust for this (could casual users?), but it would be a PITA. Alternatively, you could configure two VMBACKUP machines (ex VMBACKUP and VMBREMOT), but that wouldn't be pretty either. Best regards, Mark Wheeler, 3M Company
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: IBMVM@LISTSERV.UARK.EDU 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: IBMVM@LISTSERV.UARK.EDU 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: IBMVM@LISTSERV.UARK.EDU 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.
Re: VM:Backup: Twinning Tapes to Remote Tape Unit
Use of the VM:Tape command exit provides a means to automagically swap the mount command volsers in any order you desire. Works great for us after most operators moved to the remote campus. Now, without swapping onsite and offsite tape vaults, read mounts are swapped to the remote site where tape operators have moved. For D.R. the command exit automatically detects which campus we're running in, and mount the tape at that campus. Cool! Mike Walter Hewitt Associates - Original Message - From: Mark Wheeler [EMAIL PROTECTED] Sent: 06/06/2008 06:48 PM EST To: IBMVM@LISTSERV.UARK.EDU Subject: Re: VM:Backup: Twinning Tapes to Remote Tape Unit Mark Llewellyn wrote on 06/05/2008 03:12:50 PM: Our other option is to simply run two backup jobs, one to the local drive and one to the remote, but that effectively doubles the hit of the backup jobs. The (I/O) performance hit on this might not be as high as you think. If you ran the two backup jobs concurrently (allowed by VM:Backup), the second job (they won't be exactly in sync) can benefit by drafting (for all you NASCAR fans) behind the other through the magic of minidisk caching. In such a scenario, VMBACKUP should probably have OPTION NOMDCFS in its directory definition. This is also assuming that: 1) one job doesn't get too far out of sync with the other (ex remote tape drives much slower than local) 2) you have sufficient storage for MDC, to make it worthwhile as a tradeoff for I/O. That said, I would still avoid this option. Restores will be based (generally) on the last backup in the catalog, which will likely be associated with the slowest-running backup job. Meaning tapes at the remote (aka slowest) location will be used. You could adjust for this (could casual users?), but it would be a PITA. Alternatively, you could configure two VMBACKUP machines (ex VMBACKUP and VMBREMOT), but that wouldn't be pretty either. Best regards, Mark Wheeler, 3M Company 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.
VM:Backup: Twinning Tapes to Remote Tape Unit
Greetings, We are ramping up our Technical Recovery Plan, and intend to use channel- extended tape units at a remote location when performing our regular full and incremental backups. We use CA's VM:BACKUP for file-level backups, and will be using VM:HiDRO to capture the system image. We're curious as to whether any other CA customers are using the synchronous tape twinning feature with one loca l tape unit and one remote. We've been cautioned by our network folks that the response time from the remote tape unit would be quite a limiting factor affecting the speed of a synchronous, twinned backup. Our other option is to simply run two backup jobs, one to the local drive and one to the remote, but that effectively doubles the hit of the backup jobs. Any anecdotes or insight would be most welcome! Mark Llewellyn VM Systems Support Visa, Inc.
Re: VM:Backup: Twinning Tapes to Remote Tape Unit
We don't anymore, but we did for a very long time and it worked beautifully. Christine Brogan - TPF/VM Systems Support Information Technology Services Americas Phone: 623-505-5366, Cell: 623-512-5883, IBM tieline 273-4647 Email: [EMAIL PROTECTED] The end of fear is where we begin - the moment we decided to let Love in... Goo Goo Dolls Mark Llewellyn [EMAIL PROTECTED] M To Sent by: The IBM IBMVM@LISTSERV.UARK.EDU z/VM Operating cc System [EMAIL PROTECTED] Subject ARK.EDU VM:Backup: Twinning Tapes to Remote Tape Unit 06/05/2008 01:12 PM Please respond to The IBM z/VM Operating System [EMAIL PROTECTED] ARK.EDU Greetings, We are ramping up our Technical Recovery Plan, and intend to use channel- extended tape units at a remote location when performing our regular full and incremental backups. We use CA's VM:BACKUP for file-level backups, and will be using VM:HiDRO to capture the system image. We're curious as to whether any other CA customers are using the synchronous tape twinning feature with one loca l tape unit and one remote. We've been cautioned by our network folks that the response time from the remote tape unit would be quite a limiting factor affecting the speed of a synchronous, twinned backup. Our other option is to simply run two backup jobs, one to the local drive and one to the remote, but that effectively doubles the hit of the backup jobs. Any anecdotes or insight would be most welcome! Mark Llewellyn VM Systems Support Visa, Inc.
Re: VM:Backup: Twinning Tapes to Remote Tape Unit
On Thu, Jun 5, 2008 at 4:12 PM, in message [EMAIL PROTECTED], Mark Llewellyn [EMAIL PROTECTED] wrote: -snip- Our other option is to simply run two backup jobs, one to the local drive and one to the remote, but that effectively doubles the hit of the backup jobs. Not if you do the backup to local tape drives, and then do a tape-to-tape copy to the remote drives. Mark Post
Re: VM:Backup: Twinning Tapes to Remote Tape Unit
We are ramping up our Technical Recovery Plan, and intend to use channel- extended tape units at a remote location when performing our regular full and incremental backups. This approach lives and dies on the speed of the link to the remote drives. I ran this configuration a long time ago with parallel channel extenders to an offsite 3490 and it worked OK with a dedicated DS3 between the channel extenders. With modern drives, the bandwidth requirements will probably be higher. The time to get the write completed to the remote drive was measurable, however, and the backup time did increase by about 15-20%. Didn't matter much for that site (it was less than 100 3370s), but that might screw you for modern large disk.
Re: VM:Backup: Twinning Tapes to Remote Tape Unit
Not if you do the backup to local tape drives, and then do a tape-to-tape copy to the remote drives. Mark Post Some auditors won't let you do it that way because there is a window (however short) where only 1 copy exists.
Re: VM:Backup: Twinning Tapes to Remote Tape Unit
That would be by far the easiest way, but VM:Backup is not able to handle copied tapes at a BRP site - it's catalog wouldn't match. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Mark Post Sent: Thursday, June 05, 2008 1:38 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: VM:Backup: Twinning Tapes to Remote Tape Unit On Thu, Jun 5, 2008 at 4:12 PM, in message [EMAIL PROTECTED], Mark Llewellyn [EMAIL PROTECTED] wrote: -snip- Our other option is to simply run two backup jobs, one to the local drive and one to the remote, but that effectively doubles the hit of the backup jobs. Not if you do the backup to local tape drives, and then do a tape-to-tape copy to the remote drives. Mark Post
Re: VM:Backup: Twinning Tapes to Remote Tape Unit
The auditors may have a stroke when they realize there is a larger window where no copies exist. Jim Hughes 603-271-5586 Any fool can criticize when a man makes a mistake - and most of them do. =-Original Message- =From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On =Behalf Of David Boyes =Sent: Thursday, June 05, 2008 4:42 PM =To: IBMVM@LISTSERV.UARK.EDU =Subject: Re: VM:Backup: Twinning Tapes to Remote Tape Unit = = Not if you do the backup to local tape drives, and then do a =tape-to-tape = copy to the remote drives. = Mark Post = =Some auditors won't let you do it that way because there is a window =(however short) where only 1 copy exists.
Re: VM:Backup: Twinning Tapes to Remote Tape Unit
What you say is so true. However, even a 50% increase in time may not be a show-stopper for our shop, as opposed to running two complete backup jobs. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of David Boyes Sent: Thursday, June 05, 2008 1:41 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: VM:Backup: Twinning Tapes to Remote Tape Unit We are ramping up our Technical Recovery Plan, and intend to use channel- extended tape units at a remote location when performing our regular full and incremental backups. This approach lives and dies on the speed of the link to the remote drives. I ran this configuration a long time ago with parallel channel extenders to an offsite 3490 and it worked OK with a dedicated DS3 between the channel extenders. With modern drives, the bandwidth requirements will probably be higher. The time to get the write completed to the remote drive was measurable, however, and the backup time did increase by about 15-20%. Didn't matter much for that site (it was less than 100 3370s), but that might screw you for modern large disk.
Re: VM:Backup: Twinning Tapes to Remote Tape Unit
Caveat: We have not used HiDRO yet, other than figuring out a way for it to actually write two tapes with different volsers at the same time. What about completing the local HiDRO backup job, and then running its process to read in the local copy and write it to volume with the same volser at the remote site. Or, is that the same as the synchronous twinning you refer to? That means that the disk access is only performed once (as opposed to possible repeat backups for separate tapes), speeding real backups. It's just the tape that's used twice (once write, followed by job(s) to read it and write its identical-volser twin far offsite). Given that our data centers are only about 3 miles apart, we did not want to use the same volsers in both campuses for fear that one or more tapes might somehow travel between campuses just before a real disaster, leaving us with no copies of those backup tapes at the surviving data center. Tapes that are really, truly many miles apart are less likely to become illegal immigrants. Mark Llewellyn [EMAIL PROTECTED] Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 06/05/2008 03:12 PM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject VM:Backup: Twinning Tapes to Remote Tape Unit Greetings, We are ramping up our Technical Recovery Plan, and intend to use channel- extended tape units at a remote location when performing our regular full and incremental backups. We use CA's VM:BACKUP for file-level backups, and will be using VM:HiDRO to capture the system image. We're curious as to whether any other CA customers are using the synchronous tape twinning feature with one loca l tape unit and one remote. We've been cautioned by our network folks that the response time from the remote tape unit would be quite a limiting factor affecting the speed of a synchronous, twinned backup. Our other option is to simply run two backup jobs, one to the local drive and one to the remote, but that effectively doubles the hit of the backup jobs. Any anecdotes or insight would be most welcome! Mark Llewellyn VM Systems Support Visa, Inc. 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.
Re: VM:Backup: Twinning Tapes to Remote Tape Unit
If you do a tape-to-tape copy, make sure your local and remote tape volsers match. VM:Backup has the tape volsers in its catalog. If you don't have the correct volsers at your remote site, you have a problem. You could probably get away with different volsers if you code VM:Backup's tape mount user exit to translate the local volser to the remote volser. VM:Backup will probably want to check the tape label, so you'll need to make sure that was copied as part of your tape copy. You'll need to mount the tapes with BLP at the remote site if you do this. Note: I haven't tested any of this. We run a separate backup job, from a separate VM:Backup service machine, for our DR backups. Dennis O'Brien Don't worry about biting off more than you can chew. Your mouth is bigger than you think. -- CVW-11 chaplain, Carrier -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Mark Post Sent: Thursday, June 05, 2008 13:38 To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] VM:Backup: Twinning Tapes to Remote Tape Unit On Thu, Jun 5, 2008 at 4:12 PM, in message [EMAIL PROTECTED], Mark Llewellyn [EMAIL PROTECTED] wrote: -snip- Our other option is to simply run two backup jobs, one to the local drive and one to the remote, but that effectively doubles the hit of the backup jobs. Not if you do the backup to local tape drives, and then do a tape-to-tape copy to the remote drives. Mark Post
Re: VM:Backup: Twinning Tapes to Remote Tape Unit
What you say is so true. However, even a 50% increase in time may not be a show-stopper for our shop, as opposed to running two complete backup jobs. YMMV. Also, keep in mind that you'll probably need to mess with the MIH time values for class TAPE devices to compensate for the additional delay. You really, really want dedicated bandwidth for this if its in any way possible. Variable delays tend to make channel extenders cranky. Once we got that worked out and the proper expectations set and managed, it's a pretty slick setup.
Re: VM:Backup: Twinning Tapes to Remote Tape Unit
This concept was considered, but is really last on the list - it's a bit of a mine field. Running two VM:Backup service machines has potential, though, instead of running two backups serially on the same machine. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of O'Brien, Dennis L Sent: Thursday, June 05, 2008 1:53 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: VM:Backup: Twinning Tapes to Remote Tape Unit If you do a tape-to-tape copy, make sure your local and remote tape volsers match. VM:Backup has the tape volsers in its catalog. If you don't have the correct volsers at your remote site, you have a problem. You could probably get away with different volsers if you code VM:Backup's tape mount user exit to translate the local volser to the remote volser. VM:Backup will probably want to check the tape label, so you'll need to make sure that was copied as part of your tape copy. You'll need to mount the tapes with BLP at the remote site if you do this. Note: I haven't tested any of this. We run a separate backup job, from a separate VM:Backup service machine, for our DR backups. Dennis O'Brien Don't worry about biting off more than you can chew. Your mouth is bigger than you think. -- CVW-11 chaplain, Carrier -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Mark Post Sent: Thursday, June 05, 2008 13:38 To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] VM:Backup: Twinning Tapes to Remote Tape Unit On Thu, Jun 5, 2008 at 4:12 PM, in message [EMAIL PROTECTED], Mark Llewellyn [EMAIL PROTECTED] wrote: -snip- Our other option is to simply run two backup jobs, one to the local drive and one to the remote, but that effectively doubles the hit of the backup jobs. Not if you do the backup to local tape drives, and then do a tape-to-tape copy to the remote drives. Mark Post
Re: VM:Backup: Twinning Tapes to Remote Tape Unit
This solution is our real hope. I believe we'll have dedicated bandwidth - our network guys are working on that one. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of David Boyes Sent: Thursday, June 05, 2008 1:58 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: VM:Backup: Twinning Tapes to Remote Tape Unit What you say is so true. However, even a 50% increase in time may not be a show-stopper for our shop, as opposed to running two complete backup jobs. YMMV. Also, keep in mind that you'll probably need to mess with the MIH time values for class TAPE devices to compensate for the additional delay. You really, really want dedicated bandwidth for this if its in any way possible. Variable delays tend to make channel extenders cranky. Once we got that worked out and the proper expectations set and managed, it's a pretty slick setup.
Re: VM:Backup: Twinning Tapes to Remote Tape Unit
You have a pretty slick setup. We back up about 200G or less for a full backup, and 2 to 10G for our daily incremental. The kicker is the 3000 mile channel extension...coast-to-coast. From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Mike Walter Sent: Thursday, June 05, 2008 1:58 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: VM:Backup: Twinning Tapes to Remote Tape Unit We have (forever) backed up using VM:Backup twins - reading disk once, writing concurrently to separate backup tapes about 3 miles apart (each with it's own volser). We do full file-level backups and critical system DASD physical-backups each Saturday to three 3590 drives in each data center (six spinning MagStar tapes). Over the past few weeks, each Saturday we've backed up about 350G-500G in 5.5-6.25 hours from an VM:Backup running on an olde z800. Mike Walter Hewitt Associates Any opinions expressed herein are mine alone and do not necessarily represent the opinions or policies of Hewitt Associates. Llewellyn, Mark [EMAIL PROTECTED] Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 06/05/2008 03:44 PM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject Re: VM:Backup: Twinning Tapes to Remote Tape Unit That would be by far the easiest way, but VM:Backup is not able to handle copied tapes at a BRP site - it's catalog wouldn't match. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Mark Post Sent: Thursday, June 05, 2008 1:38 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: VM:Backup: Twinning Tapes to Remote Tape Unit On Thu, Jun 5, 2008 at 4:12 PM, in message [EMAIL PROTECTED], Mark Llewellyn [EMAIL PROTECTED] wrote: -snip- Our other option is to simply run two backup jobs, one to the local drive and one to the remote, but that effectively doubles the hit of the backup jobs. Not if you do the backup to local tape drives, and then do a tape-to-tape copy to the remote drives. Mark Post 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.
Re: VM:Backup: Twinning Tapes to Remote Tape Unit
We run VM:Backup to local tapes and HIDRO to remote tapes. HIDRO is much faster and doesn't chew the CPU the way VM:Backup does. But the users are used to getting their stuff out of the much prettier vmbackup interface. If you twin remotely and locally, how does the restores work? Do you have to code to just use the local drives for that? Marcy Cortes 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. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of O'Brien, Dennis L Sent: Thursday, June 05, 2008 1:53 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] VM:Backup: Twinning Tapes to Remote Tape Unit If you do a tape-to-tape copy, make sure your local and remote tape volsers match. VM:Backup has the tape volsers in its catalog. If you don't have the correct volsers at your remote site, you have a problem. You could probably get away with different volsers if you code VM:Backup's tape mount user exit to translate the local volser to the remote volser. VM:Backup will probably want to check the tape label, so you'll need to make sure that was copied as part of your tape copy. You'll need to mount the tapes with BLP at the remote site if you do this. Note: I haven't tested any of this. We run a separate backup job, from a separate VM:Backup service machine, for our DR backups. Dennis O'Brien Don't worry about biting off more than you can chew. Your mouth is bigger than you think. -- CVW-11 chaplain, Carrier -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Mark Post Sent: Thursday, June 05, 2008 13:38 To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] VM:Backup: Twinning Tapes to Remote Tape Unit On Thu, Jun 5, 2008 at 4:12 PM, in message [EMAIL PROTECTED], Mark Llewellyn [EMAIL PROTECTED] wrote: -snip- Our other option is to simply run two backup jobs, one to the local drive and one to the remote, but that effectively doubles the hit of the backup jobs. Not if you do the backup to local tape drives, and then do a tape-to-tape copy to the remote drives. Mark Post
Re: VM:Backup: Twinning Tapes to Remote Tape Unit
That's another option I'll add to the list. The remote site is disaster-recovery only - it doesn't necessarily have to be pretty right off the bat. I'll have to figure out how it knows which tapes to call for where - it'll be a few months before we start real testing. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Marcy Cortes Sent: Thursday, June 05, 2008 2:06 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: VM:Backup: Twinning Tapes to Remote Tape Unit We run VM:Backup to local tapes and HIDRO to remote tapes. HIDRO is much faster and doesn't chew the CPU the way VM:Backup does. But the users are used to getting their stuff out of the much prettier vmbackup interface. If you twin remotely and locally, how does the restores work? Do you have to code to just use the local drives for that? Marcy Cortes 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. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of O'Brien, Dennis L Sent: Thursday, June 05, 2008 1:53 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] VM:Backup: Twinning Tapes to Remote Tape Unit If you do a tape-to-tape copy, make sure your local and remote tape volsers match. VM:Backup has the tape volsers in its catalog. If you don't have the correct volsers at your remote site, you have a problem. You could probably get away with different volsers if you code VM:Backup's tape mount user exit to translate the local volser to the remote volser. VM:Backup will probably want to check the tape label, so you'll need to make sure that was copied as part of your tape copy. You'll need to mount the tapes with BLP at the remote site if you do this. Note: I haven't tested any of this. We run a separate backup job, from a separate VM:Backup service machine, for our DR backups. Dennis O'Brien Don't worry about biting off more than you can chew. Your mouth is bigger than you think. -- CVW-11 chaplain, Carrier -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Mark Post Sent: Thursday, June 05, 2008 13:38 To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] VM:Backup: Twinning Tapes to Remote Tape Unit On Thu, Jun 5, 2008 at 4:12 PM, in message [EMAIL PROTECTED], Mark Llewellyn [EMAIL PROTECTED] wrote: -snip- Our other option is to simply run two backup jobs, one to the local drive and one to the remote, but that effectively doubles the hit of the backup jobs. Not if you do the backup to local tape drives, and then do a tape-to-tape copy to the remote drives. Mark Post
Re: VM:Backup: Twinning Tapes to Remote Tape Unit
This sounds like the optimal approach, really. Thanks! -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Marcy Cortes Sent: Thursday, June 05, 2008 2:34 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: VM:Backup: Twinning Tapes to Remote Tape Unit FWIW, backing up about 360G of disk on the smaller system of our 2 traditional VM/CMS systems with HIDRO (uses 4 tapes, 2000 miles) takes a little less that 10 hours. The network is being beefed up. Then we will do full XRC mirroring instead (or too?). The restores are faster with HIDRO as well. Since we do monthly disaster tests, fast is good... (JR and Fran will tell you that too :) I figure too that using both vmbackup and hidro is some protection against sw bugs too that might corrupt both the primary and the secondary at the same time. 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. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Llewellyn, Mark Sent: Thursday, June 05, 2008 2:19 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] VM:Backup: Twinning Tapes to Remote Tape Unit That's another option I'll add to the list. The remote site is disaster-recovery only - it doesn't necessarily have to be pretty right off the bat. I'll have to figure out how it knows which tapes to call for where - it'll be a few months before we start real testing. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Marcy Cortes Sent: Thursday, June 05, 2008 2:06 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: VM:Backup: Twinning Tapes to Remote Tape Unit We run VM:Backup to local tapes and HIDRO to remote tapes. HIDRO is much faster and doesn't chew the CPU the way VM:Backup does. But the users are used to getting their stuff out of the much prettier vmbackup interface. If you twin remotely and locally, how does the restores work? Do you have to code to just use the local drives for that? Marcy Cortes 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. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of O'Brien, Dennis L Sent: Thursday, June 05, 2008 1:53 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] VM:Backup: Twinning Tapes to Remote Tape Unit If you do a tape-to-tape copy, make sure your local and remote tape volsers match. VM:Backup has the tape volsers in its catalog. If you don't have the correct volsers at your remote site, you have a problem. You could probably get away with different volsers if you code VM:Backup's tape mount user exit to translate the local volser to the remote volser. VM:Backup will probably want to check the tape label, so you'll need to make sure that was copied as part of your tape copy. You'll need to mount the tapes with BLP at the remote site if you do this. Note: I haven't tested any of this. We run a separate backup job, from a separate VM:Backup service machine, for our DR backups. Dennis O'Brien Don't worry about biting off more than you can chew. Your mouth is bigger than you think. -- CVW-11 chaplain, Carrier -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Mark Post Sent: Thursday, June 05, 2008 13:38 To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] VM:Backup: Twinning Tapes to Remote Tape Unit On Thu, Jun 5, 2008 at 4:12 PM, in message [EMAIL PROTECTED], Mark Llewellyn [EMAIL PROTECTED] wrote: -snip- Our other option is to simply run two backup jobs, one to the local drive and one to the remote, but that effectively doubles the hit of the backup jobs. Not if you do the backup to local tape drives, and then do a tape-to-tape copy to the remote drives. Mark Post
Re: VM:Backup: Twinning Tapes to Remote Tape Unit
We wrote a VM:Tape command exit which swaps the volsers for any VMBACKUP read mount when running on any processor other than the production system. That way when we come up on a D.R. box, we use the production VM:Tape and VM:Backup catalogs, but it asks the operator (or robot) to mount the tape in the surviving data center. The direction I took for D.R. is to automate as much as humanly and legally possible so that operators just IPL the regular (the mirror copy) sysres, and reply to a prompt asking is this is REALLY (What? The cpuid doesn't match production you say!!?) a disaster recovery. If they agree, magic happens. Our typical z/VM D.R. system (the production system running on a different system z CEC) is usually up less than 10 minutes after we are handed the LPAR. Of course, sysprogs have to change a couple product CPUID passwords, but that takes only minutes after the IPL. Testing end users usually can logon with about 30 minutes of our having been given the LPAR. And we don't have to hurry. It sort of makes me misty-eyed for the old days of 38-hours straight-through heads-down systems programming with no sleep and few meals. But not too much. :-) It's a nice confluence of early career years loving the exhaustion, and later career years having the technology to prevent it. Mike Walter Hewitt Associates Any opinions expressed herein are mine alone and do not necessarily represent the opinions or policies of Hewitt Associates. Llewellyn, Mark [EMAIL PROTECTED] Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 06/05/2008 04:19 PM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject Re: VM:Backup: Twinning Tapes to Remote Tape Unit That's another option I'll add to the list. The remote site is disaster-recovery only - it doesn't necessarily have to be pretty right off the bat. I'll have to figure out how it knows which tapes to call for where - it'll be a few months before we start real testing. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Marcy Cortes Sent: Thursday, June 05, 2008 2:06 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: VM:Backup: Twinning Tapes to Remote Tape Unit We run VM:Backup to local tapes and HIDRO to remote tapes. HIDRO is much faster and doesn't chew the CPU the way VM:Backup does. But the users are used to getting their stuff out of the much prettier vmbackup interface. If you twin remotely and locally, how does the restores work? Do you have to code to just use the local drives for that? Marcy Cortes 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. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of O'Brien, Dennis L Sent: Thursday, June 05, 2008 1:53 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] VM:Backup: Twinning Tapes to Remote Tape Unit If you do a tape-to-tape copy, make sure your local and remote tape volsers match. VM:Backup has the tape volsers in its catalog. If you don't have the correct volsers at your remote site, you have a problem. You could probably get away with different volsers if you code VM:Backup's tape mount user exit to translate the local volser to the remote volser. VM:Backup will probably want to check the tape label, so you'll need to make sure that was copied as part of your tape copy. You'll need to mount the tapes with BLP at the remote site if you do this. Note: I haven't tested any of this. We run a separate backup job, from a separate VM:Backup service machine, for our DR backups. Dennis O'Brien Don't worry about biting off more than you can chew. Your mouth is bigger than you think. -- CVW-11 chaplain, Carrier -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Mark Post Sent: Thursday, June 05, 2008 13:38 To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] VM:Backup: Twinning Tapes to Remote Tape Unit On Thu, Jun 5, 2008 at 4:12 PM, in message [EMAIL PROTECTED], Mark Llewellyn [EMAIL PROTECTED] wrote: -snip- Our other option is to simply run two backup jobs, one to the local drive and one to the remote, but that effectively doubles the hit of the backup jobs. Not if you do the backup to local tape drives, and then do a tape-to-tape copy to the remote drives. Mark Post The information contained in this e-mail and any accompanying documents may contain information that is confidential or otherwise protected from disclosure
Re: VM:Backup: Twinning Tapes to Remote Tape Unit
This concept was considered, but is really last on the list - it's a bit of a mine field. Running two VM:Backup service machines has potential, though, instead of running two backups serially on the same machine. And how...there be dragons, big time. Two VM:Backup runs (even simultaneous runs) have a high probability of being different enough to drive auditors berserk. The system isn't the same as it was with the first set, and you can't stand up and give evidence that the two backups contain the same data, particularly if the system is live during the backup runs. Also, anything that uses BLP tape options is pretty much automatically suspect (and your tape librarians are probably going to get hostile as well -- things like that tend to mess with their worldview of having One True Identifier That Is Immutable In the Whole Enterprise).
Re: VM:Backup: Twinning Tapes to Remote Tape Unit
If you twin remotely and locally, how does the restores work? Do you have to code to just use the local drives for that? If you do it the official way (channel extension to remote drives and simultaneous twinning), VM:Backup records the data on two (or more) unique volsers in parallel, and records all the volsers in the backup catalog and associates the volumes with VM:Backup in VM:Tape. Any of the volumes is acceptable, so it will try them all sequentially (if vol A is not available, tape operator responds to VMTAPE that the tape is destroyed, and it automagically switches to the next one. Seamless to the end user.) This saved my proverbial posterior several times when a careless operator (the cause of the legendary RICSTP666E error message for some of the old Rice utilities) dropped one of the volumes. If you've bit-copied the tapes (including labels), then you just substitute the copy for the real thing, and again, no user-visible impact (but you better be *dead* sure that copy job runs reliably). VM:Tape and VM:Backup can't really tell as long as the block counts are right and the data is in the right place on the volume. More risk than I'm really comfortable with, since I don't have VM:Backup source. -- db
Re: VM:Backup: Twinning Tapes to Remote Tape Unit
No one has told us that the two backup runs have to be the same. The DR backups are only used if the primary data center is a pile of rubble. Who cares if they're a few hours older or newer than a set of tapes that is now unusable, and may be irrecoverable? The disaster time is unpredictable. The backup tapes may be 2 hours old or 22 hours old. In either case, the users get what they get. We don't make backups when most of the users are doing their work, but beyond that, it really doesn't matter when they're made. The other advantage of separate onsite and offsite backup jobs is that your onsite backups aren't held up when your channel extension equipment is down. I'm certainly not advocating BLP. I was just pointing out one of the issues with a tape copy solution. Dennis O'Brien Don't worry about biting off more than you can chew. Your mouth is bigger than you think. -- CVW-11 chaplain, Carrier -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of David Boyes Sent: Thursday, June 05, 2008 18:24 To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] VM:Backup: Twinning Tapes to Remote Tape Unit This concept was considered, but is really last on the list - it's a bit of a mine field. Running two VM:Backup service machines has potential, though, instead of running two backups serially on the same machine. And how...there be dragons, big time. Two VM:Backup runs (even simultaneous runs) have a high probability of being different enough to drive auditors berserk. The system isn't the same as it was with the first set, and you can't stand up and give evidence that the two backups contain the same data, particularly if the system is live during the backup runs. Also, anything that uses BLP tape options is pretty much automatically suspect (and your tape librarians are probably going to get hostile as well -- things like that tend to mess with their worldview of having One True Identifier That Is Immutable In the Whole Enterprise).
Re: VM:Backup: Twinning Tapes to Remote Tape Unit
No one has told us that the two backup runs have to be the same. Consider yourself fortunate. At least one of our clients has to be able to swear in (possibly international) courts that the two are written simultaneously and are identical to the extent of technical feasibility. It's a huge PITA. (On the other hand, given what they do, I can't say I object much at all that they have to be *really* careful. 'nuff said. ) The other advantage of separate onsite and offsite backup jobs is that your onsite backups aren't held up when your channel extension equipment is down. Very true. Depending on how smart your scratch exits are, you can fall back on generating local volumes and adding them to the remote series, then shipping the physical tapes ASAP. VMTAPE is really good at coping with that. I'm certainly not advocating BLP. Me either. It's on one set of auditors immediate fail checklist. 8-)
Re: VM:Backup: Twinning Tapes to Remote Tape Unit
The other advantage of separate onsite and offsite backup jobs is that your onsite backups aren't held up when your channel extension equipment is down. Very true. Depending on how smart your scratch exits are, you can fall back on generating local volumes and adding them to the remote series, then shipping the physical tapes ASAP. VMTAPE is really good at coping with that. Physical tape shipment is scrutinized here. Tapes must either be encrypted or hand-carried by a Bank employee to their destination. We'll probably be moving to an all-VTS environment in a year or two, which makes shipment even more of a problem. When I implemented the remote DR process, I added the capability to fall back to local tapes. After a few years of never using it, I took the code out and we freed up the tape range for something else. If the channel extension is down, the offsite backups just wait for it to come back up. Dennis O'Brien Don't worry about biting off more than you can chew. Your mouth is bigger than you think. -- CVW-11 chaplain, Carrier
