Ar Sad, 2006-07-29 am 11:08 +0800, ysgrifennodd John Summerfield:
> Aside from users' aversion to cookies, their correct use isn't any
> easier than good backups;-) I reckon a lot of application authors trust
> the data held cookies, saying "we provided that so we know it's okay."
It is possible
Mark Perry wrote:
- Start Original Message -
Sent: Fri, 28 Jul 2006 12:35:26 +0200
From: Rob van der Heij <[EMAIL PROTECTED]>
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Bad Linux backups
I would hope that anything that prevents the flashcopy
from starting could be reported for e
Post, Mark K wrote:
From what I've seen, a lot of that information is usually kept in the
user's browser via cookies or "session cookies." For things that
aren't, mirroring the data on separate physical devices, on separate
controllers, etc., etc., provides the redundancy needed. The whole
poin
] On Behalf Of J
Leslie Turriff
Sent: Friday, July 28, 2006 11:04 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Bad Linux backups
Well, I can see that clustering is a solution to the availability of a
service while a host is shut down, but I don't see how it makes thinks
any better in regar
> >From what I've seen, a lot of that information is usually kept in the
> user's browser via cookies or "session cookies." For things that
> aren't, mirroring the data on separate physical devices, on separate
> controllers, etc., etc., provides the redundancy needed.
The other common technique
Thursday, July 27, 2006 8:37 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Bad Linux backups
David Boyes wrote:
>I think Lea means:
>
>For cluster takeover to work seamlessly, your application has to keep
>session data in some common location between the servers.
There's the po
>>On Wed, Jul 26, 2006 at 01:27:06PM -0500, J Leslie Turriff wrote:
>>Okay, now, wait; are you saying that the storage device _does_ have a
>>mechanism for communicating with the Linux filesystem to determine
what
>>filesystem pages are still cached in main storage and have not yet
been
>>commited
: Thursday, July 27, 2006 8:37 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Bad Linux backups
David Boyes wrote:
> I think Lea means:
>
> For cluster takeover to work seamlessly, your application has to keep
> session data in some common location between the servers.
There's the
David Boyes wrote:
I think Lea means:
For cluster takeover to work seamlessly, your application has to keep
session data in some common location between the servers.
There's the point that has me: how do you backup that location? Is it
something that, if it fails, you quickly find a new one an
- Start Original Message -
Sent: Fri, 28 Jul 2006 12:35:26 +0200
From: Rob van der Heij <[EMAIL PROTECTED]>
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Bad Linux backups
> I would hope that anything that prevents the flashcopy
> from starting could be reported for example wi
On 7/28/06, Mark Perry <[EMAIL PROTECTED]> wrote:
> Unless I am terribly misinformed, it *is* an atomic operation for the
> operating system.
Sorry Rob, but your are terribly misinformed.
What I meant to say with "atomic operation" is that things remain in order.
The flashcopy itself is ini
Rob van der Heij wrote:
On 7/26/06, Mark Perry <[EMAIL PROTECTED]> wrote:
One point not mentioned yet, is that FLASHCOPY is an asynchronous
process. You can start a FLASHCOPY operation and it *can* return an
error status asynchronously. 90+% of the time this is not apparent,
the request is made
-enters the cluster and all is
well.
David Boyes
Sine Nomine Associates
> -Original Message-
> From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of
John
> Summerfied
> Sent: Thursday, July 27, 2006 7:46 PM
> To: LINUX-390@VM.MARIST.EDU
> Subject: Re: Bad Lin
Stahr, Lea wrote:
A piece of cake! Use VMUTIL on VM to do the shutdowns and startups and
have the backups scheduled appropriately. Or get the CONTROL-M agent and
have that do it all from ZOS.
I don't understand how that addresses my concern.
Stahr, Lea wrote:
With clustering, you shut down
On Wed, Jul 26, 2006 at 03:04:34PM -0400, Alan Altmark wrote:
> On Wednesday, 07/26/2006 at 01:27 EST, J Leslie Turriff
> <[EMAIL PROTECTED]> wrote:
> > Okay, now, wait; are you saying that the storage device _does_ have a
> > mechanism for communicating with the Linux filesystem to determine what
On Wed, Jul 26, 2006 at 01:27:06PM -0500, J Leslie Turriff wrote:
> Okay, now, wait; are you saying that the storage device _does_ have a
> mechanism for communicating with the Linux filesystem to determine what
> filesystem pages are still cached in main storage and have not yet been
> commited to
On Wed, Jul 26, 2006 at 12:50:09PM -0400, Alan Altmark wrote:
> You're right, however, and as we've been discussing, that these features
> can be misused or misinterpreted to provide an *application*-consistent
> view of the data. They don't do that. That applies to any operating
> system, not ju
On Wed, Jul 26, 2006 at 06:21:03PM +0200, Rob van der Heij wrote:
> On 7/26/06, Mark Perry <[EMAIL PROTECTED]> wrote:
>
> >One point not mentioned yet, is that FLASHCOPY is an asynchronous process.
> >You can start a FLASHCOPY operation and it *can* return an error status
> >asynchronously. 90+% of
On Thursday, 07/27/2006 at 09:57 ZE2, Carsten Otte <[EMAIL PROTECTED]>
wrote:
> I am sorry, but I have to disagree with Alan's statement. They _are_
> currently dangerous to use with Linux volumes that are being accessed
> _because_ unlike dm-snapshot the filesystem is not frozen in Linux
> (lockfs
on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of
John Summerfied
Sent: Wednesday, July 26, 2006 7:18 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Bad Linux backups
Stahr, Lea wrote:
> With clustering, you shut down one image and do an OFFLINE backup
while
> the application runs on the
] On Behalf Of
Alan Altmark
Sent: Wednesday, July 26, 2006 3:13 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Bad Linux backups
On Wednesday, 07/26/2006 at 02:55 EST, J Leslie Turriff
<[EMAIL PROTECTED]> wrote:
> Okay. I may be wrong, but it seems to me that the majority of Linux
>
J Leslie Turriff wrote:
Sounds to me, then, like the use of the
snapshot/mirror/peer-to-peer copy features of storage devices e.g.
Shark, SATABeast, etc. are currently dangerous to use with Linux
filesystems. They would need to be able to coordinate their activities
with the filesystem lock
Carsten Otte wrote:
Fargusson.Alan wrote:
I agree. I think you should make your backups with the Linux system down. You
should test this to make sure that there is not some other operational error
causing problems.
I think we got close to the bottom of the stack now: If one can take
down
Alan Altmark wrote:
On Wednesday, 07/26/2006 at 01:27 EST, J Leslie Turriff
<[EMAIL PROTECTED]> wrote:
Okay, now, wait; are you saying that the storage device _does_ have a
mechanism for communicating with the Linux filesystem to determine what
filesystem pages are still cached in main storage
Stahr, Lea wrote:
With clustering, you shut down one image and do an OFFLINE backup while
the application runs on the second image. Then bring up the primary
image and shutdown the secondary system for backup.
which sounds every bit as tricky to me as getting good backups from a
live Linux sys
J Leslie Turriff wrote:
> Okay, now, wait; are you saying that the storage device _does_ have a
> mechanism for communicating with the Linux filesystem to determine what
> filesystem pages are still cached in main storage and have not yet been
> commited to external storage?
No, it does not. Invent
> On Wednesday, 07/26/2006 at 10:33 EST, J Leslie Turriff
> <[EMAIL PROTECTED]> wrote:
>> Sounds to me, then, like the use of the
>> snapshot/mirror/peer-to-peer copy features of storage devices e.g.
>> Shark, SATABeast, etc. are currently dangerous to use with Linux
>> filesystems. They would nee
On Wednesday, 07/26/2006 at 02:55 EST, J Leslie Turriff
<[EMAIL PROTECTED]> wrote:
> Okay. I may be wrong, but it seems to me that the majority of Linux
> applications (probably excepting database packages and such) rely on the
> filesystem to eventually get their data to disk without them doing
>
On Wednesday, 07/26/2006 at 02:20 AST, David Kreuter
<[EMAIL PROTECTED]> wrote:
> including ESTABLISH, QUERY and WITHDRAW ala ickdsf on z/OS?
> will ickdsf on z/vm be changed to support these functions?
I give an inch and you want a mile! :-) We will, among other things, be
adding a QUERY capab
Okay. I may be wrong, but it seems to me that the majority of Linux
applications (probably excepting database packages and such) rely on the
filesystem to eventually get their data to disk without them doing
anything besides open, write and close operations.
J. Leslie Turriff
VM Systems Progr
On Wednesday, 07/26/2006 at 01:27 EST, J Leslie Turriff
<[EMAIL PROTECTED]> wrote:
> Okay, now, wait; are you saying that the storage device _does_ have a
> mechanism for communicating with the Linux filesystem to determine what
> filesystem pages are still cached in main storage and have not yet b
Okay, now, wait; are you saying that the storage device _does_ have a
mechanism for communicating with the Linux filesystem to determine what
filesystem pages are still cached in main storage and have not yet been
commited to external storage?
J. Leslie Turriff
VM Systems Programmer
Central Mi
including ESTABLISH, QUERY and WITHDRAW ala ickdsf on z/OS?
will ickdsf on z/vm be changed to support these functions?
David
Yes, the CP FLASHCOPY command is one of those asynchronous commands. But
take heart! We are busily improving it, making it more suitable for use
in scripts. (And adding
On Wednesday, 07/26/2006 at 01:59 AST, Michael
MacIsaac/Poughkeepsie/[EMAIL PROTECTED] wrote:
> The z/VM FLASHCOPY command can give a return code of 0 and then *fail*
> later asynchronously. It is difficult to trap in REXX (for a mere mortal
> like myself). And it will fail reliably (and asynchron
> Unless I am terribly misinformed, it *is* an atomic operation for the
> operating system. Even though from a storage management point of view
> it may take some time.
The z/VM FLASHCOPY command can give a return code of 0 and then *fail*
later asynchronously. It is difficult to trap in REXX (for
On Wednesday, 07/26/2006 at 10:33 EST, J Leslie Turriff
<[EMAIL PROTECTED]> wrote:
> Sounds to me, then, like the use of the
> snapshot/mirror/peer-to-peer copy features of storage devices e.g.
> Shark, SATABeast, etc. are currently dangerous to use with Linux
> filesystems. They would need to be
On 7/26/06, Mark Perry <[EMAIL PROTECTED]> wrote:
One point not mentioned yet, is that FLASHCOPY is an asynchronous process. You
can start a FLASHCOPY operation and it *can* return an error status
asynchronously. 90+% of the time this is not apparent, the request is made and
the Shark goes ha
J Leslie Turriff wrote:
> Sounds to me, then, like the use of the
> snapshot/mirror/peer-to-peer copy features of storage devices e.g.
> Shark, SATABeast, etc. are currently dangerous to use with Linux
> filesystems. They would need to be able to coordinate their activities
> with the filesys
- Start Original Message -
Sent: Wed, 26 Jul 2006 10:33:32 -0500
From: J Leslie Turriff <[EMAIL PROTECTED]>
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Bad Linux backups
> Sounds to me, then, like the use of the
> snapshot/mirror/peer-to-peer copy features of storage
Sounds to me, then, like the use of the
snapshot/mirror/peer-to-peer copy features of storage devices e.g.
Shark, SATABeast, etc. are currently dangerous to use with Linux
filesystems. They would need to be able to coordinate their activities
with the filesystem lock/unlock components of the
On Wed, Jul 26, 2006 at 02:28:53PM +0200, Carsten Otte wrote:
> Very interresting indeed. This pointed me to reading the
> lockfs/unlockfs semantics in Linux, and I think I need to withdraw my
> statement regarding flashcopy snapshots: because of the fact that
> there is no lockfs/unlockfs interact
- Start Original Message -
Sent: Wed, 26 Jul 2006 11:49:45 +0200
From: Christoph Hellwig <[EMAIL PROTECTED]>
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Bad Linux backups
> On Tue, Jul 25, 2006 at 01:22:53PM +0200, Mark Perry wrote:
> > I believe that several DB systems offer
Christoph Hellwig wrote:
> But that's not how snapshot work. When you do a snapshot the filesystem
> is frozen. That means: new file writers are blocked from dirtying the
> filesystem throug the pagecache. The filesystem block callers that want
> to create new transactions. Then the whole file
On Tue, Jul 25, 2006 at 09:06:54AM +0800, John Summerfied wrote:
> To avoid the nitpickers, let's say that David means all filesystems must
> be flushed and ro.
>
> As I understand it, journalling (by default) logs metadata (dirctory
> info) but not data.
>
> If you create a file, that's journalled
On Tue, Jul 25, 2006 at 01:22:53PM +0200, Mark Perry wrote:
> I believe that several DB systems offer direct/raw I/O to avoid Linux cache
> problems, and that journaling filesystems, although by default only journal
> meta-data, offer mount options to journal data too. This of course comes at
> a
25, 2006 8:18 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Bad Linux backups
FDR says working as designed. They back up the entire volume and restore
the entire volume. I have restored 3 systems and they DO NOT BOOT.
Lea Stahr
Sr. System
On Tuesday, 07/25/2006 at 02:19 ZE2, Carsten Otte <[EMAIL PROTECTED]>
wrote:
> Stahr, Lea wrote:
> > FDR says working as designed. They back up the entire volume and
restore
> > the entire volume. I have restored 3 systems and they DO NOT BOOT.
> How does FDR copy the volume? Do they sequentially c
Linux/Unix Team
630-753-5445
[EMAIL PROTECTED]
-Original Message-
From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of
David Boyes
Sent: Tuesday, July 25, 2006 10:11 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Bad Linux backups
> Therefore, dm-snapshot and
> flashcopy ar
Rob van der Heij wrote:
On 7/25/06, John Campbell <[EMAIL PROTECTED]> wrote:
In all of this, isn't the UNIONFS still a live deal? If as many client
systems as possible use a set of backing F/Ss that are Read Only,
wouldn't
Yes, it's mostly working. I have done quite a lot with it on s390. Yo
On 7/25/06, John Campbell <[EMAIL PROTECTED]> wrote:
In all of this, isn't the UNIONFS still a live deal? If as many client
systems as possible use a set of backing F/Ss that are Read Only, wouldn't
Yes, it's mostly working. I have done quite a lot with it on s390. You
probably don't want to
Subject
Re: [LINUX-390] Bad Linux backups
07/24/06 04:38 PM
Please respond to
Linux on 390 Port
<[EMAIL PROTECTED]
IST.EDU>
On Jul 24, 2006, at 1:3
> Earlier in this thread there was mention of using clustering
> services to avoid outages while doing backups. Wouldn't that involve
> the same sort of data-in-flight issues?
Not really, because the major thrust of clustering tools is to
coordinate the services and workload between the clus
J Leslie Turriff wrote:
> Earlier in this thread there was mention of using clustering
> services to avoid outages while doing backups. Wouldn't that involve
> the same sort of data-in-flight issues?
If the data is shared among the nodes, like with nfs or a cluster
filesystem, yes.
with kind
Message-
From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of J
Leslie Turriff
Sent: Tuesday, July 25, 2006 10:54 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Bad Linux backups
Earlier in this thread there was mention of using clustering
services to avoid outages while doing backups
Earlier in this thread there was mention of using clustering
services to avoid outages while doing backups. Wouldn't that involve
the same sort of data-in-flight issues?
J. Leslie Turriff
VM Systems Programmer
Central Missouri State University
Room 400
Ward Edwards Building
Warrensburg MO
On Jul 25, 2006, at 8:49 AM, Carsten Otte wrote:
James Melin wrote:
Not even remotely close to what I was thinking Greater minds
than mine any ideas?
Oh not me. The oops seems to be issued in the filesystem code,
probably reiserfs. Lea, could you run the oops message through
ksymoops p
James Melin wrote:
> Not even remotely close to what I was thinking Greater minds than
> mine any ideas?
Oh not me. The oops seems to be issued in the filesystem code,
probably reiserfs. Lea, could you run the oops message through
ksymoops please?
regards,
Carsten
--
Fargusson.Alan wrote:
> I agree. I think you should make your backups with the Linux system down.
> You should test this to make sure that there is not some other operational
> error causing problems.
I think we got close to the bottom of the stack now: If one can take
down the system for backu
25/2006 09:31 AM
Subject
Re: Bad
Linux backups
Please respond to
David Boyes wrote:
>> Therefore, dm-snapshot and
>> flashcopy are two sides of the same medal once the entire filesystem
>> is on a single dasd.
>
> That's a pretty large assumption, especially since the recommended
> wisdom for most "advanced applications" -- like DB/2 and WAS -- is *not*
> to put
, 2006 8:28 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Bad Linux backups
Gentlemen, I must agree with the validity of external backups, but only
when the Linux is down. Any backup taken internally OR externally while
the system is running may not work due to extensive caching by the
system itself
AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Bad Linux backups
> Therefore, dm-snapshot and
> flashcopy are two sides of the same medal once the entire filesystem
> is on a single dasd.
That's a pretty large assumption, especially since the recommended
wisdom for most "advanced ap
> Therefore, dm-snapshot and
> flashcopy are two sides of the same medal once the entire filesystem
> is on a single dasd.
That's a pretty large assumption, especially since the recommended
wisdom for most "advanced applications" -- like DB/2 and WAS -- is *not*
to put things like data and logs on
]
-Original Message-
From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of
Jeremy Warren
Sent: Tuesday, July 25, 2006 8:50 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Bad Linux backups
Did you try the fdr from cyl / to cyl options on the backups? This
sounds
eerily familar to our label
nux/Unix Team
630-753-5445
[EMAIL PROTECTED]
-Original Message-
From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of
James Melin
Sent: Tuesday, July 25, 2006 8:43 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Bad Linux backups
I think I might have an idea as to where your prob
What happens when you try to boot a restored system?
Jon
FDR says working as designed. They back up the entire volume and restore
the entire volume. I have restored 3 systems and they DO NOT BOOT.
--
For LINUX-390 subscribe /
inux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of
John Summerfied
Sent: Monday, July 24, 2006 6:03 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Bad Linux backups
Stahr, Lea wrote:
> I run SuSE SLES 8 under ZVM 5.1 in an IFL. The DASD are in a SAN that
is
> also accessed by ZOS. Backups are
LINUX-390@VM.MARIST.EDU
cc
07/25/2006 07:17 AM
Subject
Stahr, Lea wrote:
> FDR says working as designed. They back up the entire volume and restore
> the entire volume. I have restored 3 systems and they DO NOT BOOT.
How does FDR copy the volume? Do they sequentially copy track-by-track
or use flashcopy?
cheers,
Carsten
--
PROTECTED] On Behalf Of
John Summerfied
Sent: Monday, July 24, 2006 6:03 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Bad Linux backups
Stahr, Lea wrote:
> I run SuSE SLES 8 under ZVM 5.1 in an IFL. The DASD are in a SAN that
is
> also accessed by ZOS. Backups are taken by ZOS using FDR full
- Start Original Message -
Sent: Tue, 25 Jul 2006 11:48:09 +0200
From: Ingo Adlung <[EMAIL PROTECTED]>
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Bad Linux backups
> Linux on 390 Port wrote on 25.07.2006 11:23:02:
>
> > Alan Altmark wrote:
> > > But, Carsten, t
Ingo Adlung wrote:
> Whether the file system is consistent in itself after a restart is
> irrelevant form an application perspective if the application has e.g.
> state that is independent from the file system content. You can only
> capture that by application collaboration or by forcing that stat
David Boyes wrote:
> As others have described, just dumping the data actually physically on
> the disk doesn't always provde a consistent backup that is useful for
> restoring the system. You *must* coordinate what happens inside the
> guest with something outside the guest -- regardless of what th
Linux on 390 Port wrote on 25.07.2006 11:23:02:
> Alan Altmark wrote:
> > But, Carsten, the application may start up just fine, however it may be
> > using old data. I have an application running on my workstation right
now
> > that saves its configuration data only when you shut it down (workin
Linux on 390 Port wrote on 25.07.2006 11:10:04:
> > Carsten Otte wrote:
> >> Wrong. Due to caching, as correctly described by David Boyes, the
> >> system may change on-disk content even when the application is not
> >> running. Example: the syslogd generates a "mark" every 20 minutes.
>
> John S
Alan Altmark wrote:
> On Monday, 07/24/2006 at 06:35 ZE2, Carsten Otte <[EMAIL PROTECTED]> wrote:
>>> But rather than focus on that "edge" condition, we are all, I think,
> in
>>> violent agreement that you cannot take a volume-by-volume physical
> backup
>>> from outside a running Linux system and
Alan Altmark wrote:
> But, Carsten, the application may start up just fine, however it may be
> using old data. I have an application running on my workstation right now
> that saves its configuration data only when you shut it down (working as
> designed according to the vendor). Since the appli
> Carsten Otte wrote:
>> Wrong. Due to caching, as correctly described by David Boyes, the
>> system may change on-disk content even when the application is not
>> running. Example: the syslogd generates a "mark" every 20 minutes.
John Summerfied wrote:
> syslogd's mark message has nothing to do w
Dominic Coulombe wrote:
I'm sorry, but I don't get your point.
"I don't mind losing data on the system filesystems as we are only
interested in the database stuff."
On 24-Jul-2006, at 19:19, John Summerfied wrote:
so you don't care that it doesn't actually work!
It might be that in your
I'm sorry, but I don't get your point.
On 24-Jul-2006, at 19:19, John Summerfied wrote:
so you don't care that it doesn't actually work!
--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL
Dominic Coulombe wrote:
On 7/24/06, David Boyes <[EMAIL PROTECTED]> wrote:
One more time: Unless your Linux systems *are completely down* at the
time of backup, full volume dumps from outside the Linux system are more
than likely to be useless.
Can you explain why is that ?
To avoid the
On Behalf Of
Jon
> Brock
> Sent: Monday, July 24, 2006 4:46 PM
> To: LINUX-390@VM.MARIST.EDU
> Subject: Re: Bad Linux backups
>
> Our robotics are controlled by Storagetek's software on our z/OS
system;
> we do not have a
Carsten Otte wrote:
But Dominic, it has nothing to do with a journaled file system. The fact
that you stopped the application and sync'd the file system (equivalent to
unmounting it) is what makes it work, not the file system implementation.
Wrong. Due to caching, as correctly described by Da
> It shouldn't be hard to create a tape (or something) that IPLs and
> restores. Should it?
Sure -- you *could* create such an animal. On the other hand, there's a
perfectly good one shipped with VM -- the IPLable DDR utility. DDR also
handles z/OS, VSE, Linux, TPF, and pretty much any other strea
Rob van der Heij wrote:
On 7/24/06, Adam Thornton <[EMAIL PROTECTED]> wrote:
It strikes me that file-level backups are generally a lot easier to
work with, and use less archival media.
File level backup is great for "oops backup" when you erased a few
files and want them back. I am not sure
Carsten Otte wrote:
As Alan said, it's a question of one system knowing what's happening on
the other system. There's no way that z/OS is going to be able to know
that the Linux system is "safe" (without some kind of automation on BOTH
systems to be able to signal same) so dumps taken from outsi
David Boyes wrote:
Why is everyone so hung up on volume backups?
It strikes me that file-level backups are generally a lot easier to
work with, and use less archival media.
Restore time in DR situations. Volume-level backups are a LOT faster to
restore, and you don't have to configure anything
rom: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of
Adam Thornton
Sent: Monday, July 24, 2006 2:48 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Bad Linux backups
-snip-
Why is everyone so hung up on volume backups?
It strikes me that file-level backups are generally a lot easier to
work
James Melin wrote:
This is more of a 'how do YOU do it ancillary question'...
Obviously to get a decent system backup from within Linux you should be in
single user mode, or even quiesced completely (if you're doing CDL volume
backups, for instance).
What are people doing to get a given image
Dominic Coulombe wrote:
On 7/24/06, Rob van der Heij <[EMAIL PROTECTED]> wrote:
Stop dreaming. Not even in theory - at least not my theory.
Hi,
I'm sorry, but we managed to do live backup of our systems without any
problem. We restored a lot of backup and all were recoverable without an
Stahr, Lea wrote:
I run SuSE SLES 8 under ZVM 5.1 in an IFL. The DASD are in a SAN that is
also accessed by ZOS. Backups are taken by ZOS using FDR full volume
copies on Saturday morning (low usage). When I restore a backup, it will
not boot. The backup and the restore have the same byte counts.
On 7/24/06, Jeremy Warren <[EMAIL PROTECTED]> wrote:
After reading the previous post though, does anyone know if that method
would correctly configure the boot sector.
The bootstrap uses a list of block numbers for the kernel, initrd etc.
When you restore a physical backup all these files go i
the rescue box?
TIA
jrw
Rob van der Heij <[EMAIL PROTECTED]>
Sent by: Linux on 390 Port
07/24/2006 04:23 PM
Please respond to
Linux on 390 Port
To
LINUX-390@VM.MARIST.EDU
cc
Subject
Re: [LINUX-390] Bad Linux backups
On 7/24/06, Stahr, Lea <[EMAIL PROTECTED]> wrote:
> The
Our robotics are controlled by Storagetek's software on our z/OS system; we do
not have a VM version. As far as APIs go, I have no idea.
Jon
What do you currently use to control your tape robotics?
We did a demo of how to use a client-server program to make Bacula
think it could drive your
On Jul 24, 2006, at 1:35 PM, David Boyes wrote:
Such an approach does require discipline to properly register what
you
have modified and to assure the copy of that customized file is held
somewhere.
Tripwire is a handy tool for this. Run it every night and have it
generate a list of changes in
> Such an approach does require discipline to properly register what you
> have modified and to assure the copy of that customized file is held
> somewhere.
Tripwire is a handy tool for this. Run it every night and have it
generate a list of changes in diff format. You can then turn that diff
into
On 7/24/06, Stahr, Lea <[EMAIL PROTECTED]> wrote:
These are standard image systems that I can clone from a master and have
in production in 2 hours. But what if its not standard? Then I have
customizations that are lost.
Such an approach does require discipline to properly register what you
ha
On Jul 24, 2006, at 12:47 PM, Rob van der Heij wrote:
On 7/24/06, Adam Thornton <[EMAIL PROTECTED]> wrote:
It strikes me that file-level backups are generally a lot easier to
work with, and use less archival media.
File level backup is great for "oops backup" when you erased a few
files and
Comments: What we have down is;
1. MANUAL JOB- SHUTDOWN LINUX 4 z/VM server-AFT 7pm.
2. DDR specific volumes thru an automated exec process.
3. MANUAL JOB- STARTLINUX 4 z/VM server- AFT 7pm.
We are halting to shut down the Linux servers thru the
The Linux Web interface.
We then perform; DDR o
390 Port [mailto:[EMAIL PROTECTED] On Behalf Of
Rob van der Heij
Sent: Monday, July 24, 2006 2:47 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Bad Linux backups
On 7/24/06, Adam Thornton <[EMAIL PROTECTED]> wrote:
> It strikes me that file-level backups are generally a lot easier to
&g
1 - 100 of 151 matches
Mail list logo
