Holger Parplies wrote at about 01:25:40 +0200 on Tuesday, September 1, 2009:
*snipped all the irrelevant and patronizing comments*
> How do you ensure consistency between database content and file
> system content? Please answer that, for once!
How do you ensure consistency between the pool and the attrib files?
But more importantly, this is entire question is a Red Herring.
It is also at its essence an unanswerable question unless you provide
specific cases that you are worried about. It's like saying "How can you
guarantee that you won't get hurt tomorrow" - well, I can't answer
that question unless you tell me what things you are worried will hurt
you.
Here too. Rather than continuing to site some general scary bogeyman
of inconsistency, please for once give specific cases where
inconsistency can occur. Then each case can be addressed (or not) in
turn.
Similarly, I could ask you how do you assure that the pool and pc
trees remain consistent? And you would say but they are because of
hard links. And I could site hypotheticals that would break the
consistency. Luckily most of them are either unlikely or
require deliberate intervention, so you can relax and feel comfortable
in consistency. But the point is unless you tell me
what you are specifically worried about, I can't tell you how or even
if it likely to be an issue or whether it is solvable.
>
> Go ahead, prove me wrong. Maybe I'm just to blind to see what is evident to
> you, but you won't convince me by reiterating the same old assumptions. Show
> me!
Tell me what you *specific* use cases are and then I can try to prove
them wrong (or better try to figure out a way around them or convince
you that they are not relevant). Otherwise, it is like saying "since
you can't prove that God does not exist, he must exist."
> The one thing that makes sense to me - to a certain degree - is joining
> attrib
> files into one database. This also gives you a single point of failure - the
> corruption you had with your attrib files could have made the whole database
> unusable instead of only a single attrib file for one directory. Sure, you
> *can* back it up, you would probably *have to* for any reasonable amount of
> robustness. Just to be clear: putting the pc/ directory structure inside a
> database *does not* make sense to me. Not even maybe.
Well joining them into a single linear text based database certainly
makes no sense since it would make retrieving individual file
attributes even slower and more inefficient. If you are talking about
a relational database, then the one thing that makes sense to you is
really the one thing I have been arguing for so we at least have some
partial agreement. But once you have everything in a single relational
database, you then need to ask yourself whether you still need to
maintain a parallel implicit database of pc trees and hard
links. Whether or not that is useful would depend on various
pros-and-cons regarding access time, robustness, storage efficiency
etc. I would certainly be open to objectively weighing the pros-and-cons.
>
> That aside, I'm looking forward to your experiences with storing your
> database
> on a file system mounted via NFS (we *were* talking about a solution that
> "fits everyone's needs", not only yours, weren't we?) and random other
> complications that *arbitrary* BackupPC installations may add.
Please elaborate. I happen to have my topdir on an NAS-based
filesystem mounted over NFS. If you recall from when I was a BackupPC
newbie, that too created issues that ended up severely and almost
entirely corrupting my pool and pc tree. I believe that most people
counselled against using NFS-based filesystems for BackupPC, so
presumably you wouldn't be losing anything by moving to a
database-version. By the way, once I identified that the problem was a
linux kernel driver issue and fixed it, I have not had to unmount or
reboot my NFS partition in over 6 months.
>
>
> Just some thoughts out of many, most of which I've already forgotten while
> reading all of this thread (why did I read it? Valid question. I don't
> know.).
>>From my reading of your posts over the past year, I think you enjoy
arguing and being a wise-ass (and in full-disclosure, I regrettably
share some of the same anti-social tendencies ;)
Remember not everything is black-and-white. People are allowed to
continue to hold and espouse different opinions. People have different
needs and weigh pros-and-cons differently. Clearly there is a
role for database-based backup programs or else there wouldn't be so
many out there. On the other hand, BackupPC as-is is also a valid and
wonderful implementation. Just because you have your own (valid)
opinion in the context of your own user needs and biases, others too
have their own separate needs and biases.
> P.S.: Tino suggested moving this to backuppc-devel. I think we have a more
> suited place ... $TopDir/trash ...
I have a better suggestion. Ignore if you are not interested.
------------------------------------------------------------------------------
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/
|
