Re: [Duplicity-talk] Mirroring vs. Sets

[edgar . soldin]

On 04.12.2011 23:35, email builder wrote:
SNAP
> > that's standard backup methodology. backups should protect from accidential
> > deletion or hidden data corruption as well, which you might notice as late as
> > after several backups.
>
> OK that makes sense, but I'm planning to mirror multiple user email
> data from a server to probably more than one location.  I think in that
> case, mirroring is the standard methodology.  It seems like historical
> backups are used more for personal data.
>
> Does that make sense or.... not?

on a second thought. how do you expect an encrypted backup to add an increment 
if not as a set to a chain? for this you would have to encrypt the chunks rsync 
computes and i know of no software that does that. the only alternative would 
be to do fulls all the time.

> Plus, from the example given of 14MB extra in 2 months on top of a
> 90MB data set, that's not insignificant, especially when handling bigger
> (and rapidly changing as email does) data sets.

what is your mileage here?.. i consider a mailbox with 2GB reasonable and 
backupable. It'll proably change by less than 20MB every day.

SNIP
> Well, obviously I'm naive here, but I came to find duplicity because of the
> encryption.  rsync + gpg.  If rdiffdir doesn't encrypt, why not just use rsync?
> Anyhow... since it sounds like the only way to use encryption is to stay
> with duplicity, I ask again if there's a way to effectively implement mirroring
> without historical information?  (without also having to do full backups every
> time)

no. you should look for other options, duplicity is not the only encrypting 
backup software.

> If I'm doing something really inadvisable, I'm open to hearing opinions too.

if suggest try duplicity for fesability plus look around for alternatives.

ede/duply.net