Does anyone know when Linux decides to write cache out to DASD?

When the cache is full or when the data set is closed?

 

 

________________________________

From: The IBM z/VM Operating System [mailto:[email protected]] On
Behalf Of Doug Shupe
Sent: Friday, February 26, 2010 3:59 AM
To: [email protected]
Subject: Re: z/VM backup&restore procedure

 

Make sure you get an SPXTAPE backup of your NSS files that live in the
spool !

 

CMS saved segments etc... or you will have to go through the process to
recreate / resave them. Good practice is to have a SPXTAPE backup of NSS
spool files on hand for DR also.      

        ----- Original Message ----- 

        From: Martin, Terry R. (CMS/CTR) (CTR)
<mailto:[email protected]>  

        To: [email protected] 

        Sent: Thursday, February 25, 2010 20:05

        Subject: Re: z/VM backup&restore procedure

         

        Hi Mike,

         

        Thanks for the information. A couple of things, first I INIT all
of my SPOOL volumes and PAGE volumes via CPFMTXA on my z/VM system. I
INIT the other CKD volumes on z/OS (very carefully!).

         

        Second in our environment we do not have the luxury to bring
down our z/Linux guests nightly (About 15 guests) so we have no choice
but to take a "fuzzy" backup. We are aware that there may be some things
lost. I am working on ways to try handle this but it is not an easy
task. 

         

         

         

        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 Austin, Alyce (CIV)
        Sent: Thursday, February 25, 2010 6:48 PM
        To: [email protected]
        Subject: Re: z/VM backup&restore procedure

         

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

         

        
________________________________


        From: The IBM z/VM Operating System
[mailto:[email protected]] On Behalf Of Mike Walter
        Sent: Thursday, February 25, 2010 2:17 PM
        To: [email protected]
        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)
<mailto:[email protected]>  
        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. 

Reply via email to