Re: Bad Linux backups

[Post, Mark K]

I haven't finished all the replies to this thread, so I apologize if I'm
duplicating someone else's comment/question.  The thing that comes to my
mind is, what _exactly_ do you mean by "not boot."  Nothing happens at
all?  The system starts to come up, but can't find the root file system?
The root file system gets mounted, but things start dying for various
reasons?  The problem description needs to be filled in quite a bit
more.


Mark Post

-Original Message-
From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of
Stahr, Lea
Sent: Tuesday, July 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 Administrator
Linux/Unix Team

--
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

Re: MD5SUM

[Post, Mark K]

In the past when I've seen this result it was either bad RAM or a disk
starting to go bad.  If this really was an NFS mount, then you have the
added possibility of network packets being dropped or mangled.  In any
case, get out your worry beads.


Mark Post

-Original Message-
From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of
Scully, William P
Sent: Tuesday, July 25, 2006 4:09 PM
To: LINUX-390@VM.MARIST.EDU
Subject: MD5SUM

I'm -sure- these files did not change while I issued these commands.
What explains why MD5SUM's results differ?


([EMAIL PROTECTED]) /mnt/nfs/usilst22/sles10/iso > md5sum
SLES-10-CD-s390x-GMC-CD1.iso
5152b2aac4d371d64138171f0d47988e  SLES-10-CD-s390x-GMC-CD1.iso
([EMAIL PROTECTED]) /mnt/nfs/usilst22/sles10/iso > md5sum
SLES-10-CD-s390x-GMC-CD1.iso
7fe55d3fa52ff9c0db174706d8c83879  SLES-10-CD-s390x-GMC-CD1.iso
([EMAIL PROTECTED]) /mnt/nfs/usilst22/sles10/iso > md5sum
SLES-10-CD-s390x-GMC-CD2.iso
062e5d70d3d1db5622de5865ebffdb37  SLES-10-CD-s390x-GMC-CD2.iso
([EMAIL PROTECTED]) /mnt/nfs/usilst22/sles10/iso > md5sum
SLES-10-CD-s390x-GMC-CD2.iso
ddebbcacab520ef1db5804bb42fed629  SLES-10-CD-s390x-GMC-CD2.iso
([EMAIL PROTECTED]) /mnt/nfs/usilst22/sles10/iso >

--
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

Re: MD5SUM

[Adam Thornton]

On Jul 25, 2006, at 1:08 PM, Scully, William P wrote:


I'm -sure- these files did not change while I issued these commands.
What explains why MD5SUM's results differ?


NFS is giving you corrupt data?

That's really, really alarming.

Adam

--
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

MD5SUM

[Scully, William P]

I'm -sure- these files did not change while I issued these commands.
What explains why MD5SUM's results differ?


([EMAIL PROTECTED]) /mnt/nfs/usilst22/sles10/iso > md5sum
SLES-10-CD-s390x-GMC-CD1.iso
5152b2aac4d371d64138171f0d47988e  SLES-10-CD-s390x-GMC-CD1.iso
([EMAIL PROTECTED]) /mnt/nfs/usilst22/sles10/iso > md5sum
SLES-10-CD-s390x-GMC-CD1.iso
7fe55d3fa52ff9c0db174706d8c83879  SLES-10-CD-s390x-GMC-CD1.iso
([EMAIL PROTECTED]) /mnt/nfs/usilst22/sles10/iso > md5sum
SLES-10-CD-s390x-GMC-CD2.iso
062e5d70d3d1db5622de5865ebffdb37  SLES-10-CD-s390x-GMC-CD2.iso
([EMAIL PROTECTED]) /mnt/nfs/usilst22/sles10/iso > md5sum
SLES-10-CD-s390x-GMC-CD2.iso
ddebbcacab520ef1db5804bb42fed629  SLES-10-CD-s390x-GMC-CD2.iso
([EMAIL PROTECTED]) /mnt/nfs/usilst22/sles10/iso >

--
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

Re: One last call for chairs.....

[Spann, Elizebeth (Betsie)]

Martha,
I'll cover 9257 on Tues at 3pm, 9206 on Tues at 4:30pm, 9249 on Wed at
11am and 9266 on Wed at 3pm if no one else volunteer.  People will sure
get tired of seeing my face.
Betsie

-Original Message-
From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of
Martha McConaghy
Sent: Tuesday, July 25, 2006 11:39 AM
To: LINUX-390@VM.MARIST.EDU
Subject: One last call for chairs.

I'm sure you are all sick of these notes by now, so I really hope this
will
be the last one (at least for this SHARE).  We still have lots of good
sessions available that need the support of a good chairperson.  There
are
Linux sessions, there are VM sessionssomething for everyone.

So, if you are coming to Baltimore, pick a session and volunteer to
chair!
We'll buy you a drink at SCIDSppsssI mean the "post session,
pre-sleep group socialization and free food hour" (the new politically
correct SCIDS).

Martha

Mon  09:30a 9200 Open Computing and Linux
Mon  11:00a 9214 sudo - Secure and Convenient
Mon  03:00p 9127 z/VM for MVS Systems Programmers - Part 1 of 2
Mon  04:30p 9128 z/VM for MVS Systems Programmers - Part 2 of 2
Mon  04:30p 9241 Linux on zSeries - What to Do When There is a Problem

Tue  01:30p 9115 VM Performance Introduction
Tue  01:30p 9227 Linux for S/390 Installation Hands-On Lab - Part 1 of 3
Tue  03:00p 9228 Linux for S/390 Installation Hands-On Lab - Part 2 of 3
Tue  03:00p 9257 FCP Channel Virtualization in a Linux Environment
Tue  04:30p 9120 z/VM Installation - It's Installed, NOW What?
Tue  04:30p 9206 Cloning Linux Images under z/VM
Tue  04:30p 9229 Linux for S/390 Installation Hands-On Lab - Part 3 of 3

Wed  08:00a 9150 CSE for High Availability and System Management
Wed  08:00a 9267 Networking with Linux on zSeries - Part 1 of 2
Wed  09:30a 9117 Introduction to VMSES/E for z/VM
Wed  09:30a 9268 Networking with Linux on zSeries - Part 2 of 2
Wed  11:00a 9114 The z/VM Control Program (CP) - Under the Covers
Wed  11:00a 9118 Maintaining z/VM with VMSES/E - Hands-On Lab
Wed  11:00a 9249 Putting Linux for zSeries into Production: True Stories
Wed  01:30p 9278 Levanta - Managing Linux on z/VM (and Intel)
Wed  03:00p 9266 CPU Accounting for Linux Virtual Servers
Wed  06:00p 9281 Replacing Windows Servers with Linux

Thu  08:00a 9218 SuSE Linux Enterprise Server on zSeries for Flexible
  Business Solutions
Thu  09:30a 9252 Managing in a Mixed Linux and Windows Environment Lab -
  Part 1 of 2
Thu  11:00a 9253 Managing in a Mixed Linux and Windows Environment Lab -
  Part 2 of 2
Thu  01:30p 9135 VM Performance Internals - Why It Works That Way
Thu  01:30p 9261 (Dis)Honest TCO Analysis for Linux on zSeries
Thu  03:00p 9116 z/VM Simplified Network Configuration
Thu  03:00p 9224 Linux for S/390 System Management for the Mainframe
System
  Programmer - Part 1 of 2
Thu  04:30p 9225 Linux for S/390 System Management for the Mainframe
System
  Programmer - Part 2 of 2
Thu  04:30p 9275 Quick, Easy and Accurate Linux Deployment under z/VM
Thu  06:00p 9203 Teach your Penguins to Samba

Fri  08:00a 9136 Automated Linux Guest Monitoring on z/VM using PROP
Fri  08:00a 9209 Using Oracle Products on Linux for IBM's zSeries
Computing
  Environment
Fri  08:00a 9235 Turkeys and Penguins with no Bears, Oh My!
Fri  08:00a 9245 Linux on Intel InstallFest Hands-On Lab - Part 1 of 3
Fri  09:30a 9129 z/VM Security and Integrity
Fri  09:30a 9219 Easy z/VM Linux Guest System Deployment and Management
With
  IBM Director
Fri  09:30a 9246 Linux on Intel InstallFest Hands-On Lab - Part 2 of 3
Fri  11:00a 9247 Linux on Intel InstallFest Hands-On Lab - Part 3 of 3

--
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

Re: Bad Linux backups

[Alan Altmark]

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 track-by-track
> or use flashcopy?

You would have to presume track-by-track copy since flashcopy is an
optional feature and isn't available on all dasd brands.

Alan Altmark
z/VM Development
IBM Endicott

--
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

Re: Bad Linux backups

[Richard Pinion]

Sorry for asking this at such a late time but did you say the Linux guest was 
shutdown when the FDR backup jobs were run?

>>> [EMAIL PROTECTED] 7/25/2006 11:27 AM >>>
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 and by the applications. If I cannot restore my
application to a current state, then it's broken. And these were all
either EXT3 or REISERFS.

Lea Stahr
Sr. System Administrator
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 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 same filesystem for performance
reasons. 
 
> > Given how quickly this can change in
> > most real production systems, I don't have time or spare cycles to
try
> > to second-guess this, or make excuses when I miss backing up
something
> > important because someone didn't tell me that a change in data
location
> > was made.
> The point is, that data is considered stable at any time. That's a
> basic assumption which is true for ext3 and most applications. If you
> run a file system or an application that does have inconsistent data
> from time to time, you are in trouble in case of a power outage or
> system crash. I hope this is not the case in any production
environment.

With respect, I think this is an unrealistic expectation. I don't
control the application programmers at IBM or S/AP or Oracle, etc. If
you want to preach on proper application design to those folks, I'll
happily supply amens from the pews, but out here in the real world, it
ain't so, and it ain't gonna be so for a good long while (or at least
until the current crop of programmers re-discover all the development
validation model work that we did back in the 70s at PARC). 

We're faced with dealing with the world as it is, not as we'd like it to
be, and that reality contradicts your assertion. The filesystem contents
may be technically consistent, but if the applications disagree for
*any* reason, then that doesn't help us at all given what we have to
work with in the field. It's a goal to build toward, but for now, it's
just that: a goal. 

With *today's* applications, you need a guaranteed valid state both from
the application *and* filesystem standpoint, and to get that, you need
to coordinate backups from both inside and outside the guest if you want
to use facilities outside the guest to dump the data. How you do that
coordination is what I think you're trying to argue and there, your
points are extremely valid and useful; my point still stands that
without coordination between Linux and whatever else you're using,
you're not going to get the desired result, which is a no-exceptions way
to handle backup and restore of critical data in the most efficient
manner available. 

-- db

--
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

--
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

One last call for chairs.....

[Martha McConaghy]

I'm sure you are all sick of these notes by now, so I really hope this will
be the last one (at least for this SHARE).  We still have lots of good
sessions available that need the support of a good chairperson.  There are
Linux sessions, there are VM sessionssomething for everyone.

So, if you are coming to Baltimore, pick a session and volunteer to chair!
We'll buy you a drink at SCIDSppsssI mean the "post session,
pre-sleep group socialization and free food hour" (the new politically
correct SCIDS).

Martha

Mon  09:30a 9200 Open Computing and Linux
Mon  11:00a 9214 sudo - Secure and Convenient
Mon  03:00p 9127 z/VM for MVS Systems Programmers - Part 1 of 2
Mon  04:30p 9128 z/VM for MVS Systems Programmers - Part 2 of 2
Mon  04:30p 9241 Linux on zSeries - What to Do When There is a Problem

Tue  01:30p 9115 VM Performance Introduction
Tue  01:30p 9227 Linux for S/390 Installation Hands-On Lab - Part 1 of 3
Tue  03:00p 9228 Linux for S/390 Installation Hands-On Lab - Part 2 of 3
Tue  03:00p 9257 FCP Channel Virtualization in a Linux Environment
Tue  04:30p 9120 z/VM Installation - It's Installed, NOW What?
Tue  04:30p 9206 Cloning Linux Images under z/VM
Tue  04:30p 9229 Linux for S/390 Installation Hands-On Lab - Part 3 of 3

Wed  08:00a 9150 CSE for High Availability and System Management
Wed  08:00a 9267 Networking with Linux on zSeries - Part 1 of 2
Wed  09:30a 9117 Introduction to VMSES/E for z/VM
Wed  09:30a 9268 Networking with Linux on zSeries - Part 2 of 2
Wed  11:00a 9114 The z/VM Control Program (CP) - Under the Covers
Wed  11:00a 9118 Maintaining z/VM with VMSES/E - Hands-On Lab
Wed  11:00a 9249 Putting Linux for zSeries into Production: True Stories
Wed  01:30p 9278 Levanta - Managing Linux on z/VM (and Intel)
Wed  03:00p 9266 CPU Accounting for Linux Virtual Servers
Wed  06:00p 9281 Replacing Windows Servers with Linux

Thu  08:00a 9218 SuSE Linux Enterprise Server on zSeries for Flexible
  Business Solutions
Thu  09:30a 9252 Managing in a Mixed Linux and Windows Environment Lab -
  Part 1 of 2
Thu  11:00a 9253 Managing in a Mixed Linux and Windows Environment Lab -
  Part 2 of 2
Thu  01:30p 9135 VM Performance Internals - Why It Works That Way
Thu  01:30p 9261 (Dis)Honest TCO Analysis for Linux on zSeries
Thu  03:00p 9116 z/VM Simplified Network Configuration
Thu  03:00p 9224 Linux for S/390 System Management for the Mainframe System
  Programmer - Part 1 of 2
Thu  04:30p 9225 Linux for S/390 System Management for the Mainframe System
  Programmer - Part 2 of 2
Thu  04:30p 9275 Quick, Easy and Accurate Linux Deployment under z/VM
Thu  06:00p 9203 Teach your Penguins to Samba

Fri  08:00a 9136 Automated Linux Guest Monitoring on z/VM using PROP
Fri  08:00a 9209 Using Oracle Products on Linux for IBM's zSeries Computing
  Environment
Fri  08:00a 9235 Turkeys and Penguins with no Bears, Oh My!
Fri  08:00a 9245 Linux on Intel InstallFest Hands-On Lab - Part 1 of 3
Fri  09:30a 9129 z/VM Security and Integrity
Fri  09:30a 9219 Easy z/VM Linux Guest System Deployment and Management With
  IBM Director
Fri  09:30a 9246 Linux on Intel InstallFest Hands-On Lab - Part 2 of 3
Fri  11:00a 9247 Linux on Intel InstallFest Hands-On Lab - Part 3 of 3

--
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

Re: Fw: [LINUX-390] Bad Linux backups

[Mark Perry]

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. You
probably don't want to use it for all your data (for performance
reasons) but just for parts of the file system that are mostly
unmodified (like /etc). I would not use it for all data on the system
though.
With unionfs you can put a sparse R/W file system on top and have the
modified files reside on some private R/W disk. Because that R/W disk
still is a real file system, you could sort of run a file level backup
of that disk outside the unionfs. For a stable backup you would have
the issues we discussed in this thread though.
But you could even put a temporary R/W layer on top and divert all
writes to that layer, backup the (now frozen) first R/W layer, and
then merge any updates during the backup back into the first R/W
layer. This is neat because it's file level, but there may be a
performance issue when files need to be copied up.

Rob
--
Rob van der Heij
Velocity Software, Inc
http://velocitysoftware.com/

--
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


AFAIK unionfs copies the entire file when a change is made, unlike other
snapshot methods which only record the changes at a more granular level.
Thus as Rob mentions it is *very* useful for ascii text file changes
(/etc or source code etc.), but not for your DB files!

Mark

--
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

Re: Somewhat OT: YaST/YaST segfault

[McKown, John]

Never mind. The problem, if anybody is interested, was a corrupted YaST
source repository (packman) that I've been using successfully for quite
a while. I removed that source and everything works. Sorry to bother
everybody.

--
John McKown
Senior Systems Programmer
HealthMarkets
Keeping the Promise of Affordable Coverage
Administrative Services Group
Information Technology

This message (including any attachments) contains confidential
information intended for a specific individual and purpose, and its
content is protected by law.  If you are not the intended recipient, you
should delete this message and are hereby notified that any disclosure,
copying, or distribution of this transmission, or taking any action
based on it, is strictly prohibited. 

--
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

Re: Fw: [LINUX-390] Bad Linux backups

[Rob van der Heij]

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 use it for all your data (for performance
reasons) but just for parts of the file system that are mostly
unmodified (like /etc). I would not use it for all data on the system
though.
With unionfs you can put a sparse R/W file system on top and have the
modified files reside on some private R/W disk. Because that R/W disk
still is a real file system, you could sort of run a file level backup
of that disk outside the unionfs. For a stable backup you would have
the issues we discussed in this thread though.
But you could even put a temporary R/W layer on top and divert all
writes to that layer, backup the (now frozen) first R/W layer, and
then merge any updates during the backup back into the first R/W
layer. This is neat because it's file level, but there may be a
performance issue when files need to be copied up.

Rob
--
Rob van der Heij
Velocity Software, Inc
http://velocitysoftware.com/

--
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

Fw: [LINUX-390] Bad Linux backups

[John Campbell]

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
the local copy ONLY consist of changed files?  And wouldn't the local copy
(I'm not sure, UNIONFS _does_ handle having a R/W copy on a hard disk,
right?  Or am I talking through a sphincter again?) be in a form that could
be copied off VERY quickly because it'd be pretty darn small?

It seems, at least w/ z/VM, that this kind of trick would be almost *made*
for a virtualized environment.  I realize, though, that this discussion has
been about LPAR'd environments so I'm not sure what would be different.

Note that my experiences are currently limited to Intel and pSeries
(PowerPC) based systems...


John R. Campbell, Speaker to Machines (GNUrd)  (813) 356-5322 (t/l 697)
Adsumo ergo raptus sum
Why MacOS X?  Well, it's proof that making Unix user-friendly was much
easier than debugging Windows.
Red Hat Certified Engineer (#803004680310286, RHEL3)
- Forwarded by John Campbell/Tampa/IBM on 07/25/06 01:20 PM -

 Adam Thornton
 <[EMAIL PROTECTED]
 mine.net>  To
 Sent by: Linux on LINUX-390@VM.MARIST.EDU
 390 Port   cc
 <[EMAIL PROTECTED]
 IST.EDU>  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: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 diff format. You can then turn that diff
> into input to patch and deploy it as a .deb or .rpm.

Or, if you're feeling REALLY parsimonious, you can use Bacula in its
"verify" mode to do the same thing.

Adam

--
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

Re: Bad Linux backups

[David Boyes]

>  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 cluster members. In
that case, there is no exposure for the guest being shut down, because
the work and inflight transactions have been moved elsewhere in a
coordinated manner. 

Once the guest leaves the cluster, then the shutdown/logoff is trivial,
and you can do what you like with dumping the disks for that guest from
outside the guest.

David Boyes
Sine Nomine Associates

--
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

Re: Bad Linux backups

[Carsten Otte]

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 regards,
Carsten

--
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

Re: Bad Linux backups

[Stahr, Lea]

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.

Lea Stahr
Sr. System Administrator
Linux/Unix Team
630-753-5445
[EMAIL PROTECTED]
 

-Original 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.  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 64093
660-543-4285
660-580-0523
[EMAIL PROTECTED]

--
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

Re: Bad Linux backups

[J Leslie Turriff]

 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 64093
660-543-4285
660-580-0523
[EMAIL PROTECTED]

--
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

Re: Bad Linux backups

[Adam Thornton]

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 please?


That would utterly fail to surprise me.

ReiserFS and I don't get along.  Ext3, on the other hand, has rarely
bitten me without extreme provocation.

Adam

--
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

Re: Kernel update 2.6.5-7.267 s390x revisited

[Rich Smrcina]

Duh!  I thought these s390x images had SP3 installed, it turns out they
are only SP1.

Thanks, Gio.

Paul Giordano wrote:

SLES9 SP3 has mkinitrd-1.2-27.21.s390x.rpm

Paul Giordano
Technical Sales Specialist - Linux zSeries
e-business Solutions Technical Sales, Americas
(312) 529-1347
(630) 207-9435 (cell)

email: [EMAIL PROTECTED]

Check http://www.ibm.com/linux for the latest in Linux news and
information


--
Rich Smrcina
VM Assist, Inc.
Phone: 414-491-6001
Ans Service:  360-715-2467
rich.smrcina at vmassist.com

Catch the WAVV!  http://www.wavv.org
WAVV 2007 - Green Bay, WI - May 18-22, 2007

--
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

Re: SLES10 GA

[Post, Mark K]

Then that looks like a bug in the YaST installer, and should be reported
to Novell/SUSE.


Mark Post 

-Original Message-
From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of
Nico Potgieter
Sent: Tuesday, July 25, 2006 2:44 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: SLES10 GA

Hi

The message shows the http in front of the ip address  .. I just specify
the
ip address in the panel when going through the Yast install


Nico

On 7/24/06, Post, Mark K <[EMAIL PROTECTED]> wrote:
>
> It looks like you're specifying the installation server incorrectly.
> The error message shows an http:// string in the middle of the
directory
> tree.  When you specify the installation server, you don't want/need
to
> say http://ip.address, you just need to provide the IP address.
>
>
> Mark Post
>
> -Original Message-
> From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of
> Nico Potgieter
> Sent: Monday, July 24, 2006 9:30 AM
> To: LINUX-390@VM.MARIST.EDU
> Subject: Re: SLES10 GA
>
> Hi All
>
> I have a problem installing SLES10 under Hercules ..
>
> I use Hercules 3.02 and when I need to specify the partitioning and
> software
> selection I get a message that say
> No *catalog found at
> http://x.x.x.x/xx/DVD1/"
> and "ERROR: No** proposal".
>
> Same problem occurs using Windows or SLED10 as driver system ..
>
> I initially downloaded the 4 cd's and also had the problem .. I then
> downloaded the DVD version but alas still the same problem
>
> Any ideas how to bypass this . ??
>
> Thanks
>
> Nico

--
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

Re: Kernel update 2.6.5-7.267 s390x revisited

[Paul Giordano]

SLES9 SP3 has mkinitrd-1.2-27.21.s390x.rpm

Paul Giordano
Technical Sales Specialist - Linux zSeries
e-business Solutions Technical Sales, Americas
(312) 529-1347
(630) 207-9435 (cell)

email: [EMAIL PROTECTED]

Check http://www.ibm.com/linux for the latest in Linux news and
information



Rich Smrcina <[EMAIL PROTECTED]>
Sent by: Linux on 390 Port 
07/25/2006 07:42 AM
Please respond to
Linux on 390 Port 


To
LINUX-390@VM.MARIST.EDU
cc

Subject
Kernel update 2.6.5-7.267 s390x revisited






OK, now that the IPL issue is worked out, when I try to install the RPM
for this kernel it tells me:

error: Failed dependencies:
 mkinitrd >= 1.2 is needed by kernel-s390x-2.6.5-7.267

I have an existing RPM database entry for mkinitrd-1.0-199.61.  There
doesn't appear to be an RPM available on the SUSE site for mkinitrd.

Thanks.
--
Rich Smrcina
VM Assist, Inc.
Phone: 414-491-6001
Ans Service:  360-715-2467
rich.smrcina at vmassist.com

Catch the WAVV!  http://www.wavv.org
WAVV 2007 - Green Bay, WI - May 18-22, 2007

--
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

Somewhat OT: YaST/YaST segfault

[McKown, John]

This is somewhat OT because: (1) this is not Linux per-se; (2) the
problem is not on a zSeries. Please ignore (or flame me off-list, if
necessary) if I am being a pest.

Has anybody out there had yast and/or yast2 do a "segfault" when you
select software to install? This happens both with the character mode
yast and GUI yast2. I get a listing of possible packages. I can select
any number of packages. When I do the "next" function, I get the
segfault. The segfault is in SlideShow.ycp, which is apparently some
Perl code. I thought that I might have a corrupted rpm database, so I
first tried "rpm --rebuilddb". No joy. I then renamed the /var/lib/rpm
subdirectory and created an empty one, followed by "rpm --initdb". Still
no joy, same problem. I can use RPM, just not yast/yast2. Which is a
real pain.

--
John McKown
Senior Systems Programmer
HealthMarkets
Keeping the Promise of Affordable Coverage
Administrative Services Group
Information Technology

This message (including any attachments) contains confidential
information intended for a specific individual and purpose, and its
content is protected by law.  If you are not the intended recipient, you
should delete this message and are hereby notified that any disclosure,
copying, or distribution of this transmission, or taking any action
based on it, is strictly prohibited. 
 

--
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

Re: Bad Linux backups

[Carsten Otte]

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

--
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

Re: Bad Linux backups

[Carsten Otte]

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 backup it is a good idea to do so because of the
reasons discussed in this thread.
Backing up a running system involves trust in the application and the
file system.

with kind regards,
Carsten

--
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

Re: Bad Linux backups

[James Melin]

Not even remotely close to what I was thinking Greater minds than mine 
any ideas?




 "Stahr, Lea" <[EMAIL PROTECTED]>
 Sent by: Linux on 390 Port
   
   To
 
LINUX-390@VM.MARIST.EDU

   cc
 07/25/2006 09:31 AM

  Subject
 Re: Bad 
Linux backups
Please respond to
   Linux on 390 Port 








All systems are clones of an original, so all device assignments in
Linux are the same across systems. Here is my ZIPL and FSTAB. I cannot
generate the error messages as I had to re-clone the system and get it
back online.
I was receiving errors on different filesystems and I ran FSCK's on
them, then received this abend in the kernel:
I restored the Linux volumes from the backup tapes and it will not come
up all the way. I switched tape sets with the same result. The kernel is
abending.



Unable to handle kernel pointer dereference at virtual kernel address
0c80

Oops: 0010

CPU:0Not tainted

Process find (pid: 497, task: 09804000, ksp: 09805940)

Krnl PSW : 07081000 8d020b96

Krnl GPRS: 09709a80 fffd2348 0c7fff79 6003

   0c5c7570 d140 09a3e779 09a34300

   b814a409 00643c03 0d14 6004

   09a414b0 8d020864 8d020a54 09805c98

Krnl ACRS:    

   0001   

      

      

Krnl Code: d2 ff 40 00 20 00 41 40 41 00 41 20 21 00 a7 16 ff f9 a7 15

Call Trace:

 <1>Unable to handle kernel pointer dereference at virtual kernel
address 18

00

Oops: 0010

CPU:0Not tainted

Process find (pid: 497, task: 09804000, ksp: 09805940)

Krnl PSW : 07082000 800765aa

Krnl GPRS: 00a83f80 0002 1800 00c0
**

[EMAIL PROTECTED]:~> cd /etc
[EMAIL PROTECTED]:/etc> cat zipl.conf
# Generated by YaST2
[defaultboot]
default=ipl

[ipl]
target=/boot/zipl
image=/boot/kernel/image
ramdisk=/boot/initrd
parameters="dasd=0201-020f,0300-030f root=/dev/dasda1"

[dumpdasd]
target=/boot/zipl
dumpto=/dev/dasd??

[dumptape]
target=/boot/zipl
dumpto=/dev/rtibm0
[EMAIL PROTECTED]:/etc> cat fstab
/dev/dasda1  /reiserfs   defaults
1 1
/dev/dasda2  /tmp ext2   defaults
1 2
/dev/dasdb1  /usr reiserfs   defaults
1 2
/dev/dasdd1  /var reiserfs   defaults
1 2
/dev/dasde1  /homereiserfs   defaults
1 2
/dev/dasdf1  /user2   reiserfs   defaults
1 2
/dev/dasdc1  swap swap   pri=42
0 0
/dev/dasdd2  /opt/IBM reiserfs   defaults
0 2
devpts   /dev/pts devpts mode=0620,gid=5
0 0
proc /procproc   defaults
0 0
[EMAIL PROTECTED]:/etc>

Lea Stahr
Sr. System Administrator
Linux/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 problem MAY be - I'm
guessing at this point so I'd like you to fill in some blanks

Are your Linux guests device number consistent across Linuxen? As in,
/dev/dasdb1 is always device 601 and /{root file system} is 600, etc? Or
is it
on Linux A it's 600,601,602 etc and Linux B it's 400,401,402 etc?  What
does your zipl.conf look like?

Also can you post any messages you get when you try to boot them?





 "Stahr, Lea" <[EMAIL PROTECTED]>
 Sent by: Linux on 390 Port
 
To

LINUX-390@VM.MARIST.EDU

cc
 07/25/2006 07:17 AM

Subject
 Re:
Bad Linux backups
Please respond to
   Linux on 390 Port 








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 Message-
From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of
John Summerfied
Sent: Monday, July 24, 2006 6:0

Re: Bad Linux backups

[Carsten Otte]

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 like data and logs on the same filesystem for performance
> reasons.
Yup, I know that "everything on a single dasd" is a strong limitation.
But since flashcopy does'nt allow to snapshot multiple volumes at a
time, it is the only way to get a snapshot of all data involved from
outside the system that I know of.

>> The point is, that data is considered stable at any time. That's a
>> basic assumption which is true for ext3 and most applications. If you
>> run a file system or an application that does have inconsistent data
>> from time to time, you are in trouble in case of a power outage or
>> system crash. I hope this is not the case in any production
> environment.
>
> With respect, I think this is an unrealistic expectation. I don't
> control the application programmers at IBM or S/AP or Oracle, etc. If
> you want to preach on proper application design to those folks, I'll
> happily supply amens from the pews, but out here in the real world, it
> ain't so, and it ain't gonna be so for a good long while (or at least
> until the current crop of programmers re-discover all the development
> validation model work that we did back in the 70s at PARC).
It depends on the type of application. For a fileserver or static
webserver for example, this requirement is fullfilled. For more
complex servers, it can get nasty.

> With *today's* applications, you need a guaranteed valid state both from
> the application *and* filesystem standpoint, and to get that, you need
> to coordinate backups from both inside and outside the guest if you want
> to use facilities outside the guest to dump the data. How you do that
> coordination is what I think you're trying to argue and there, your
> points are extremely valid and useful; my point still stands that
> without coordination between Linux and whatever else you're using,
> you're not going to get the desired result, which is a no-exceptions way
> to handle backup and restore of critical data in the most efficient
> manner available.
Some people seem to trust today's applications more, for example the
developers of dm-snapshot and the users of per-file backup soloutions
like tsm which usually also run while the application is active.


with kind regards,
Carsten

--
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

Re: Bad Linux backups

[Fargusson.Alan]

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.

-Original Message-
From: Linux on 390 Port [mailto:[EMAIL PROTECTED] Behalf Of
Stahr, Lea
Sent: Tuesday, July 25, 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 and by the applications. If I cannot restore my
application to a current state, then it's broken. And these were all
either EXT3 or REISERFS.

Lea Stahr
Sr. System Administrator
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 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 same filesystem for performance
reasons. 
 
> > Given how quickly this can change in
> > most real production systems, I don't have time or spare cycles to
try
> > to second-guess this, or make excuses when I miss backing up
something
> > important because someone didn't tell me that a change in data
location
> > was made.
> The point is, that data is considered stable at any time. That's a
> basic assumption which is true for ext3 and most applications. If you
> run a file system or an application that does have inconsistent data
> from time to time, you are in trouble in case of a power outage or
> system crash. I hope this is not the case in any production
environment.

With respect, I think this is an unrealistic expectation. I don't
control the application programmers at IBM or S/AP or Oracle, etc. If
you want to preach on proper application design to those folks, I'll
happily supply amens from the pews, but out here in the real world, it
ain't so, and it ain't gonna be so for a good long while (or at least
until the current crop of programmers re-discover all the development
validation model work that we did back in the 70s at PARC). 

We're faced with dealing with the world as it is, not as we'd like it to
be, and that reality contradicts your assertion. The filesystem contents
may be technically consistent, but if the applications disagree for
*any* reason, then that doesn't help us at all given what we have to
work with in the field. It's a goal to build toward, but for now, it's
just that: a goal. 

With *today's* applications, you need a guaranteed valid state both from
the application *and* filesystem standpoint, and to get that, you need
to coordinate backups from both inside and outside the guest if you want
to use facilities outside the guest to dump the data. How you do that
coordination is what I think you're trying to argue and there, your
points are extremely valid and useful; my point still stands that
without coordination between Linux and whatever else you're using,
you're not going to get the desired result, which is a no-exceptions way
to handle backup and restore of critical data in the most efficient
manner available. 

-- db

--
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

--
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

Re: Bad Linux backups

[Stahr, Lea]

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 and by the applications. If I cannot restore my
application to a current state, then it's broken. And these were all
either EXT3 or REISERFS.

Lea Stahr
Sr. System Administrator
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 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 same filesystem for performance
reasons. 
 
> > Given how quickly this can change in
> > most real production systems, I don't have time or spare cycles to
try
> > to second-guess this, or make excuses when I miss backing up
something
> > important because someone didn't tell me that a change in data
location
> > was made.
> The point is, that data is considered stable at any time. That's a
> basic assumption which is true for ext3 and most applications. If you
> run a file system or an application that does have inconsistent data
> from time to time, you are in trouble in case of a power outage or
> system crash. I hope this is not the case in any production
environment.

With respect, I think this is an unrealistic expectation. I don't
control the application programmers at IBM or S/AP or Oracle, etc. If
you want to preach on proper application design to those folks, I'll
happily supply amens from the pews, but out here in the real world, it
ain't so, and it ain't gonna be so for a good long while (or at least
until the current crop of programmers re-discover all the development
validation model work that we did back in the 70s at PARC). 

We're faced with dealing with the world as it is, not as we'd like it to
be, and that reality contradicts your assertion. The filesystem contents
may be technically consistent, but if the applications disagree for
*any* reason, then that doesn't help us at all given what we have to
work with in the field. It's a goal to build toward, but for now, it's
just that: a goal. 

With *today's* applications, you need a guaranteed valid state both from
the application *and* filesystem standpoint, and to get that, you need
to coordinate backups from both inside and outside the guest if you want
to use facilities outside the guest to dump the data. How you do that
coordination is what I think you're trying to argue and there, your
points are extremely valid and useful; my point still stands that
without coordination between Linux and whatever else you're using,
you're not going to get the desired result, which is a no-exceptions way
to handle backup and restore of critical data in the most efficient
manner available. 

-- db

--
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

Re: Bad Linux backups

[David Boyes]

> 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 same filesystem for performance
reasons. 
 
> > Given how quickly this can change in
> > most real production systems, I don't have time or spare cycles to
try
> > to second-guess this, or make excuses when I miss backing up
something
> > important because someone didn't tell me that a change in data
location
> > was made.
> The point is, that data is considered stable at any time. That's a
> basic assumption which is true for ext3 and most applications. If you
> run a file system or an application that does have inconsistent data
> from time to time, you are in trouble in case of a power outage or
> system crash. I hope this is not the case in any production
environment.

With respect, I think this is an unrealistic expectation. I don't
control the application programmers at IBM or S/AP or Oracle, etc. If
you want to preach on proper application design to those folks, I'll
happily supply amens from the pews, but out here in the real world, it
ain't so, and it ain't gonna be so for a good long while (or at least
until the current crop of programmers re-discover all the development
validation model work that we did back in the 70s at PARC). 

We're faced with dealing with the world as it is, not as we'd like it to
be, and that reality contradicts your assertion. The filesystem contents
may be technically consistent, but if the applications disagree for
*any* reason, then that doesn't help us at all given what we have to
work with in the field. It's a goal to build toward, but for now, it's
just that: a goal. 

With *today's* applications, you need a guaranteed valid state both from
the application *and* filesystem standpoint, and to get that, you need
to coordinate backups from both inside and outside the guest if you want
to use facilities outside the guest to dump the data. How you do that
coordination is what I think you're trying to argue and there, your
points are extremely valid and useful; my point still stands that
without coordination between Linux and whatever else you're using,
you're not going to get the desired result, which is a no-exceptions way
to handle backup and restore of critical data in the most efficient
manner available. 

-- db

--
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

Re: Bad Linux backups

[Stahr, Lea]

Here is my FDR restore job step for a volume:

//DISK5DD UNIT=SYSALLDA,VOL=SER=VML061,DISP=OLD
//TAPE5DD DSN=DRP.OPR.SOV.M3DMP.VML061(-3),
//SUBSYS=SOV,DISP=SHR
//SYSPRIN5 DD SYSOUT=*

Lea Stahr
Sr. System Administrator
Linux/Unix Team
630-753-5445
[EMAIL PROTECTED]
 

-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 issue.








"Stahr, Lea" <[EMAIL PROTECTED]>
Sent by: Linux on 390 Port 
07/25/2006 08:17 AM
Please respond to
Linux on 390 Port 


To
LINUX-390@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 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 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 MainLine Systems tells me that he has seen this before at
> other customers. What is everyone using for Linux under ZVM backups?
> HELP! My backups are no good!

What do the FDR suppliers say?


--

Cheers
John

-- spambait
[EMAIL PROTECTED]  [EMAIL PROTECTED]
Tourist pics
http://portgeographe.environmentaldisasters.cds.merseine.nu/

do not reply off-list

--
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


--
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

Re: Bad Linux backups

[Stahr, Lea]

All systems are clones of an original, so all device assignments in
Linux are the same across systems. Here is my ZIPL and FSTAB. I cannot
generate the error messages as I had to re-clone the system and get it
back online.
I was receiving errors on different filesystems and I ran FSCK's on
them, then received this abend in the kernel:
I restored the Linux volumes from the backup tapes and it will not come
up all the way. I switched tape sets with the same result. The kernel is
abending.



Unable to handle kernel pointer dereference at virtual kernel address
0c80

Oops: 0010

CPU:0Not tainted

Process find (pid: 497, task: 09804000, ksp: 09805940)

Krnl PSW : 07081000 8d020b96

Krnl GPRS: 09709a80 fffd2348 0c7fff79 6003

   0c5c7570 d140 09a3e779 09a34300

   b814a409 00643c03 0d14 6004

   09a414b0 8d020864 8d020a54 09805c98

Krnl ACRS:    

   0001   

      

      

Krnl Code: d2 ff 40 00 20 00 41 40 41 00 41 20 21 00 a7 16 ff f9 a7 15

Call Trace:

 <1>Unable to handle kernel pointer dereference at virtual kernel
address 18

00

Oops: 0010

CPU:0Not tainted

Process find (pid: 497, task: 09804000, ksp: 09805940)

Krnl PSW : 07082000 800765aa

Krnl GPRS: 00a83f80 0002 1800 00c0
**

[EMAIL PROTECTED]:~> cd /etc
[EMAIL PROTECTED]:/etc> cat zipl.conf
# Generated by YaST2
[defaultboot]
default=ipl

[ipl]
target=/boot/zipl
image=/boot/kernel/image
ramdisk=/boot/initrd
parameters="dasd=0201-020f,0300-030f root=/dev/dasda1"

[dumpdasd]
target=/boot/zipl
dumpto=/dev/dasd??

[dumptape]
target=/boot/zipl
dumpto=/dev/rtibm0
[EMAIL PROTECTED]:/etc> cat fstab
/dev/dasda1  /reiserfs   defaults
1 1
/dev/dasda2  /tmp ext2   defaults
1 2
/dev/dasdb1  /usr reiserfs   defaults
1 2
/dev/dasdd1  /var reiserfs   defaults
1 2
/dev/dasde1  /homereiserfs   defaults
1 2
/dev/dasdf1  /user2   reiserfs   defaults
1 2
/dev/dasdc1  swap swap   pri=42
0 0
/dev/dasdd2  /opt/IBM reiserfs   defaults
0 2 
devpts   /dev/pts devpts mode=0620,gid=5
0 0
proc /procproc   defaults
0 0
[EMAIL PROTECTED]:/etc>

Lea Stahr
Sr. System Administrator
Linux/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 problem MAY be - I'm
guessing at this point so I'd like you to fill in some blanks

Are your Linux guests device number consistent across Linuxen? As in,
/dev/dasdb1 is always device 601 and /{root file system} is 600, etc? Or
is it
on Linux A it's 600,601,602 etc and Linux B it's 400,401,402 etc?  What
does your zipl.conf look like?

Also can you post any messages you get when you try to boot them?





 "Stahr, Lea" <[EMAIL PROTECTED]>
 Sent by: Linux on 390 Port
 
To
 
LINUX-390@VM.MARIST.EDU
 
cc
 07/25/2006 07:17 AM
 
Subject
 Re:
Bad Linux backups
Please respond to
   Linux on 390 Port 








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 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 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 MainLine Systems tells me that he has seen this before at
> other customers. What is everyone using for Linux under ZVM backups?
> HELP! My backups are no good!

What do the FDR suppliers say?


--

Cheers
John

-- spambait
[EMAIL PROTECTED]  [EMAIL PROTECTED]
Tourist pics
http://portgeographe.environmentaldisasters.cds.merseine.nu/

do not reply off-list

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTEC

Re: Bad Linux backups

[Jon Brock]

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 / 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

Re: Bad Linux backups

[Jeremy Warren]

Did you try the fdr from cyl / to cyl options on the backups?  This sounds
eerily familar to our label issue.








"Stahr, Lea" <[EMAIL PROTECTED]>
Sent by: Linux on 390 Port 
07/25/2006 08:17 AM
Please respond to
Linux on 390 Port 


To
LINUX-390@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 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 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 MainLine Systems tells me that he has seen this before at
> other customers. What is everyone using for Linux under ZVM backups?
> HELP! My backups are no good!

What do the FDR suppliers say?


--

Cheers
John

-- spambait
[EMAIL PROTECTED]  [EMAIL PROTECTED]
Tourist pics
http://portgeographe.environmentaldisasters.cds.merseine.nu/

do not reply off-list

--
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


--
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

Re: Bad Linux backups

[James Melin]

I think I might have an idea as to where your problem MAY be - I'm guessing at 
this point so I'd like you to fill in some blanks

Are your Linux guests device number consistent across Linuxen? As in, 
/dev/dasdb1 is always device 601 and /{root file system} is 600, etc? Or is it
on Linux A it's 600,601,602 etc and Linux B it's 400,401,402 etc?  What does 
your zipl.conf look like?

Also can you post any messages you get when you try to boot them?





 "Stahr, Lea" <[EMAIL PROTECTED]>
 Sent by: Linux on 390 Port
   
   To
 
LINUX-390@VM.MARIST.EDU

   cc
 07/25/2006 07:17 AM

  Subject
 Re: Bad 
Linux backups
Please respond to
   Linux on 390 Port 








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 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 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 MainLine Systems tells me that he has seen this before at
> other customers. What is everyone using for Linux under ZVM backups?
> HELP! My backups are no good!

What do the FDR suppliers say?


--

Cheers
John

-- spambait
[EMAIL PROTECTED]  [EMAIL PROTECTED]
Tourist pics
http://portgeographe.environmentaldisasters.cds.merseine.nu/

do not reply off-list

--
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

--
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

Kernel update 2.6.5-7.267 s390x revisited

[Rich Smrcina]

OK, now that the IPL issue is worked out, when I try to install the RPM
for this kernel it tells me:

error: Failed dependencies:
mkinitrd >= 1.2 is needed by kernel-s390x-2.6.5-7.267

I have an existing RPM database entry for mkinitrd-1.0-199.61.  There
doesn't appear to be an RPM available on the SUSE site for mkinitrd.

Thanks.
--
Rich Smrcina
VM Assist, Inc.
Phone: 414-491-6001
Ans Service:  360-715-2467
rich.smrcina at vmassist.com

Catch the WAVV!  http://www.wavv.org
WAVV 2007 - Green Bay, WI - May 18-22, 2007

--
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

Re: Bad Linux backups

[Carsten Otte]

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

--
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

Re: Bad Linux backups

[Stahr, Lea]

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 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 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 MainLine Systems tells me that he has seen this before at
> other customers. What is everyone using for Linux under ZVM backups?
> HELP! My backups are no good!

What do the FDR suppliers say?


--

Cheers
John

-- spambait
[EMAIL PROTECTED]  [EMAIL PROTECTED]
Tourist pics
http://portgeographe.environmentaldisasters.cds.merseine.nu/

do not reply off-list

--
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

Re: Bad Linux backups

[Mark Perry]

- 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, 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 application is only
> > > terminated when the system is shut down, a live backup of the disk
> would
> > > have no effect.  I mean, it would restore and run just fine, but be
> > > running with old data.
> > Well, backups are always about using old data in case of recovery as
> > far as I can see. Using an application that saves important data only
> > on shutdown in a mission critical environment is very dangerous
> > regardless of the backup soloution.
> >
> 
> Well, I guess the question is whether you relaunch from a deterministic
> starting point, or whether your starting point is arbitrary. You are
> arguing
> along the line that one shouldn't be afraid about discretionary starting
> points, as anecdotal knowledge suggests that it will usually work anyhow.
> Alan is arguing that customers would typically not want to bet on
> arbitraryness and we shouldn't paper the risks doing so but clearly
> articulate
> it. Either you have application support/awareness for live backups, or the
> result by definition *is* arbitrary - unless you can guarantee a well
> defined
> transactional state (as viewed by an aplication) which we currently lack
> file
> system or more generally operating system support for.
> 

Your articulation of the English language is quite exquisite :-)

> > > I can jump up and down and stamp my feet, claiming that the application
> is
> > > broken, but that doesn't make it so.
> 
> I fully support Alan's view.

Whilst the application may not be "broken", it is most definitely unsuitable 
for use within an Enterprise. The robustness of an application, and its ability 
to recover from unexpected system errors without *any* data loss (Power outages 
etc.) is of paramount importance.

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 
performance price, though Hans Reiser did claim that the new Resier4 FS will 
journal data without the previous performance penalties.

Mark

--
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

Re: Bad Linux backups

[Carsten Otte]

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 to
> be hardened on persistent storage, hence shutting down the application
> prior to backup/archive.
True, but this is a general restricion of live backups (e.g. file
level backup). Not specific to full volume snapshot backup.

cheers,
Carsten

--
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

Re: Bad Linux backups

[Carsten Otte]

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 that
> outside system is -- to get something usable.
I am well aware that there are other opinions. I am just trying to
explain why those are wrong.

> LVM snapshot is neat and cool, but it doesn't help in this case if the
> outside system doesn't know it's happening or what data can be
> considered "stable" to back up.
LVM also does'nt know about filesystem interna, it just grabs a copy
of the entire volume at a given point in time. Like flashcopy. Also,
in Linux layering, LVM is "behind" the page cache (where the physical
disk is) just like the flashcopy mechanism. Therefore, dm-snapshot and
flashcopy are two sides of the same medal once the entire filesystem
is on a single dasd.

> Given how quickly this can change in
> most real production systems, I don't have time or spare cycles to try
> to second-guess this, or make excuses when I miss backing up something
> important because someone didn't tell me that a change in data location
> was made.
The point is, that data is considered stable at any time. That's a
basic assumption which is true for ext3 and most applications. If you
run a file system or an application that does have inconsistent data
from time to time, you are in trouble in case of a power outage or
system crash. I hope this is not the case in any production environment.

>> z/OS does not need to know what Linux is doing when the setup ensures
>> consistent on-disk data at all times.
> Clearly, from the live example that started this discussion, this is not
> the case.
I agree, it does'nt work in the current live example with the current
setup. But the list is suggesting to "never do flashcopy backups from
outside a running linux guest". This suggestion is wrong.

> You are talking about something that happens INSIDE the Linux guest,
> coordinating things on the Linux side to produce a copy of the data that
> z/OS can dump in a consistent manner. Given that, then z/OS darn well
> *better* know that the Linux system has done this, or the data you are
> backing up is demonstratably crap.
It can be demonstratably crap, or a reliably usable backup. If done
proper, one can be sure to get the second one.

regards,
Carsten

--
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

Re: Bad Linux backups

[Ingo Adlung]

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 (working
as
> > designed according to the vendor).  Since the application is only
> > terminated when the system is shut down, a live backup of the disk
would
> > have no effect.  I mean, it would restore and run just fine, but be
> > running with old data.
> Well, backups are always about using old data in case of recovery as
> far as I can see. Using an application that saves important data only
> on shutdown in a mission critical environment is very dangerous
> regardless of the backup soloution.
>

Well, I guess the question is whether you relaunch from a deterministic
starting point, or whether your starting point is arbitrary. You are
arguing
along the line that one shouldn't be afraid about discretionary starting
points, as anecdotal knowledge suggests that it will usually work anyhow.
Alan is arguing that customers would typically not want to bet on
arbitraryness and we shouldn't paper the risks doing so but clearly
articulate
it. Either you have application support/awareness for live backups, or the
result by definition *is* arbitrary - unless you can guarantee a well
defined
transactional state (as viewed by an aplication) which we currently lack
file
system or more generally operating system support for.

> > I can jump up and down and stamp my feet, claiming that the application
is
> > broken, but that doesn't make it so.

I fully support Alan's view.

> What application (Server Application on Linux) acts like you claim?
>
> regards,
> Carsten
>
> --
> 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

Ingo

--
Ingo Adlung,
STSM, System z Linux and Virtualization Architecture
mail: [EMAIL PROTECTED] - phone: +49-7031-16-4263

--
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

Re: Bad Linux backups

[Ingo Adlung]

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 Summerfied wrote:
> > syslogd's mark message has nothing to do with caching.
> >
> > According to its man page, "sync forces changed blocks to disk, updates
> > the super block."
> >
> > If you don't believe (or trust) that, then "mount -o remount" is your
> > friend.
> You missed my point: From the file system perspective, a snapshot of
> an ext3 is _always_ consistent. No need to do remount, sync, shutdown
> of application or shutdown of the entire system.
>
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 to
be hardened on persistent storage, hence shutting down the application
prior to backup/archive.

> regards,
> Carsten
>
> --
> 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

Ingo

--
Ingo Adlung,
STSM, System z Linux and Virtualization Architecture
mail: [EMAIL PROTECTED] - phone: +49-7031-16-4263

--
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

Re: Bad Linux backups

[Carsten Otte]

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 a usable
> backup.
>> That is a wrong assumption, I clearly disagree with it. If planned
>> proper, and I agree that there are lots of things one can do wrong
>> when planning the setup, physical backup of mounted and actively used
>> volumes _is_ reliable.
>
> But you are making assumptions about the applications, something I am not
> willing to do quite yet.  If a database update requires a change to the
> data file, the index file, and the log file, how do you (from the outside)
> know that all changes have been made and that it is safe to copy them? And
> that another transaction has not started?
As for the first part of the question: doing "sync" after the update
ensures that everything relevant has been flushed out to disk proper.
If another transaction has been started, fine. I expect the database
to be capable of rolling back the transaction after restore. That
brings things to the same situation as if I was doing the backup
before the transaction.

> From my days as a database application developer, a the transaction
> journal was meant to be replayed against a copy of the database as it
> existed at when the database was started, not replayed against a more
> current snapshot.  I.e. today's log is replayed against last night's
> backup.  And the transaction log is specifically NOT placed on the same
> device as the data itself.  In Linux terms, I guess that means don't place
> it in the same filesystem since that's the smallest consistent unit of
> data, right?  If you lose the data device, you haven't lost a whole day's
> worth of transactions.  (Maybe database technology no longer requires such
> precautions?)
When using snapshots for backup purposes, you would obviously need a
snapshot of both journal and data at the same time. Therefore you
either need to use dm-snapshot if you have data and log on different
devices, or you need to put both on the same device if you want to use
flashcopy.

> So I'll admit that I'm obviously not "getting it".  If you would summarize
> the steps needed to allow a reliable, usable, uncoordinated live backup of
> Linux volumes, I for one would sincerely appreciate it.  How do you
> integrate them into your server?  How do you automate the process?  Right
> now I'm a fan of SIGNAL SHUTDOWN, FLASHCOPY, XAUTOLOG, but that's just
> me...
Please don't get upset, I am doing my best to explain the situation.
You need:
- the capability of getting a consistent snapshot of all data relevant
to a) the file system _and_ b) the application. If the file system or
the data set relevant to the application spans multiple volumes, you
need the capability to snapshot all volumes at the very same time. The
easy way to fullfill this requirement is to use just a single file
system - which can span multiple physical disks in case of dm-snapshot.
- an application that has consistent on-disk data at all times (which
is a basic requirement to any server application)
- a file system that has consistent on-disk data at all times (such is
ext3)
Now you can:
- take a snapshot backup at any time while the server is doing regular
disk-IO
- pull the plug (crash)
- copy the data back to the original disk
- start the snapshot copy of the server and let the file system replay
its journal, then start the application again

cheers,
Carsten

--
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

Re: Bad Linux backups

[Carsten Otte]

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 application is only
> terminated when the system is shut down, a live backup of the disk would
> have no effect.  I mean, it would restore and run just fine, but be
> running with old data.
Well, backups are always about using old data in case of recovery as
far as I can see. Using an application that saves important data only
on shutdown in a mission critical environment is very dangerous
regardless of the backup soloution.

> I can jump up and down and stamp my feet, claiming that the application is
> broken, but that doesn't make it so.
What application (Server Application on Linux) acts like you claim?

regards,
Carsten

--
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

Re: Bad Linux backups

[Carsten Otte]

> 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 caching.
>
> According to its man page, "sync forces changed blocks to disk, updates
> the super block."
>
> If you don't believe (or trust) that, then "mount -o remount" is your
> friend.
You missed my point: From the file system perspective, a snapshot of
an ext3 is _always_ consistent. No need to do remount, sync, shutdown
of application or shutdown of the entire system.

regards,
Carsten

--
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