Michael Stowe wrote at about 17:15:47 -0500 on Monday, August 31, 2009:
>
> > Words like "fringe", "shenanigans" are pejorative - no matter how you
> > couch it. My response was hardly ad-hominem, but rather suggesting if
> > you went based on actual contributions to the BackupPC community then
> > you would be way more fringe than me -- that's all.
>
> There's a big difference between "that's a retarded idea" and "you are
> retarded" no matter how pejorative or inflammatory one finds the word
> "retarded."
>
> I don't think the leap from "I'm not sure how common this case is" to "oh
> yeah, let's see how much you contribute" was in any way warranted,
> necessary, and anything less than a leap to ad hominem.
>
> > Newbie as in new to this community -- no insult intended since all of
> > us start as newbies. You seem to be remarkably thin-skinned (is that
> > ad-hominem too?) in seeing insults where none were intended.
>
> Yes, calling somebody "thin-skinned" is also ad hominem, just like calling
> somebody a n00b, no matter how affectionately you meant it.
>
> Just because I recently joined this list doesn't mean I'm at all new to
> BackupPC.
This is getting ridiculous. Who cares? If it bothers you ignore
it. I'm not going to argue the semantics over relative levels of
pejorative phraseology or massage your offended ego over the term
"newbie." Let's agree to focus on issues here.
> > It's not settled. Opinions differ and the same issues keep arising. In
> > truth, there is no real well-defined long-term roadmap for BackupPC
> > and Craig is the ultimate arbiter based on his time and preferences
> > since almost all of the coding is done by him. Whether this is good or
> > bad is for another discussion. But the result is that such discussions
> > don't truly get resolved in any public way but they are hopefully healthy
> > nonetheless in terms of giving input to Craig and exploring potential
> > solution paths.
>
> Therefore, one would think that if a particular solution or technical
> point had merit, it would be worthy of rehashing.
Again this is a useless argument over semantics. Let's focus on issues
that contribute to the group.
>
> > Familiar as a user or as a developer? The issues we are discussing go
> > way beyond the Unix 101 concept of "hard links" and have to do with
> > the detailed implementation of things like attrib files and potential
> > extensions to ACL's and extended attributes. If you are familiar with
> > the code and know how to do this best, then please share with us.
>
> I'm familiar with the code. How to do *what* best? I feel we've gone all
> over the place, from attempting to solve a problem in copying a NAS
> volume, meandering over to a documentation issue, and now trying to solve
> a vague kind of problem with ACLs that I've also not experienced.
We have been talking about the subject line "Problems with
hard-linked backups...." A database for the file meta-data has been
proposed as an alternative approach that solves a number of potential
problems with hard-linked backups while potentially introducing other
complexities. Hence the discussion. Again, let's focus on the issues
and stay away from rhetoric.
>
> > I have already mentioned this multiple times:
> > Attrib files are:
> > 1. Slow/inefficient/scattered
> > 2. Kludgey/difficult to extend to ACL's and extended attributes
> > 3. Fragile and disconnected from the file source (non-atomic also)
> > 4. Require kludges like file name mangling
> > 5. Handle hard-links in a non-symmetric manner
> > 6. Contain redundant information
> >
> > Not all of these need to be solved but many if not all of them would
> > be solved by a database approach.
> >
> > #2 is a real show-stopper if you want to back up a Windows system
> > properly.
>
> #2 is interesting in and of itself, since ACLs are to some extent
> arbitrary attributes that can be associated with a file, and differ from
> operating system to operating system and from file system to file system.
> Before we get too far on how best to store ACL's, first let me ask, how do
> we intend to *retrieve* them?
Well the latest versions of rsync and tar are supposed to be able to
handle ACL's and extended attributes. People using SELinux would
presumably like to back up Linux extended attributes while people
using Windows would presumably like to back up Windows ACL's.
In fact, as far as I know, there is no good open source,
client/server, file-based, pooled backup approach for Windows that
allow for full restores. You can use things like clonezilla but that
works at the file system level or you can use BackupPC but that
doesn't store all the filesystem data needed for a full restore. Even
commercial software like Norton Ghost doesn't do pooling. Given that,
it seems that adding ACL and other file and filesystem metadata to
BackupPC would be a killer app for Windows environments.
Another disadvantage of the current approach is that it is difficult
to perform queries such as:
"How many copies of file xyz do I have?"
"Return the latest version of file xyz across the following hosts?"
(and infinite variations and extensions of the above)
------------------------------------------------------------------------------
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/
|
