Re: [Duplicity-talk] Deletion

[Scott Hannahs]

On Jan 24, 2020, at 4:53 PM, Fogust via Duplicity-talk <address@hidden> wrote:

On 2020-01-24 05:02, address@hidden wrote:

hi Foust,

 

--cut--

duplicity treats backend as dumb file storage. it merely writes or reads data from there. and because there is not target based duplicity a "reconstruction" approach would need to re-transfer the whole data.
that is in turn equal to a simple new full which is the suggested methodology here. simply use '--full-if-older-than 6M' during backup and you will end up with a new independent chain every 6 months that can be safely discarded if not needed anymore.

personally i keep monthly chains* and verify after every backup, just to be sure.

*if one volume gets corrupted the whole chain might not be restorable by default means, so regular full backups are advised.

 

Thank you. I have a large amount of data and there's a good chance that a significant portion will not change (or rarely change). So, if I have 10TB of data and 6TB doesn't change between backups, is there a way to intelligently update that to bring a bunch of incremental changes elsewhere into a full backup

Not on the server side!  As Edgar pointed out the server is considered compromised and does not have any keys or access to data.  Thus it cannot coalesce  incremental with the initial full backup.  To do so, all the data would have to be downloaded to the local machine, coalesced and then uploaded back to the server.  This is more cpu and network bandwidth than just uploading a new Full backup.

Other non-secure backups can do this.  There are several commercial systems or a series of scripts and use of rsync.  Duplicity by its name and design includes top shelf security with as much efficiency as possible.

Also note the issue of corruption with long chains and not making fresh full backups.

-Scott