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
point
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
SNIP
I would hope that anything that prevents the flashcopy
from starting could be reported
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 to
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
- 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
SNIP
I would hope that anything that prevents the flashcopy
from starting could be reported for example with a command
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
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 point that has me: how do you backup that location
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
why clustering an application is _at least_ two times more
expensive than not clustering it.
Mark Post
-Original Message-
From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of
John Summerfied
Sent: Thursday, July 27, 2006 8:37 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Bad Linux
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 is
] 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 regards
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. Invention
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
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
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
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
] 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
applications (probably
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 second image
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) and
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 the time
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 just
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 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
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.
snip
I don't understand how that addresses my concern.
Stahr, Lea wrote:
With clustering, you shut
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 Linux backups
Stahr, Lea wrote:
A piece of cake! Use
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
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. If
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
- 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 direct/raw I/O
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 interaction
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
- 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 devices e.g.
Shark
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
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
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 able
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 a
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
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
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 been
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
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
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
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 with
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 expect to have
Linux on 390 Port LINUX-390@VM.MARIST.EDU 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
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 state
- 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 LINUX-390@VM.MARIST.EDU wrote on 25.07.2006 11:23:02:
Alan Altmark wrote:
But, Carsten, the application
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 volume
copies
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
Administrator
Linux/Unix Team
630-753-5445
[EMAIL PROTECTED]
-Original Message-
From: Linux 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
@VM.MARIST.EDU
cc
Subject
Re: [LINUX-390] 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 Administrator
Linux/Unix Team
630-753-5445
[EMAIL PROTECTED]
-Original
What happens when you try to boot a restored system?
Jon
snip
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.
/snip
--
For LINUX-390
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 problem MAY be - I'm
guessing at this point so
]
-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
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 the
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 applications -- like DB/2
, 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
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 things
:31 AM
Subject
Re: Bad
Linux backups
Please respond
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
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
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
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:35 PM, David Boyes wrote:
Such an approach does require discipline
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
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 copy
@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 Administrator
Linux/Unix Team
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. Linux
support at
Can you send the messages that appear at boot time?
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.
We use OFFLINDR which runs on the z/OS side of our box.
- Original Message -
From: Stahr, Lea [EMAIL PROTECTED]
To: LINUX-390@VM.MARIST.EDU
Sent: Monday, July 24, 2006 9:31 AM
Subject: Bad Linux backups
I run SuSE SLES 8 under ZVM 5.1 in an IFL. The DASD are in a SAN that is
also
Subject
Re: Bad
Linux backups
Please respond to
Linux on 390 Port
On Monday, 07/24/2006 at 08:31 EST, Stahr, Lea
[EMAIL PROTECTED] 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
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).
To quote Alan Altmark: Nobody listens to me. Sigh.
One more time: Unless your Linux systems *are completely
Hi,
in *theory* you can do live backup of machines with journaled filesystems
(at least ext3) without any problem.
Linux will repair filesystems from journal after recovering your backups.
You need to be sure that there is no activity on the Linux machine, or you
might end with corrupted data.
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 ?
I never experimented such failure after
I shutdown my Linux system and perform a Zvm DDR volume backup. This is
a full image backup of every track on the pack.
[EMAIL PROTECTED] 07/24/06 9:02 AM
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
Re: Bad
Linux backups
Please respond to
Linux on 390 Port LINUX-390@VM.MARIST.EDU
Hi,
in *theory* you can do live backup of machines with journaled filesystems
(at least ext3
Bad Linux backups
07/24/2006 09:31
AM
Please respond to
Linux on 390 Port
[EMAIL PROTECTED]
ist.edu
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
On Monday 24 July 2006 16:06, Dominic Coulombe wrote:
in *theory* you can do live backup of machines with journaled filesystems
(at least ext3) without any problem.
Linux will repair filesystems from journal after recovering your backups.
No, that does not work, because the journal is backed
On 7/24/06, Dominic Coulombe [EMAIL PROTECTED] wrote:
in *theory* you can do live backup of machines with journaled filesystems
(at least ext3) without any problem.
Stop dreaming. Not even in theory - at least not my theory.
Linux will repair filesystems from journal after recovering your
On Mon, Jul 24, 2006 at 04:42:10PM +0200, Christian Borntraeger wrote:
On Monday 24 July 2006 16:06, Dominic Coulombe wrote:
in *theory* you can do live backup of machines with journaled filesystems
(at least ext3) without any problem.
Linux will repair filesystems from journal after
in *theory* you can do live backup of machines with journaled filesystems
(at least ext3) without any problem.
Rob van der Heij wrote:
Stop dreaming. Not even in theory - at least not my theory.
Well, that is what the device-mapper snapshot target is for:
a) make a snapshot, which is very
We have used DFDSS, DDR and PIPEDDR to backup VM volumes containing
Linux data. Inside the Linux systems, we use TSM for filelevel
restores.
Does Bacula support encryption of the data on tape?
/Tom Kern
/301-903-2211
From: David Boyes [EMAIL PROTECTED]
What is everyone using for Linux
For my SLES9 systems, I use 'SIGNAL SHUTDOWN FOR userx WITHIN 120' to
bring the servers down. For my older TurboLinux systems, I use SCIF to
enter a 'SHUTDOWN -H NOW' command at the server's virtual console. Once
all the Linus systems are down, I run the backups and use XAUTOLOG to
initiate each
On Monday, 07/24/2006 at 04:47 ZE2, Carsten Otte [EMAIL PROTECTED] wrote:
Well, that is what the device-mapper snapshot target is for:
a) make a snapshot, which is very fast because it does not actually
copy data
b) use dd to copy the snapshot to a backup dasd while writing to the
original
]
Sent by: Linux on 390 Port LINUX-390@VM.MARIST.EDU
07/24/2006 09:31 AM
Please respond to
Linux on 390 Port LINUX-390@VM.MARIST.EDU
To
LINUX-390@VM.MARIST.EDU
cc
Subject
[LINUX-390] Bad Linux backups
I run SuSE SLES 8 under ZVM 5.1 in an IFL. The DASD are in a SAN that is
also accessed by ZOS
On 7/24/06, Carsten Otte [EMAIL PROTECTED] wrote:
Well, that is what the device-mapper snapshot target is for:
a) make a snapshot, which is very fast because it does not actually
copy data
b) use dd to copy the snapshot to a backup dasd while writing to the
original disk
c) destroy the snapshot
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 any
problem. Even when data
Alan Altmark wrote:
And the point here is that you are getting *Linux* to create a consistent
backup. You are not backing up from the outside. Once Linux has created
the backup copy and unmounted it, only then are you free to copy the
backup disk at your leisure from the outside. At that
Rob van der Heij wrote:
I have looked in the past at options with LVM to suspend writing dirty
pages to disk, signal something outside Linux to take the physical
backup, and tell LVM to resume writing to disk. We did not implement
it because the process appeared a bit risky.
Nice idea that
Dominic Coulombe wrote:
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 any
problem. Even when data was stored on LVM volumes.
We stop our databases prior to do the backup, sync the filesystems, do
On 7/24/06, Dominic Coulombe [EMAIL PROTECTED] wrote:
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 any
problem. Even when data was stored on LVM volumes.
You've been lucky. That sometimes
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 ?
Linux performs in-memory caching to a much greater degree than most
operating systems to
On Monday, 07/24/2006 at 11:12 AST, Dominic Coulombe
[EMAIL PROTECTED] wrote:
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
any
problem. Even when data was stored on LVM volumes.
We stop our
On 7/24/06, Rob van der Heij [EMAIL PROTECTED] wrote:
You've been lucky. That sometimes happens.
It's hard to predict what damage occurs when the file system is
corrupt. I am not sure you would not even risk your database.
My apologies. Maybe I should not have abused your post to
We have used DFDSS, DDR and PIPEDDR to backup VM volumes containing
Linux data. Inside the Linux systems, we use TSM for filelevel
restores.
Does Bacula support encryption of the data on tape?
Recent versions of Bacula do (1.38.10 and higher) (using the crypto
support in OpenSSL, so can use
No need to shut down any application. If a database has a file state
at any point in time that it cannot recover from you are in deep
problems anyway (think of power outage). Databases are supposed to be
transactional. That also applies the the general case application.
The snapshot is atomic
On Monday, 07/24/2006 at 05:16 ZE2, Carsten Otte [EMAIL PROTECTED] wrote:
No need to shut down any application. If a database has a file state
at any point in time that it cannot recover from you are in deep
problems anyway (think of power outage). Databases are supposed to be
transactional.
David Boyes 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 ?
Linux performs in-memory caching to a much greater degree than most
Alan Altmark wrote:
If you *do* know how the application is implemented and fully understand
the relationships of all the files, then you can build customized backup
strategies.
You can just put all relevant files on a single dasd (for flashcopy)
or LVM volume (for dm-snapshot). Seems easy
On Monday, 07/24/2006 at 06:29 ZE2, Carsten Otte [EMAIL PROTECTED] wrote:
It is just extra paranoia. If you have an application that does not
start up anymore after a power outage (or snapshot backuprestore
which is the same from the application perspective), it is plain
broken. I just remeber
1 - 100 of 132 matches
Mail list logo
