Mike, Thank you for expounding on the 'dangers' of using z/OS backup/restore. Since you went there... Fuzzy backups of z/Linux 'generally' work without issue(so far for us too), Linux can do/does do a file system check at startup -BUT- Mike's WARNING should be taken very SERIOUSLY! Make sure your Management understands the risks - As Mike stated - 'Not a very good career enhancing move.'
z/VM system volumes? DDR backup, SA DDR restore. As mentioned in other posts, put the VM SA ICKDSF and SA DDR files as the first files (tape marks as needed).IPL the tape once and you have ICKDSF, IPL the tape again and you have DDR. At DR for non system volumes(z/Linux), we have good ol' z/VM REXX execs to CPFMTXA cyl 0 from z/VM, then bring volumes online to z/OS recovery system and restore. z/OS using dfdss TRACKS(x,x,xxxxx) backups and restores. That was before EMC SRDF replication but, we keep plan 'B'(bare metal) up-to-date just in case. This topic comes up often, there are many more thoughts in the list-serv archives. Doug ----- Original Message ----- From: Mike Walter To: [email protected] Sent: Thursday, February 25, 2010 17:16 Subject: Re: z/VM backup&restore procedure If you format VM DASD from VM using the CPFMTXA EXEC is will ALWAYS install a Format 5 label, and he few other and absolutely critical things that VM requires. If you are not very careful to read the ICKDSF doc when INITing a VM DASD from MVS, you can easily write a VTOC that makes it appear that the DASD has scads of free space available. Do that just ONE single time on a VM page DASD, and get it mounted (by accident, of course) on an MVS system as a PUBlic volume, and watch your VM system crash in seconds! Not a very good career enhancing move. Not mentioned when discussing backing up z/VM from a z/OS system, but critical... if that z/VM system is up and running, just like with z/OS, there are open files and databases that may span multiple volumes. Backing up a running z/VM system from any other system can easily result in "inconsistent file systems". That is especially true of backing up Linux guests from anywhere but an agent on that Linux guest -Linux heavily caches files in memory, so many open files may not be fully committed to disk at the time of the backup. Either shut down your z/VM system before backing it up from any other system (z/OS or even z/VM), or prepare for sporadic system, and/or application failures as the inconsistent filesystems are encountered. That said, for over 15 years our z/VM system **used to be** backed up by jobs on z/OS (and it's forerunners). Once the restores were completed at the D.R. site, we ran a CMS filesystem checker on every CMS minidisk, looking for problems - never had a single one. WE were very lucky, or very good, or something else entirely. But all that was before Linux guests. Before we started shutting down our Linux P.O.C. guests (now down to only one) while backing them up from CMS, the Linux sysprog (not an immediate believer in the warning) regularly had trouble restoring from nightly backups. Your gun, your foot. You've been warned. Mike Walter Hewitt Associates The opinions expressed herein are mine alone, not my employer's. "Doug Shupe" <[email protected]> Sent by: "The IBM z/VM Operating System" <[email protected]> 02/25/2010 03:29 PM Please respond to "The IBM z/VM Operating System" <[email protected]> To [email protected] cc Subject Re: z/VM backup&restore procedure Tried this once, ended up having to init the packs from z/OS. needed a Format 5 label if I recall correctly. ----- Original Message ----- From: Martin, Terry R. (CMS/CTR) (CTR) To: [email protected] Sent: Thursday, February 25, 2010 15:49 Subject: Re: z/VM backup&restore procedure Hi If you have a z/OS system and have connectivity to the z/VM packs you can run DFDSS full pack backup of all of your CKD packs and use ICKDSF to restore them. This is what I usually do when I want to copy my system packs for building a new z/VM LPAR for instance. Thank You, Terry Martin Lockheed Martin - Citic z/OS and z/VM Performance Tuning and Operating Systems Support Office - 443 348-2102 Cell - 443 632-4191 From: The IBM z/VM Operating System [mailto:[email protected]] On Behalf Of Ivica Brodaric Sent: Thursday, February 25, 2010 3:33 PM To: [email protected] Subject: Re: z/VM backup&restore procedure Ivica 2010/2/26 Pluzhnikov Vsevolod <[email protected]> Hello, All! Help me please in understanding the correct way of backup/restore z/VM system (on CKD dasd). I'll need to perform this because of disruptive upgrade of our DS8300. I'm testing now ddrxa. Is it possible to define all 3390 mod9 (540RES, 540SPL, 540PAG, USER.) dasd to maint as full-pack minidisks and just backup all of them on tape? You can, but I suggest a separate user, call it SYSDASD, SYSDISK, or whatever, with password NOLOG. Let that user own all full pack minidisks. You don't need any other statements in that user's directory except USER and MDISK for each full pack. Then link from a worker machine to perform backups. Can I perform a restore with IPL from tape and just typing new dasd in output command for restore or it can be done only from z/VM ? You can restore by IPLing the tape with DDRXA program on it first, and then mounting data tapes. To create the tape with ICKDSF, DDRXA and DIRECTXA on it, do UTILITY UTILTAPE ALL or UTILITY UTILTAPE DDR for just DDR after accessing MAINT 193. Tape needs to be attached as 181 for this. You may also put the DDR program at the start of your first backup tape using MOVEFILE: 1. Mount scratch tape and attach it to your machine as 181 2. Do the following commands: REW 181 FILEDEF IN DISK IPL DDRXA S FILEDEF OUT TAP1 (RECF F LRECL 80 BLOCK 80 MOVEFILE IN OUT You may then IPL this tape in your virtual machine for practice or on a real processor. Ivica ------------------------------------------------------------------------------ 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.
