Les Mikesell wrote at about 11:15:52 -0600 on Tuesday, December 16, 2008:
 > Jeffrey J. Kosowsky wrote:
 > > 
 > > Which gets me back to the #1 thing that is gnawing me (in a positive
 > > way) about BackupPC -- which is that it *seems* to be lacking an active
 > > development engine. There is so much exciting stuff to be done but I
 > > have yet to figure out how to tap into a group that is active in
 > > taking this to the next level.
 > 
 > I'm not sure anyone other than Craig really understands the 
 > rsync-in-perl or the hashing/pooling code well enough to touch it...
 > 
I haven't touched the rsync-in-perl code and don't know anything about
it but I can say that the hashing/pooling code (and the whole nature &
structure of attrib files) is pretty straightforward. I have gotten
pretty deep in the code from the routines I have written to check/fix
the pool and to delete individual files and directories (correctly)
from one-or-more incremental or full backups. The code for playing
with the pool is all very straightforward.

 > But the thing I alway thought should happen was some sort of merge with 
 > bacula code.  That is, either make backuppc able to talk to bacula's 
 > client agent, or put backuppc's file pooling code into bacula's disk 
 > archive handling.

I agree - I think the ideal combo would be:
  - Pooling & compression like with BackupPC (though I would add full
        md5sum checksums which you would get anyway I think if we upgrade
        to protocol 30)
  - Database backend like Bacula (this would get rid of the platform
        dependence of hard links along with all the associated limitation
        and backup issues caused by them; plus, it would make it much
        easier to extend to allow backup of acls, extended attributes, and
        any other filesystem entry needed to accurately recreate the
        backup)
  - Choice between simpler server+rsync method like BackupPC (for SOHO
        or personal use) vs. more sophisticated client/server approach of
        Bacula
  - Modular code that would allow extensions (e.g., alternative
        compression algorithms, encryption)
  - Choice of interfaces:
                 web
                 fuse fs
                 other modular extensions
  - Knowledge of and ability to create full restorable backups of
        multiple filesystems (including shadow copies for NTFS and other
        ntfs tidbits)

 > 
 > As for fuse, it is a nice idea but I doubt if you'll like the 
 > performance on operations that have to uncompress the files.

It is fine for small numbers of files and poking around. Certainly
faster than navigating the CGI interface ;)

 > 
 > -- 
 >    Les Mikesell
 >     lesmikesell AT gmail DOT com
 > 
 > 
 > ------------------------------------------------------------------------------
 > SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
 > The future of the web can't happen without you.  Join us at MIX09 to help
 > pave the way to the Next Web now. Learn more and register at
 > http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
 > _______________________________________________
 > 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/
 > 

------------------------------------------------------------------------------
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
_______________________________________________
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/