The ultimate, I think, would be a VM based backup tool that plays nice
with the Linux file system. It would:

1. Recognize if Linux is running.
2. If Linux is running, tell it to purge it's file cache and 'go to
sleep'.
3. Access a Linux minidisk and understand the file system that resides
there.
4. Run full / incremental backup or restore. 
5. Tell Linux to wake up when it's over.

This would also allow easy recovery of dead penguins, as well as take
advantage of proven backup tools. Sounds simple on paper at least.


Ray Mrohs
U.S. Department of Justice
202-307-6896
 

> -----Original Message-----
> From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On 
> Behalf Of Eddie Chen
> Sent: Friday, June 29, 2007 2:29 PM
> To: LINUX-390@VM.MARIST.EDU
> Subject: Re: Backup and Restore Strategies For Z/Linux
> 
> I think there is two or more issues,  backing up the data 
> using DDR type
> backup only gives you full backup. therefore you need to install/get
> software package to do you back.
> 
> The problems are:
> 
>    -   Many  linux server  where password changes,  many 
> other thing get
> installed on that servers.
>    -   Your not the ADMIN  in control of those servers.
>    -   not all servers are the same. and many others...
> 
>    If you are lucky,   only have few  hours  to do your 
> backup, Sunday from
> 2am-5am.
> 
>  z/VM we perform  the  clone,   is the same as cratering a 
> golden image or
> install linux from a network.  The problem is keep track  all  the
> installed  software and  what  was  changed
>  on those servers... /etc/passwd
> 
>  .  If you lost you  "/usr"...   the backup  you did was just 
> waste of time
> -- you need to boot from "recovery disk", chroot .
> 
>  . May be DDR type backup is the best
> 
> ..  Boot linux from a "recovery system(disk)" and mount that 
> filesystem(s)
> to correct the problem -- if need,  run the restore.
> 
>  I know there is a shop(s) that do there install from a  "one 
>  servers",
> all ADMINs uses(go thru)  that servers to  install, config... etc to
> address this issue .
>  it seems if there is good maintenance  procedures then 
> recovery is less
> pain.
> 
> 
> 
> 
> 
>                 "McKown, John"
>              <[EMAIL PROTECTED]
>              thmarkets.com>                                   
>           To
>                 Sent by: Linux         LINUX-390@VM.MARIST.EDU
>              on 390 Port                                      
>           cc
>              <[EMAIL PROTECTED]
>              IST.EDU>                                         
>      Subject
>                                        Re: Backup and Restore 
> Strategies
>                                        For Z/Linux
>                 06/29/2007
>              11:14 AM
> 
> 
>              Please respond to
>              Linux on 390 Port
>              <[EMAIL PROTECTED]
>                  IST.EDU>
> 
> 
> 
> 
> 
> 
> > -----Original Message-----
> > From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On
> > Behalf Of Paul Noble
> > Sent: Friday, June 29, 2007 10:01 AM
> > To: LINUX-390@VM.MARIST.EDU
> > Subject: Re: Backup and Restore Strategies For Z/Linux
> >
> >
> > So, if I'm understanding this correctly, taking a backup of a
> > running Linux system from another LPAR gives you, at best, an
> > unreliable backup.
> 
> That's certainly how I read it.
> 
> >
> > That means that there are only two viable alternatives:
> >
> > Shut down Linux and do the backup from another LPAR or,
> 
> Yes. The plus is that you can then restore your Linux environment the
> same way that you restore the z/OS or z/VM environment. Also, you can
> manage your tapes using your standard tape management software (which
> doesn't exist at all on Linux, as I understand it). The minus is
> unavailability of the Linux system during this time (which is 
> shorted by
> some sort of "snap shot", if you have that capability) and well as it
> being an "all or nothing" DASD level backup / restore, which is not
> useful for restoring individual files.
> 
> >
> > Use a backup client that runs within Linux and therefore
> > participates in its file system processing, getting all the
> > current and correct data for the backup.
> 
> Correct. But, again, Linux does not interface to the "normal" tape
> management systems used by other System z operating systems.
> 
> >
> > Is that about it?
> >
> > The problem, as I see it, with backing up from another LPAR
> > is that there is no incremental or differential backup
> > capability. Nor is there any selective restore capability.
> > Its an all-or-nothing backup/restore.
> 
> Yea.
> 
> >
> > Paul Noble
> > Cuyahoga County Information Service Center
> 
> 
> 
> --
> John McKown
> Senior Systems Programmer
> HealthMarkets
> Keeping the Promise of Affordable Coverage
> Administrative Services Group
> Information Technology
> 
> The information contained in this e-mail message may be privileged
> and/or confidential.  It is for intended addressee(s) only.  
> If you are
> not the intended recipient, you are hereby notified that any 
> disclosure,
> reproduction, distribution or other use of this communication is
> strictly prohibited and could, in certain circumstances, be a criminal
> offense.  If you have received this e-mail in error, please notify the
> sender by reply and delete this message without copying or disclosing
> it.
> 
> ----------------------------------------------------------------------
> For LINUX-390 subscribe / signoff / archive access instructions,
> send email to [EMAIL PROTECTED] with the message: INFO 
> LINUX-390 or
> visit
> http://www.marist.edu/htbin/wlvindex?LINUX-390
> 
> 
> 
> 
> 
> Visit our website at http://www.nyse.com
> 
> ****************************************************
> 
> Note:  The information contained in this message and any attachment
> to it is privileged, confidential and protected from 
> disclosure.  If the
> reader of this message is not the intended recipient, or an employee
> or agent responsible for delivering this message to the intended
> recipient, you are hereby notified that any dissemination,
> distribution or copying of this communication is strictly prohibited.
> If you have received this communication in error, please notify the
> sender immediately by replying to the message, and please delete
> it from your system. Thank you.  NYSE Group, Inc.
> 
> ----------------------------------------------------------------------
> For LINUX-390 subscribe / signoff / archive access instructions,
> send email to [EMAIL PROTECTED] with the message: INFO 
> LINUX-390 or visit
> http://www.marist.edu/htbin/wlvindex?LINUX-390
> 

----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Reply via email to