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         [email protected]
             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

Reply via email to