If the system being backed up has a process dedicated to sync()ing its brains out, the exposure will be somewhat reduced.
That being said, I am not sure whether a journalled filesystem (of whatever flavor) is gonna be all that happy since you'd likely want to do a "deep" fsck rather than the quick-check. It is hard to ensure real quiescence in any kind of production system... if you can *really* go quiescent then you can take the stop, right? The real issue I see is one of trade-offs... A smaller filesystem has, for any given transfer rate, a smaller window of vulnerability to small changes accumulating. What is really being protected against? With a SAN a hardware failure is being handled "transparent to the consumer" because the SAN, itself, is managing redundancy via either mirroring, RAID5 or some multiple permutations of this technology (I can imagine a two-dimensional RAID5 and my brains starts to boggle, but, then, the S/390 and brethren have two-dimensional ECC, too) so, really, are you worried about a hardware failure in an HDA? I can see such an effort being done to protect against a software failure where something in the OS (or, with windows, some kind of facsimile of an OS) may trash the current set of drives the system is seeing and you may want some kind of disaster recovery when some kind of runaway doodles on the disks. In any backup strategy you first have to identify what you are protecting against... and then work against that. You can learn a lot listening to Bruce Schneier and the folks who make comments on his blog... and figuring out what you want to protect against is the first step or else you'll have "backup theater" (like the "security theater" you see at airports) which only gives warm fuzzies but doesn't do enough of the REAL job. - soup On Thu, Dec 17, 2009 at 2:03 PM, Gary Detro <[email protected]> wrote: > Yes, I have booted off the backup disks and IPL's successfully and then > checked the data. We do the backups off hours so there is less activity. > But we know there is a possibility of this process being fuzzy or somewhat > because of caching. > > But it has worked for our environment. > > > Thanks, > > Detro > > > > > > > From: RPN01 <[email protected]> To: > [email protected] > Date: 12/17/2009 12:56 PM > Subject: Re: Backup procedure for Linux Sent by: Linux on 390 Port < > [email protected]> > ------------------------------ > > > > You may find your backups to be inconsistent or unstable this way, as Linux > buffers things in storage, so the disk image taken by the snapshot may not > be complete at the moment you flash. > > Have you tried mounting and looking over the data on the backup disks as > yet? > > -- > Robert P. Nix Mayo Foundation .~. > RO-OE-5-55 200 First Street SW /V\ > 507-284-0844 Rochester, MN 55905 /( )\ > ----- ^^-^^ > "In theory, theory and practice are the same, but > in practice, theory and practice are different." > > > > > On 12/17/09 12:50 PM, "Gary Detro" <[email protected]> wrote: > > > The approach we have taken is to give the machine duplicate mdisk 150-155 > > (base disk) and then B150-B155 (backup disks) and do a flashcopy of the > base > > disks to the backup disks. From another user running CMS programmable > > operator. I do this without stopping the linux guest system and it has > been > > recoverable each time we have tested. > > > > > > Thanks, > > > > Detro > > > > > > > > > > > > > > > > > > From: Stephen Frazier <[email protected]> > > To: [email protected] > > Date: 12/17/2009 12:45 PM > > Subject: Re: Backup procedure for Linux > > Sent by: Linux on 390 Port <[email protected]> > > > > > > > > > > Romanowski, John (OFT) wrote: > >> > Are you asking how to make the script launch automatically when the > >> minidisk attach event occurs? or ?? > >> > > >> > > > No, what I am asking is what should I put in the script to be able to > > back up everything needed to do a restore in another virtual machine. > > > > -- > > Stephen Frazier > > Information Technology Unit > > Oklahoma Department of Corrections > > 3400 Martin Luther King > > Oklahoma City, Ok, 73111-4298 > > Tel.: (405) 425-2549 > > Fax: (405) 425-2554 > > Pager: (405) 690-1828 > > email: stevef%doc.state.ok.us > > > > ---------------------------------------------------------------------- > > 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 > > <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 > > > [attachment "image.gif" deleted by Gary Detro/Dallas/IBM] > > -- John R. Campbell Speaker to Machines souperb at gmail dot com MacOS X proved it was easier to make Unix user-friendly than to fix Windows ---------------------------------------------------------------------- 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
<<image/gif>>
