I fiddled with the paths of my biggest backup in order to simplify an offsite copy and now because the files aren't "exactly the same" it seems it's going to take as long as the very first backup which was 4x as long as subsequent fulls. Unfortunate, because all the files are there.. but they need to be sent in full so that BackupPC can calculate the checksums..
I think it would be nice to have an optional client application on the client server. The job of the client application could be to take a base path with includes/excludes from backuppc server. This would initiate the client to chase through the local filesystem and feed checksum/filename/modification date/permission info down to the BackupPC server. BackupPC could then examine all of this as it comes in and request the few file rsyncs it might need. Anyway, I don't mean to sound critical of BackupPC.. I think it's great the way it is and I plan to keep on using it for a long time to come in present state. Just thought I would put in my $0.02. "Rich Rauenzahn" <[EMAIL PROTECTED]> wrote: > Les Mikesell wrote: >> Gene Horodecki wrote: >> >>> Is this true? Why not just send the checksum/name/date/permissions of the >>> file first and see if it exists already and link it in if it does. If the >>> file does not exist by name but there is a checksum for the file, then just >>> use the vital data to link in the file and you're done. I'm thinking >>> Backuppc shouldn't need to send the entire file for that? >>> >> >> You are talking to a stock rsync on the other end. I don't think it >> knows about the hashing scheme and collision detection that the backuppc >> pooling mechanism uses for filename generation. >> > It doesn't, but I did wonder on this list a while ago if the rsync > checksum could be stored in the pool with the hash and also kept in a > lookup table (rsync checksum -> filename) on the backuppc server. It > could be then used to see if the file exists in the pool somewhere else > before having rsync download it. > > I tried to follow the rsync backuppc perl code to see where that logic > could be injected, but ultimately gave up. There may be a limitation on > the rsync server side, but I couldn't determine that either. > > Rich > ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ 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/
