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
