Re: [Duplicity-talk] Create full backup from incremental

[Scott Hannahs]

Hmm..  Ok, that is not quite what I thought.  But now I still have to keep all 
(or almost all) of my Full and Incremental backups unless all the files in the 
incremental or the Full are replaced.  I don’t think it will save much server 
space.

It takes a bit more bandwidth than a normal incremental backup.

It seems fragile now needing itself and all of the incremental and full backups 
to stay uncorrupted.

What is the advantage of this scheme over the normal incremental backup?  If 
there are some files that never change, you can rebase a new incremental over 
the static original Full backup and drop all the intermediate backups.

Maybe I am confused on this and there are some advantages that I haven’t 
envisioned.  Also when File B gets updated on the local system the incremental 
only updates a portion of B not the whole file which makes pointers to File B 
weird since they will have to point to the original and all the changed 
portions.

-Scott

> On Apr 20, 2015, at 7:38 PM, Eric O'Connor <address@hidden> wrote:
> 
> On 2015-04-19 7:34, address@hidden wrote:
>> obviously a misunderstanding. he means recreating a synthetic full
>> from an existing remote chain (full+incr's).  to do that w/o using the
>> local data you will have to locally recreate the latest states which
>> essentially is a local restore which in turn means transfer of the
>> complete chain (volumes are not cached locally).
> 
> Hmm, I think you are right about the misunderstanding, but what you say after 
> that is not what I was proposing, so I'll try to explain with an example:
> 
> 
> 
> 
> 
> On the server:
> 
> - full-1.volume containing {FileA, FileB}
> - incr-1.volume containing {FileB..now diff}
> - incr-2.volume containing {FileC added}
> 
> Locally:
> 
> - Files FileA, FileB, and FileC are stored in the user's home directory
> - Metadata noting FileB and FileC have changed since the last full
> 
> 
> 
> Then you can compute locally that a new synthetic full can be represented as:
> 
> synthetic-1.volume containing {link:full-1.volume[FileA], FileB, FileC}
> 
> To recover from this, the client would download "synthetic-1.volume", extract 
> FileB and FileC, follow the link to "full-1.volume", download it and then 
> extract FileA.
> 
> 
> -- time passes --
> 
> If FileA is later modified, and a new FileD is added, we have:
> 
> On the server:
> 
> - full-1.volume containing {FileA, FileB}
> - incr-1.volume containing {FileB..now diff}
> - incr-2.volume containing {FileC added}
> - synthetic-1.volume containing {link:full-1.volume[FileA], FileB, FileC}
> 
> Locally:
> 
> - Files FileA (modified), FileB, FileC and FileD (new) are stored in the 
> user's home directory
> 
> So now the next synthetic backup can be represented as:
> 
> synthetic-2.volume containing {synthetic-1.volume[FileB], 
> synthetic-1.volume[FileC], FileA, FileD}
> 
> To recover from this, the client downloads "synthetic-2.volume", extracts 
> FileA and FileD, follows the link to "synthetic-1.volume", downloads it, and 
> extracts FileB and FileC.