Apologies for the slow response on this. I've been preoccupied with a Very Large Project for the past 3 weeks.
On 09/06 05:57 , Craig Barratt wrote: > Carl writes: > > BackupPC does not pick up where a 'partial' transfer left off in many cases. > > I don't fully understand the mechanism (tho it is somewhat explained here: > > http://osdir.com/ml/sysutils.backup.backuppc.general/2004-08/msg00013.html > > ); but the result is that perfectly good files are deleted from the partial > > backup. > > 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? > Also, if the partial is too old, it will be ignored and even rsync will > start a new backup, which if aborted could result in a partial with fewer > files. That's configurable with $Conf{PartialAgeMax}. > > Which XferMethod are you using when you see this problem, and what > is $Conf{PartialAgeMax}? This was done with rsync, and $Conf{PartialAgeMax} = 3; but backups were done one day after another. (I don't *think* they had enough time for the beginning of one to be more than 3 days before the beginning of the next). > 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? > This also has other advantages too: > > - it is easy to support "incremental only" rsync backups too, since the > most recent backup is always filled, > > - you don't need to merge any prior backups to have the starting point > for rsync. > > - since most restores are off the most recent version, you only need > the performance impact of merging multiple backups when browsing > or restoring older backups. > > 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. -- Carl Soderstrom Systems Administrator Real-Time Enterprises www.real-time.com ------------------------------------------------------------------------- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/backuppc-users http://backuppc.sourceforge.net/
