From: Jeffrey J. K. <bac...@ko...> - 2009-09-01 01:17:14
|
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. |