[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Duplicity-talk] Rollup Functionality and Parity?
From: |
Kenneth Loafman |
Subject: |
Re: [Duplicity-talk] Rollup Functionality and Parity? |
Date: |
Mon, 18 Aug 2008 16:48:47 -0500 |
User-agent: |
Thunderbird 2.0.0.16 (X11/20080724) |
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
- [Duplicity-talk] Rollup Functionality and Parity?, Colin Ryan, 2008/08/18
- Re: [Duplicity-talk] Rollup Functionality and Parity?, Kenneth Loafman, 2008/08/18
- Re: [Duplicity-talk] Rollup Functionality and Parity?, Colin Ryan, 2008/08/18
- Re: [Duplicity-talk] Rollup Functionality and Parity?,
Kenneth Loafman <=
- Re: [Duplicity-talk] Rollup Functionality and Parity?, Colin Ryan, 2008/08/18
- gpg: [don't know]: invalid packet (ctb=14) - WAS: [Duplicity-talk] Rollup Functionality and Parity?, edgar . soldin, 2008/08/19
- Re: gpg: [don't know]: invalid packet (ctb=14) - WAS: [Duplicity-talk] Rollup Functionality and Parity?, Peter Schuller, 2008/08/19
- Re: gpg: [don't know]: invalid packet (ctb=14) - WAS: [Duplicity-talk] Rollup Functionality and Parity?, edgar . soldin, 2008/08/20
- Re: gpg: [don't know]: invalid packet (ctb=14) - WAS: [Duplicity-talk] Rollup Functionality and Parity?, Kenneth Loafman, 2008/08/20
- Re: gpg: [don't know]: invalid packet (ctb=14) - WAS: [Duplicity-talk] Rollup Functionality and Parity?, edgar . soldin, 2008/08/20
- Re: gpg: [don't know]: invalid packet (ctb=14) - WAS: [Duplicity-talk] Rollup Functionality and Parity?, Peter Schuller, 2008/08/25
- Re: gpg: [don't know]: invalid packet (ctb=14) - WAS: [Duplicity-talk] Rollup Functionality and Parity?, Jacob, 2008/08/26
- Re: gpg: [don't know]: invalid packet (ctb=14) - WAS: [Duplicity-talk] Rollup Functionality and Parity?, Edgar Soldin, 2008/08/26
- Re: gpg: [don't know]: invalid packet (ctb=14) - WAS: [Duplicity-talk] Rollup Functionality and Parity?, Jacob, 2008/08/27