: 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
une 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:Bac
M 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 b
ght.
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
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 tw
n
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
lf 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.
Wh
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
>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 chan
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 o
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 del
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
: 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.
Audito
>> 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
> 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 PIT
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. Th
> 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
> 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"
>>> 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
uot;The IBM z/VM Operating System"
06/05/2008 04:33 PM
Please respond to
"The IBM z/VM Operating System"
To
IBMVM@LISTSERV.UARK.EDU
cc
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
ns or policies of Hewitt Associates.
"Llewellyn, Mark" <[EMAIL PROTECTED]>
Sent by: "The IBM z/VM Operating System"
06/05/2008 04:19 PM
Please respond to
"The IBM z/VM Operating System"
To
IBMVM@LISTSERV.UARK.EDU
cc
Subject
Re: VM:Backup: Twinning Tapes to
On: Thu, Jun 05, 2008 at 01:53:18PM -0700,O'Brien, Dennis L Wrote:
} 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
There is a problem in a tape-tape copy that (so far) nobody has
mentioned that can bite
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
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 lo
.
-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.
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 t
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
wit
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 mes
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 ca
sent the opinions or policies of Hewitt Associates.
"Llewellyn, Mark" <[EMAIL PROTECTED]>
Sent by: "The IBM z/VM Operating System"
06/05/2008 03:44 PM
Please respond to
"The IBM z/VM Operating System"
To
IBMVM@LISTSERV.UARK.EDU
cc
Subject
Re: VM:Backup: Twinn
> 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
d
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 us
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
: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
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
=>ta
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
> 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.
> 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
>>> 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
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 w
40 matches
Mail list logo
