Carl writes: > > It depends on XferMethod. For rsync it should not delete files from a > > partial. For smb and tar, it starts a new transfer, and if any files > > get transfered (even if less than the prior partial), the new partial > > replaces the old. I should change that so it doesn't save the new > > partial (and therefore delete the old one) unless it has more files > > than the older partial. > > My understanding of how BackupPC works in this regard is imperfect. Why > can't the old partial backup be updated, in the way that conventional rsync > updates an old copy?
BackupPC doesn't do anything in place on the server. It always creates a new directory tree for each backup. In contrast, with typical usage rsync does things in place. 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. > > Longer term (main feature in 4.0?) I plan to completely change > > the way BackupPC stores backups. The most recent backup should > > always be complete (filled), and the older ones will be stored > > only as reverse-time deltas, independent of whether they were > > made with a full or incremental. Doing a backup involves > > in-place updating of the last backup, and concurrently generating > > a new tree of reverse deltas. A partial would simply mean a > > partial update of the most recent complete backup, and it would > > behave better than the current one. > > > > This makes expiry easy: you can delete the oldest reverse delta whenever > > you want. The exponential expiry (ie: deleting a backup in the middle) > > is slightly trickier - you basically have to merge to deltas to delete > > a backup. > > How much of a performance hit would it be to do this delta merging? Or could > it be optimized to be part of some other nightly cleanup operation? I'm not sure about the penalty merging backups together. It is only needed in the case when you expire a backup in the middle of the backup set. > > The one complication is whether I should go to the trouble of "unwinding" > > the in-place changes when a backup is aborted (ie: re-merging the > > partial first reverse delta). Essentially that is equivalent to > > not saving partials. It would be easier to just mark the first > > delta as a partial, and always keeping a partial. > > I'll leave that for you to experiment with and decide. :) > Are you meaning that in "always keeping a partial" the "partial" would > actually be fully-complete in the common case (where the backup completed > successfully)? I understand your question, but I do not understand your last > sentence in the above paragraph. The issue is that the proposed new style of storage would be most efficient with in-place updating of the last (complete) backup. If the backup failed part way, the most recent (complete) backup is now really a partial, and the delta prior to it (that was being generated during the backup) reflects the last full backup. My point was that it is easier to leave it that way rather than "delete the partial" which requires unwinding all the changes that were made during the failed backup, so as to put the last (complete) backup in its original state. Hope that helps. 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/
