Dan D Niles writes:
Craig Barratt writes:
Multi-level incrementals will require a handful of changes:
- I would like a config parameter that controls the sequence
of incremental levels, so you can still have the old behavior
if you wish. I haven't decided how to best specify this.
With rsync, a toggle for multi-level incrementals would be sufficient.
This would also be sufficient for the other methods if you always
wanted to bump the level by one every incremental backup. If you want
anything more complex, a toggle would be insufficient. Amanda does it
with the 3 paramaters bumpsize, bumpdays, and bumpmult. But amanda
also balances what gets backed up when, so that may be overkill for
BackupPC.
Agreed - just a simple flag would suffice. For tapes you need
more control, since the incremental levels determine how many
tapes you have to load for a restore. BackupPC doesn't have
that problem.
- The $Backups[$i]{level} value filled in by BackupPC_dump should
be the incremental level (ie: 1 + $Backups[$refBackup]{level}).
Currently it is just 1 for incrementals. This is the critical
piece that BackupPC::View uses to merge the right incrementals
together.
If you fill the incremental backups, this would not be an issue.
Perhaps using a partial fill would work. What I mean is you fill
incrementals back to the previous incremental. That way any
incremental + the previos full would be an accurate view of the
filesystem. I guess for tar, and probably samba, you would still need
this incremented so the client machine knows what to send.
- The delete logic should do the right thing (ie: never delete
an incremental that a later incremental depends upon). But
that needs to be carefully checked. Deleting incrementals
could behave unusually if you ask to keep fewer incrementals
(IncrKeepCnt) than incremental levels: the newest incrementals
might get deleted first. This needs some thought.
This could get rather confusing and you could easily end up with way
more incrementals than you want. I think the partial fill I mentioned
above would also be a good solution to this.
- Each Xfer method should pick the correct reference backup.
Your suggested change does the correct thing for rsync,
although the real code will need to depend upon a
config parameter that specifies the incremental levels.
I think using a partial fill would make this easier for all the
methods.
I like your idea of partial filling incrementals. This is the approach
I will probably take.
I would also like to support just incrementals (no fulls other than the
first). This is an appropriate option for rsync, since the attribute
checking is more thorough than smbclient or tar. This carries some risk
since the file contents are never checked unless the attributes change.
(Perhaps I'll add another config parameter to specify the probability of
rsync rechecking a file's contents in incremental mode - eg, 1%.)
This would require filling the oldest incremental from the first full
since otherwise the first full would never get deleted.
Craig
-------------------------------------------------------
This SF.Net email is sponsored by the new InstallShield X.
From Windows to Linux, servers to mobile, InstallShield X is the one
installation-authoring solution that does it all. Learn more and
evaluate today!
http://www.installshield.com/Dev2Dev/0504
_______________________________________________
BackupPC-users mailing list
BackupPC-users < at > lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/backuppc-users
http://backuppc.sourceforge.net/
