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 lesmikes...@gmail.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@lists.sourceforge.net List: https://lists.sourceforge.net/lists/listinfo/backuppc-users Wiki: http://backuppc.wiki.sourceforge.net Project: http://backuppc.sourceforge.net/