On 9/18/10 6:40 AM, Jon Craig wrote:
>
>> You're welcome to point out how I have, in any way, demonstrated any lack of
>> technical competence, other than the mere fact I'm not a major Perl hacker 
>> who
>> can instantly jump into and fix bugs in an unfamiliar project.
>>
> Your very first post calls BackupPC's methods fragile and complains about a
> documented requirement of the login process.

That doesn't make it any less true or less of a problem.  Most people have 
managed the workaround to make logins quiet or switched to port-forwarding to 
rsyncd over ssh, but the fact is that stock rsync works anyway where it breaks 
the perl version in backuppc.

>> I'm well aware of that.  "Full" backups (checksumming the ENTIRE filesystem),
>> however, are an obscene waste of time and resources for no good reason, that 
>> CAN
>> be eliminated for the reasons I've already stated.  Network bandwidth, disk
>> space, etc., are not my predominant concerns.  The time it takes to run a 
>> "full"
>> backup on a multi-terabyte server is extremely prohibitive.  Several 
>> commercial
>> backup solutions (CDP-type solutions in particular) only do a full backup 
>> once,
>> and NEVER again.  rsync is perfectly capable of doing something quite close 
>> to
>> this.  There's no reason BackupPC shouldn't be able to take advantage of 
>> this as
>> well, if it simply dropped the legacy full/incr mentality.
>>
>
> Maybe my education is lacking.  Could you explain to me how rsync
> avoids checksumming the entire filesystem without using file
> timestamps to include / exclude files and how backuppc's
> full/incremental behaves differently.

The problem here is that two operations are unnecessarily coupled in backuppc 
fulls.  The tree is rebased for subsequent comparisons (which you need to do at 
regular intervals) and the --ignore-times option is added to force full file 
comparisons - a slow process that doesn't necessarily have to happen at the 
same 
intervals - or maybe never if you trust the file timestamp/length checks.  
Again 
there have been workarounds like breaking the large target into several 
separate 
subdirectory runs aliased to different hosts so the schedules can be skewed, 
but 
it is something that could be decoupled in the design.

> I'm sorry if my impressions of your attitude are incorrect.

I'll agree that the attitude is unwarranted, but I think it is a 
misunderstanding. The mailing list isn't being intentionally unhelpful. 
Speaking 
for myself at least, tackling changes in an rsync-in-perl implementation is 
just 
a little overwhelming.  Making that work at all (especially with the back end 
working with compressed files) is such an impressive accomplishment that I even 
feel bad complaining about the few problems left.  By the way, the author is 
this Craig Barratt:
http://www.atheros.com/about/executives.html and probably doesn't have a lot of 
spare time on this while he is also working on a major redesign that he has 
said 
will use stock rsync and eliminate the hardlinks.

-- 
   Les Mikesell
    lesmikesell AT gmail DOT com

------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________
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/