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.
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}?
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.
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.
The reverse delta concept has been suggested by several people including
Jason Hughes, and I had thought about it too. But I wish I did it this
way at the inception of BackupPC. I just didn't think clearly about
separating how the backup data arrives (full and increment) and how it
is should best be stored.
Craig
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/backuppc-users
http://backuppc.sourceforge.net/
