Robin Lee Powell wrote at about 10:10:17 -0800 on Monday, December 14, 2009: > Do you actually see a *problem* with it, or are you just assuming it > won't work because it seems too easy?
The problem I see is that backuppc won't be able to backup hard links on any interrupted or sub-divided backup unless you are careful to make sure that no hard links span multiple restarts. And once you mess up hard links for a file, all subsequent incremental will be unlinked to. If you are just using BackupPC to back up data then that might not be important. On the other hand, if you are using backuppc to backup entire systems with the goal of having (close to a) bare metal restore, then this method won't work. Personally, I haven't seen a major memory sink using rsync 3.0+. Perhaps you could provide some real world data of the potential savings so that people can understand the tradeoffs. That being said, memory is pretty cheap, while reliable backups are hard. So, I wouldn't expect Craig to integrate functionality that would degrade the ability to reliably back up a *nix filesystem just to save a little memory. Of course, none of this is meant to discourage your own patches or forks if they suit your needs. As an aside, if anything, myself and others have been pushing to get more reliable backup of filesystem details such as extended attributes, ACLs, ntfs stuff etc. and removing the ability to backup hard links would be a step backwards from that perspective. Finally, the problem with interrupted backups that I see mentioned most on this group is the interruption of large transfers that have to be restarted and then retransferred over a slow link. Rsync itself is pretty fast when it just has to check file attributes to determine what needs to be backed up. So, I think the best way for improvement that would be consistent with BackupPC design would be to store partial file transfers so that they could be resumed on interruption. Also, people have suggested tweaks to the algorithm for storing partial backups. I suspect that a little effort in those directions would solve most problems with few if any drawbacks. Again, I really haven't seen people mentioning memory issues per-se in the normal backuppc context -- the memory issue seems to mostly come up when people are using rsync (outside of backuppc) to duplicate the pool/pc trees and its large number of hard links. ------------------------------------------------------------------------------ Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev _______________________________________________ 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/