From: Michael S. <ms...@ch...> - 2009-08-31 20:49:28
|
> > In other words, I'd suggest that working around the limitations of your consumer-grade NAS is probably beyond the scope of any backup system. > > How nice of you. And please remind me of all the code you have > contributed to BackupPC and to this user group... I don't think a discussion of scope really merited an ad hominem attack. Personally, I think engaging in personal attacks weakens your arguments. > > I call shenanigans. I'd suggest that it's beyond the scope of the documentation of a backup solution to provide a basic education on LVM, nor, frankly, is LVM the only solution, nor is it available on every platform on which BackupPC runs. > > No one said "education". I said warn users of the advisability of using a dedicated filesystem that can easily be > copied/resized/moved. Because most people don't recognize the problem of copying/moving/resizing their BackupPC database until they have been using it for a while at which point it might be too late. Is there a point to documentation other than to educate? I certainly don't object to the concept of pointing out that backup repositories can grow over time, and therefore one might want to consider either scaling their repository to fixed storage or selecting a repository that allows growth, but I once would have thought this self-evident. > And I didn't say LVM is the only solution - though I am not aware of too many other solutions on Linux that allow easy resizing and > spreading of a single filesystem across multiple solutions. If there are many others that allow that, please enlighten me... You were certainly specific about LVM, and BackupPC isn't specific to Linux. Even on Linux, a combination of jfs and mdadm -grow can be accomplished without LVM at all, and zfs has been brought up more than once. > I think you are the one with "shenanigans" based on your unwillingness to open your mind to other needs and other solutions -- and if you had been a long-time contributor to this newsgroup, you would realize that this issue continues to arise without satisfactory solution no matter how many times people parrot the words "LVM", "ZFS", "block copy", etc. I have an open mind to other solutions, I just have yet to hear a practical one proposed. As you point out, however, I have not been contributing to this "newsgroup" for a "long time" so it's possible that somebody outlined practical solutions to the problem of desynchronization of a SQL store and a file system, and I missed it. |