--
From: David Boyes <[EMAIL PROTECTED]>
Subject: Re: Backup and Restore Strategies For Z/Linux
> You mean something like this?
> http://sinenomine.net/vm/ext2free
EXT2FREE and friends are not intended to be used with a running system.
They would suffer from the same
>
> You mean something like this?
> http://sinenomine.net/vm/ext2free
EXT2FREE and friends are not intended to be used with a running system.
They would suffer from the same problems of not being aware of cached
data in memory.
---
We do incremental backups using FDR/Upstream and Hipersockets. The
incrementals are used to recover a file if a problem occurs. Since we
separate user data from Linux data, there is not much Linux data involved
in these incrementals.
However, we have a scheduled outage for z/VM once a week. When w
Mrohs, Ray wrote:
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'.
Suspend to disk. Linux does it on Intellish systems.
3.
Subject: Re: Backup and Restore Strategies For Z/Linux
I experimented with using the Linux install system (when you IPL the reader
when under VM), to link over to the bad system. That seemed to work. It was
fine for manual editing of configuration files, but didn't include all the
sof
D]
gov> To
Sent by: Linux LINUX-390@VM.MARIST.EDU
on 390 Port cc
<[EMAIL PROTECTED]
IST.EDU>
cc
<[EMAIL PROTECTED]
IST.EDU> Subject
Re: Backup and Restore Strategies
For Z/Linux
06/29/2007
03:09 PM
Pl
>>> On Fri, Jun 29, 2007 at 3:09 PM, in message
<[EMAIL PROTECTED]>,
"Mrohs, Ray" <[EMAIL PROTECTED]> wrote:
> 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
6
> -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 is
LINUX-390@VM.MARIST.EDU
on 390 Portcc
<[EMAIL PROTECTED]
IST.EDU> Subject
Re: Backup and Restore Strategies
>>> On Fri, Jun 29, 2007 at 11:59 AM, in message
<[EMAIL PROTECTED]>, "McKown,
John" <[EMAIL PROTECTED]> wrote:
> Along this same track - if one uses a Linux based backup and restore
> utility, then how does one restore a "base image" in a disaster
> situation?
Funny you should ask.
http://sinen
> Along this same track - if one uses a Linux based backup and restore
> utility, then how does one restore a "base image" in a disaster
> situation? D.R. providers generally have a z/OS and z/VM environment.
> How many have a Linux environment to do the restores? I would ASSuME
> that if I used Li
Along this same track - if one uses a Linux based backup and restore
utility, then how does one restore a "base image" in a disaster
situation? D.R. providers generally have a z/OS and z/VM environment.
How many have a Linux environment to do the restores? I would ASSuME
that if I used Linux to dum
>>> On Fri, Jun 29, 2007 at 11:00 AM, in message
<[EMAIL PROTECTED]>, Paul Noble <[EMAIL PROTECTED]>
wrote:
-snip-
> 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. I
> 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.
Yep.
> That means that there are only two viable alternatives:
> Shut down Linux and do the backup from another LPAR or,
> Use a backup client that
> -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
Correct on all counts. Using a tool like Bacula (open source, but
support available and z/OS friendly) or TSM (from IBM) provides the file
level backup and recoverability required in this environment.
Paul Noble wrote:
So, if I'm understanding this correctly, taking a backup of a running 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 means that there are only two viable alternatives:
Shut down Linux and do the backup from another LPAR or,
Use a backup client that runs within Lin
Well OK, maybe the analogy wasn't absolutely perfect. The point is on
reboot Linux will think it crashed, Linux will attempt to rebuild it's
filesystem, it may or may not work. Don't take the chance with your
corporate data.
Rob van der Heij wrote:
On 6/29/07, Rich Smrcina <[EMAIL PROTECTED]>
On 6/29/07, Rich Smrcina <[EMAIL PROTECTED]> wrote:
It's exactly like rebooting a Linux PC after some sort of crash, it goes
through a filesystem check (fsck).
There's a big difference. If the PC crashes you have a consistent
state as it was at that time. But when you have z/OS on the other en
Paul,
Your method provides you with the best backup possible with the tools
that you have. It's benefit is that is that it is a consistent backup,
whereas if you did not shut down the Linux machines you would have an
inconsistent backup where on startup your Linux machines would have to
attempt
We are new to z/Linux here, so I could be wrong in what I'm about to say.
Please correct me if I am.
We run z/OS in one LPAR and z/VM, with several Linux guests, in another. I
don't think that the presences of z/VM makes a difference with respect to
backups.
We were told by the consultant who
> We would like the process to be as automated as possible. We could
train
> the operators to shutdown Linux, run the backup, and then bring it
back
> up, but we would like to avoid that if possible.
>
> We would also like to avoid bringing a tape drive online to Linux. We
> don't have the resourc
Check with the folks at Sine Nomine. The have a solution that involves
an Open Source backup package and an interface to MVS tape management.
Jones, Russell wrote:
We are running z/Linux in an LPAR. It is a 1 volume system. We are
currently using an MVS batch job to back up the volume while Lin
We are running z/Linux in an LPAR. It is a 1 volume system. We are
currently using an MVS batch job to back up the volume while Linux is
running. I know that this is not a good idea, and I would like to know
how other shops handle backup and restore of their z/Linux systems. So
far, our method has
25 matches
Mail list logo
