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