Carl writes: > ah, I see. > I think I see some of the arguments for doing things this way, but what was > *your* reasoning when you first designed this architecture? It's rather > unusual compared to the other rsync-backup programs I've seen (or built).
Rsync didn't get added to BackupPC until 2.0.0, so the architecture didn't consider how rsync typically works. Also, I didn't discover the various rsync backup tools until after I had implemented it in BackupPC. > > In 3.1.0 I've added a check that a new partial won't replace an > > old partial unless it contains more files, so that should avoid > > the annoying problem of a new partial potentially being smaller > > than the last. > > Much appreciated. Thanks. :) > Ideally, the new partial would be merged with the old partial tho. I guess > we'll have to wait for a newer version for that feature. (alternatively, how > much would it cost for someone to pay you to add that feature?) Yes, it will have to wait until 4.0. I appreciate the offer, but bribes won't change the timing. > > The issue is that the proposed new style of storage would be most > > efficient with in-place updating of the last (complete) backup. > > ah, so you're planning on abandoning the creation of a 'new' tree with every > backup, and going to in-place updating, which means we get normal rsync > behavior. (Thus obviating my comment above). Right. Tar and smbclient would also be changed to do in-place updating too. Craig ------------------------------------------------------------------------- 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 https://lists.sourceforge.net/lists/listinfo/backuppc-users http://backuppc.sourceforge.net/
