Mario,
If you are looking for something you saw mentioned on the IBMVM discussion
list, you can search the IBMVM list archives very easily for previous
posts by going to:
http://listserv.uark.edu/archives/ibmvm.html
that site is actually very simple -- and **should be saved in the browser
"favorites"** by every serious z/VM systems programmer.
You have already received several excellent suggestions. But all replies
are dependent on your particular system requirements.
For example, which of the following are included in your requirements?:
1) Capability to restore all or specific CMS files
2) Capability to restore whole MDISKs (e.g. disaster recovery) without
processing each individual file,
but with guaranteed file system integrity
a) this is only possible if the applications that write to the MDISK
are either completely shut down
(e.g. Linux servers shut down), or
b) if the backup is performed by an application fully aware of and
integrated with the file systems.
3) Capability to restore whole DASD (e.g. disaster recovery) without
processing each individual MDISK
a) this is only possible if the applications that write to the MDISK
are either completely shut down
(e.g. Linux servers shut down)
b) if the backup is performed by an application fully aware of and
integrated with the file systems.
4) Reliable database restores pretty much always require backup tools made
for those specific databases unless
the database has been shut down while the backups run.
Backups performed while filesystems are active can result in "one-way
encryption" - meaning that the backups complete successfully, but the
restore at not 100% successful. Consider an application that writes a
database across multiple MDISKs. If the system backs up one MDISK while
the application is writing to both disks, and then backs up the other
MDISK, the updated MDISKS are out of synch with each other.
Worse yet, of the backup system is just backing up tracks or cylinders of
data while the applications are writing to the file systems on MDISKs on
that disk, the tracks and cylinders containing that data are changing even
while the backup system is reading the disk. The backup will complete
without any errors, but any MDISK restores will yield unreliable data of
inconsistent file systems.
Linux caches many of its disk writes (so that I/O occurs in larger blocks
at one time since I/O on Intel hardware goes through the motherboard,
preventing other CPU activity), so any I/O to disk may not complete for "a
while". Backup systems that are unaware of writes that are still cached
in memory do not make reliable backups.
So the answer really depends on your site requirements.
- If everything can be shut down while DDR backups are made (perhaps from
a system IPLed from a stand-alone one-disk sysres), then the backups _can_
be reliable. To make DDR backups reliable requires understanding of what
might be happening on the whole disk, not just its MDISKs.
- If you use a backup product that is aware of the file systems (e.g. CA's
"VM:Backup", or IBM's "Backup and Restore Manager for z/VM" for CMS file
systems; or Bacula, IBM's TSM, or others for Linux guests), then you can
have reliable, restorable backups for those file systems.
Mike Walter
Aon Corporation
The opinions expressed herein are mine alone, not my employer's.
"Mario Izaguirre" <mizagui...@circulo.es>
Sent by: "The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU>
01/28/2011 02:34 AM
Please respond to
"The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU>
To
IBMVM@LISTSERV.UARK.EDU
cc
Subject
zVM Minidisk Backup process
Hi all, I wanted to ask about how to make a backup process of Mini Disk
from z/VM, I long ago looking for some references on the Internet I found
an example of how to make 16 copies of MiniDisk on a single tape
cartridge, but cannot remember page or how it was that I found.
Could someone help me how to do this process?
Best Regards,
Mario Izaguirre
Mainframe System Programmer
Barcelona, Spain
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.
