.
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Dave Keeton
Sent: Wednesday, October 15, 2008 6:39 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: DirMaint CA's VM:Backup Software Installation
I am attempting to install VM:Backup from CA
VMRMAINT
Jim
David Boyes wrote:
This is a multi-part message in MIME format.
--_=_NextPart_001_01C92F97.DA79C3B0
Content-Type: text/plain;
charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Create a file with the directory entry VMIRMAINT shows you called
VMBACKUP
.
O'Brien, Dennis L Dennis.L.O'[EMAIL PROTECTED]
Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU
10/15/2008 04:03 PM
Please respond to
The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU
To
IBMVM@LISTSERV.UARK.EDU
cc
Subject
Re: DirMaint CA's VM:Backup Software
I am attempting to install VM:Backup from CA and it wants me to update
the directory with the user info for VMBACKUP. Trouble is, I'm using
DirMaint and I can't seem to figure out how to manually add the user as
the installation program has spelled out the entry for me.
Can I update the USER
:39
To: IBMVM@LISTSERV.UARK.EDU
Subject: [IBMVM] DirMaint CA's VM:Backup Software Installation
I am attempting to install VM:Backup from CA and it wants me to update
the directory with the user info for VMBACKUP. Trouble is, I'm using
DirMaint and I can't seem to figure out how to manually add
.
O'Brien, Dennis L Dennis.L.O'[EMAIL PROTECTED]
Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU
10/15/2008 04:03 PM
Please respond to
The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU
To
IBMVM@LISTSERV.UARK.EDU
cc
Subject
Re: DirMaint CA's VM:Backup Software Installation
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
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
: 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
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
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
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
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
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
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
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
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
@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
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
] Subject
ARK.EDU VM:Backup: Twinning Tapes to Remote
Tape Unit
06/05/2008 01:12
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
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
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.
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
[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
: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
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
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
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
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
@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
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
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
-
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
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
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
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
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
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
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
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,
anybody running VM:Backup that can tell me where to put the LMP key?
there is no reference to it in the VM:Backup manuals.
prg
Phillip Gramly
Systems Programmer
Communications Data Group
Champaign, IL
To: IBMVM@LISTSERV.UARK.EDU
Subject: VM:Backup lmp key
anybody running VM:Backup that can tell me where to put the LMP key?
there is no reference to it in the VM:Backup manuals.
prg
Phillip Gramly
Systems Programmer
Communications Data Group
Champaign, IL
VM:Backup lmp key
09/25/2007 11:42
AM
the right to be
taken seriously. - Hubert Humphrey
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of [EMAIL PROTECTED]
Sent: Tuesday, September 25, 2007 11:42
To: IBMVM@LISTSERV.UARK.EDU
Subject: [IBMVM] VM:Backup lmp key
anybody running
I am looking for a replacement for VM:Backup. It could be a collection of
utilities.
What other tools are available - both IBM supplied utilities and/or third
party utilities.
prg
Phillip Gramly
Systems Programmer
Communications Data Group
Champaign, IL
IBM Backup and Restore Manager for z/VM:
http://www-306.ibm.com/software/stormgmt/zvm/backup/
[EMAIL PROTECTED] wrote:
I am looking for a replacement for VM:Backup. It could be a collection
of utilities.
What other tools are available - both IBM supplied utilities and/or
third party
IT Specialist
Office of Information Technology
State of New Jersey
(609) 984-4065
President MVMUA
http://www.marist.edu/~mvmua
[EMAIL PROTECTED] wrote:
I am looking for a replacement for VM:Backup. It could be a collection
of utilities.
What other tools are available - both IBM supplied
Does anyone know how to remove a specific user's data from the VM:Backup
catalogs? Commands are preferred over brute force, but I have not found such a
command - that or I didn't recognize it when I saw it.
Regards,
Richard Schuh
Last I knew... no can do unless the user's data was in a specific backup
job (in which case you can expire that job prematurely).
We had a similar legal requirement in which we were required to remove
data. The best we could do was to develop and write a new VM:Backup exit
which prevented
Operating System [mailto:[EMAIL PROTECTED]
Behalf Of Mike Walter
Sent: Friday, September 22, 2006 9:07 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Uncatalog Files in VM:Backup
Last I knew... no can do unless the user's data was in a
specific backup
job (in which case you can expire
51 matches
Mail list logo
