Re: [Duplicity-talk] Rollup Functionality and Parity?

[Kenneth Loafman]

Colin Ryan wrote:
> Kenneth Loafman wrote:
>> Colin Ryan wrote:
>>
>> That is the main risk of almost any backup system, including duplicity.
>>  That's the reason we recommend regular full backups, plus local and
>> remote copies of each.
>>   
> Yes this point almost philosophical in nature. Am I correct in assuming
> that with duplicity the corruption of an incremental would leave
> anything prior in the backup chain accessible.

Yes.

>> Such a rollup would be possible, but it would require a lot of network
>> bandwidth, equivalent to restoring all of the changed files and their
>> increments, then writing them back to the host as a single incremental
>> backup, verifying, then deleting the intermediate incrementals.
> 
> I guess I was looking for some insights regarding how one might do this
> out of band. Imagine f you will that you have your local filesystem, and
> you are moving that off to a a remote site. If from a system local to
> the remote site (thereby localizing the network traffic) could one
> somehow manipulate and roll up the full + incremental into a "new full",
> in such a way that the duplicity client on the local system simply sees
> the backend as simply having a recent incremental, and hence we continue
> taking incrementals off site and "artificially build" the fulls on the
> backend.

Done locally would still require some programming on the duplicity side,
but it would indeed be possible to take the current full, merge in all
the incrementals and build a new full.  This would be equivalent to
doing a new full and would not have any advantage that I can see.

Most files are not changed between full backups.  The incremental could
be rolled up a lot faster, leaving only the last full and the rolled up
incremental.

...Ken

signature.asc
Description: OpenPGP digital signature