Re: [Fwd: Re: [rdiff-backup-users] Restarting development]

[Greg Freemyer]

On Wed, Apr 7, 2010 at 11:27 AM, Nicolas Jungers <address@hidden> wrote:
> On 04/06/2010 10:32 PM, Alexander Samad wrote:
>>
>> But I would say on encryption and de duplication - why not leave that to
>> the
>> filesystem - stay focused on what rdiff-backup does best - differential
>> backups, you can get de duplication, compression and encryption file
>> systems
>> why not leave it to them to do that (well atleast for linux and any os
>> that
>> accepts fuse filesystem).
>
> I don't know for de-duplication, but for encryption the filesystem solution
> falls a bit short.
>
> Block device encryption doesn't allow to rsync the backup of site and
> cryptfs doesn't support spare files (nor do rdiff-backup, but that shall be
> addressed soon, right?).  My memory is a bit fuzzy but I think I selected
> cryptfs because it's the only solutions which (1) allows access to either
> the crypt or uncrypt version of the files and (2) may leave the metadata
> uncrypted.
>
> So yes, it's usable, just not optimal.

Nicolas,

My rdiff-backup main repo is in a encfs filesystem.  Encfs may not be
a fully secure as other choices (I don't know), but it does allow
rsync of the encrypted data to a remote site.  (I do that).

I have done test restores to a third machine and unencrypted my data
via encfs on that machine.

So if encfs is secure enough for you, it works fine with rdiff-backup.

fyi: what is a "spare file"?

Greg