Jim Leonard wrote at about 00:05:19 -0500 on Tuesday, September 1, 2009:
 > Jeffrey J. Kosowsky wrote:
 > > In contrast, the normal usage of hard links uses a
 > > single inode to represent the same file albeit differing only in name.
 > 
 > There is nothing abnormal about the use of hard links here.  What 
 > operating environment are you basing your definition of "normal" on? 
 > This is not only normal, it is intended.  For example, granting DBAs 
 > access to raw database volumes that they don't have the privilege to 
 > create, or backup operators write access to tape volumes.  This is 
 > normal and *intended* usage of hard links.
 > 

You can't just cut and paste one sentence -- you are missing the point

 > > But these are *not* the same files -- they just happen to have the
 > > same data.
 > 
 > If they have the same data, they're the same files :-)  Or maybe you 
 > just want to argue semantics of what a "file" is.

A file also includes the associated attributes which is why they are
part of the filesystem. Again, cutting & pasting a line at the time
misses the point.

 > 
 > > "kludge" is caused by the collapsing of several truly non-identical
 > > files (though they have the same content) onto a single inode which
 > > requires the creation of a separate database (called the attib file)
 > > to store the timestamps and rwx attributes that are normally stored
 > > within the filesystem itself.
 > 
 > Okay, fine, if this is your point then you can argue it all you like. 
 > You're saying that the attrib file is so incredibly inefficient and such 
 > a crazy hacky kludge that it should be replaced by a relational 
 > database.  I personally see nothing wrong with that, as a big relational 
 > database would be just one more component I'd have to worry about 
 > breaking when I apply OS patches, or lib patches, or security patches, 
 > or exploited by a rootkit, etc.

Well that *is* and *has* been my entire point. The attrib files are
kludgey and compensate for that fact that files with different
attributes share the same inode. The kludge gets even worse when you
are backing up hard links in the source file since the hard link
concept is already in use so you now need to identify one entry in
each pc directory as the "primary" hard link and others as effectively
"secondary" hard links.

 > Here's a tip:  Your backup system should be dedicated to *backups*.  It 
 > should do one thing and do it well.  Why make the system more complex 
 > than it needs to be?  I don't want to trade the attrib file for a 
 > database simply because "it's cleaner".

True for an enterprise environment - not necessarily possible for SOHO use.
 > 
 > Maybe you're thinking that backuppc is supposed to scale to an 
 > enterprise.  It is not.  It is a nice little system for a reasonable 
 > number of clients.  If you want an enterprise-grade system, you are 
 > barking up the wrong product.  There are open-source systems that were 
 > designed specifically for what you're asking for (amanda for 
 > medium-size, and bacula for multi-site enterprise grade backups).  But 
 > don't go arguing for a major redesign of backuppc just because the 
 > implementation isn't to your personal liking.

First, the "scaling" issue with copying occurs even at the SOHO
level. Second, issues like lack of support for ACL's and extended
attributes have nothing to do with enterprise level.

Finally, this is an open source project and there is nothing wrong with
discussing various directions for new long-term development or even
potential (helpful) forks. I don't know of any Open Software systems
that combine the pooling benefits of BackupPC with the database
benefits of Bacula so it would be interesting to think about a
solution that combines the best of both.

No one is arguing that BackupPC as-is does not meet your short or long
term needs and no one is trying to take that away from you. The
purpose of this and similar threads is merely to discuss alternative
solutions and directions. Feel free not to participate if it doesn't
interest you or meet your needs.

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
BackupPC-users mailing list
BackupPC-users AT lists.sourceforge DOT net
List:    https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:    http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/