Hopefully we can put this part of the thread to rest.
I will try to summarize my conclusions based on the vociferous
feedback I have heard and then throw out some compromise roadmap
suggestions that may be workable and helpful:
- While a hybrid database/filesystem approach would certainly bring a
number of advantages in some areas, it also would require a lot of
work and would introduce a host of potential
stability/robustness/speed issues. Most such issues are probably
solvable but few would be willing to risk switching to a new
approach until it was proved stable and there is likely to be little
if any interest in investing in such an effort in advance of such
proof. Other people are not interested in a new approach simply
because the current approach satisfies all or most of their needs
Recommendation: Keep as-is
- While there are block-level approaches to copying/moving the
BackupPC tree, a continuing stream of users still would be
interested in a file-level approach. Additionally, the ability to do
"incremental" backups would be welcome. Holger, myself, and perhaps
others have at times in the past suggested various O(n log n)
algorithms for copying the tree & hard links using the known
structure of the pool and pc trees. Myself and others have also
suggested potential ways of doing incrementals either by tracking
changes or by identifying changes on the fly (with the key 'gotcha'
changes being the chain renumbering). None of these approaches
appears to be particularly difficult though it does require a
commitment of time
Recommendation: Develop and test routines using the above principles
(assuming people are willing to contribute time and effort)
- Finally, I still come back to the fact that the current attrib
appoach has some significant limitations, including:
- Difficult to extend to add additional attributes (e.g., acl, extended
attributes, md5sum checksums)
- Potentially buggy somewhere in the routines (I believe Holger has
suggested there might be bugs responsible for occasional corruption
encountered by various users)
- Routines and potentially the structure of the attrib files
themselves not optimized (again Holger has mentioned at least one
potential optimization here)
Recommendation: Debug/rewrite/redesign the attrib code and structure
as necessary to eliminate bugs, improve efficiency, and to allow for
easy extension to (arbitrary) additional attributes. The last part
is perhaps more difficult than it sounds since it also would require
the ability to receive/pass the contents of the new attributes from
the file transfer routines (e.g., rsync, tar) and would in
particular require extending perl-File-RsyncP.
This may be a longer term effort (at least for the extension part)
but I think the ability to back-up ACL's (which is particularly
important for major Windows recovery) would make BackupPC useful to
a broader audience and reap good rewards.
Again, I am sure people will argue that they don't need any of the
above changes and that it works well enough as-is (or "why don't you
just buy a new server, load OpenSolaris, and run ZFS") but on the
other hand, I believe that an approach like this would ultimately meet
the needs of most everybody without forking or destabilizing the code,
without causing any functionality loss to existing satisfied users and
without requiring an insurmountable investment of effort.
------------------------------------------------------------------------------
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@lists.sourceforge.net
List: https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki: http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/
