Michael Stowe wrote at about 15:48:17 -0500 on Monday, August 31, 2009:
>
> > > 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.
Perhaps next time don't cut out the critical preceding quote where you implied
that my usage was "fringe". My answer makes sense a lot more sense in
that context and comes across as less ad hominem.
>
> > > 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.
>
Is it self-evident that a BackupPC tree is difficult to
copy/move/resize if not on a dedicated filesystem? If so, then several
users a week seem to be lacking in "self-evidence. That is the
one-and-only addition to the documentation that I was suggesting and
that you seemingly keep objecting too. No one was talking about
educating the obvious that backups grow but rather the need to warn in
*bold type* that in this specific case standard directory copy
solutions don't work as well in the inevitability that the pool grows
and you need to copy or back it up.
> > 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.
ZFS and JFS are hardly universal and are certainly less prevalent than
LVM. Hence, I referenced LVM since that is a commonly suggested
solution.
> > 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.
You haven't even begun to listen or to read through the archives. It
is not my job to rehash every past long and informative discussion for
the benefit of newbies who prefer to argue and nitpick rather than to
educate themselves on past discussions.
>
> 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.
>
There has been a lot of discussion of the pros-and-cons. I suggest you
educate yourself on that first before shooting. To be fair, the
discussions have not progressed beyond laying out general pros-and-cons
-- i.e., no one has yet to start designing a specific solution. Though
I think few would argue that one is possible with the caveat that
there are pros-and-cons to different approaches and that different
users value them differently. That being said, I believe that there is
a lot of value to the discussion so far in that it outlines potential
directions for future development whether or not they are ever fully pursued.
In all seriousness, I suggest that you delve into the code and in
particular the handling of attrib files and you will see that it is
not all so neat-and-clean as creating hard links.
------------------------------------------------------------------------------
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/
|
