Take a look at how Unison does it's compares. On Fri, Dec 18, 2009 at 9:12 AM, Les Mikesell <lesmikes...@gmail.com> wrote: > Malik Recoing. wrote: >> >>>> I know a file will be skiped if it is present in the previous backup, but >>>> what >>>> appens if the file have been backed up for another host ? >>> It is required to be uploaded first as otherwise there's nothing to >>> compare it to (yeah, I know, that's a pain[1]). >>> >>> It might theoretically be sufficient to let the remote side calculate a >>> hash and compare it against the files in the pool with matching hashes, >>> and then let rsync do full compares against all the matching hashes in the >>> pool (since hash collisions happen), but I don't believe anyone has tried >>> to code this up yet, and it would only be of limited uses in systems that >>> were network bandwidth constrained rather than disk bandwidth constrained. >> >> I'm quite sure it will be an improvement for both. Globaly there will be no >> overhead. More : the hash calculation will be kind of "clustered" delegating >> it >> to the client. The matching of identical hash is anyway done by >> BackupPC_Link. >> Thus BackupPC_Link will became pointless in a "rsync-only" configuration. The >> disk and the network trafic will be reduced as many files won't be >> transfered at >> all. > > There are two problems: one is that the remote agent is a standard rsync > binary that knows nothing about backuppc's hashes; the other is that > hash collisions are normal and expected - and disambiguated by a full > data comparison. > >> I tougth of a similar solution. When your client are mostly "full system >> tree" >> backups, you may have ready-to-copy backups of the differents OS tree. When a >> new client is added, you copy the corresponding OS directory as it was the >> first >> full backup. > > Yes, if your remote machines are essentially clones of each other, you > could create their pc directories as clones with a tool that knows how > to make a tree of hardlinks. > > A better solution might be to have a local machine at the site running > backuppc and work out some way to get an offsite copy. If bandwidth is > such an issue, you are also going to have trouble doing a restore. But, > if you've followed this mail list very long you'd know that the 'offsite > copy' problem doesn't have a good solution yet either. > > -- > Les Mikesell > lesmikes...@gmail.com > > > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-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/ >
------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-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/