We're not using an agent, read again: 
>  Before we started shutting down our Linux P.O.C. guests (now down to 
only one) while backing them up from CMS, ...
 
Each night during the VM:Backups on one z/VM system, that system uses 
SENDFILE to send a file to the z/VM system running the Linux guests. 
 
The z/VM system running Linux guests then gracefully shuts down all the 
Linux guests (CP SIGNAL SHUTDOWN USER xxxxxxx) and responds via e-mail to 
the requesting system.   When it responds within a given timeout period, 
or if the timeout period expires, the backup (via share DASD) commences.

Cludgy?  You bet!  But it serves the requirement to get a reliable backup 
every night.  It also means that all the backups are done from one system, 
reducing program product maintenance issues.  Were we to implement Linux 
for System z in production, then it would be worth evaluating all the 
competing products that provide backup from within a Linux guest. 

Mike Walter
Hewitt Associates
The opinions expressed herein are mine alone, not my employer's.



"Austin, Alyce (CIV)" <aus...@nps.edu> 

Sent by: "The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU>
02/25/2010 05:48 PM
Please respond to
"The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU>



To
IBMVM@LISTSERV.UARK.EDU
cc

Subject
Re: z/VM backup&restore procedure






What ?agent? are you using on your Linux guest?
 

From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On 
Behalf Of Mike Walter
Sent: Thursday, February 25, 2010 2:17 PM
To: IBMVM@LISTSERV.UARK.EDU
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" <dsh...@bellsouth.net> 

Sent by: "The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU> 
02/25/2010 03:29 PM 


Please respond to
"The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU>



To
IBMVM@LISTSERV.UARK.EDU 
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: IBMVM@LISTSERV.UARK.EDU 
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:ib...@listserv.uark.edu] On 
Behalf Of Ivica Brodaric
Sent: Thursday, February 25, 2010 3:33 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: z/VM backup&restore procedure 
 
 
 
Ivica 
2010/2/26 Pluzhnikov Vsevolod <vpluzhni...@croc.ru> 
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. 




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. 

Reply via email to