encrypted home dir backup

[Donatas G.]

Hi Xen,

thank you for input. I used to do  backups with dar (
http://dar.linux.free.fr/doc/mini-howto/dar-differential-backup-mini-howto.en.html)
- which has an option to encrypt the resulting backups and which has an
option to do referential backups. But later I migrated to bup, which,
unfortunately, does not have encryption integrated. There is a project to
do that (see http://www.stavros.io/posts/encrypted-offsite-backups/), but
it is in early stages. I migrated to bup, because I really liked it's KDE
frontend Kup (and I am getting lazy, and backups are teadious, so the
easier they are made, the more often I do it).

So, using Kup to back up my encrypted home dir files seemed to be the way
to go.

Donatas G.

2015-12-31 2:29 GMT+02:00 Xen <list at xenhideout.nl>:

> Donatas G. schreef op 30-12-2015 20:49:
>
> Hi,
>>
>> I have read in a few places, like this
>> (http://mykek.com/os/ecryptfs/ecryptfs_with_backup.html) that it is
>> possible to backup the encrypted files of the Unbuntu encrypted home
>> directory to restore them later if need be. However, I was unable to
>> find out if it is possible to do the backup when I am logged in to the
>> session (with the encrypted home mounted/being accessed.
>>
>> Does anyone know if it will be ok / not cause problems later, when I
>> need to restore the backup? I am not quite sure why it _could_ cause
>> problems, but just to make sure...
>>
>> Donatas Glodenis
>>
>
>
>
> I don't think it causes any problems, of course there is always the (at
> least theoretical, real) risk of leaving the home directory copy in an
> inconsistent state.
>
> But that is true also for backing up a live non-encrypted homedir.
>
> The workaround people usually follow is to either use snapshots or 'volume
> shadow copy' etc., Or I don't know.
>
> Personally I believe.... the model is really that backing up encrypted
> files is not really the wise thing to do.
>
> This is because you cannot compress encrypted files, for one thing.
> Furthermore, you are also dependent on the software solution (eCryptFS) for
> restoring it the
> same and you get the added complication that you need to know how the
> encryption is done so you'll be safe decrypting it on another system.
>
> Unfortunately there doesn't seem to be an alternative means of encryption
> that is supported by default everywhere. For instance, I like "ccrypt" but
> it is not
> available on OpenSUSE distribution. It's easier to get it on Windows than
> on OpenSUSE.
>
> Then there is aescrypt but it is not available by default in Linux I think.
>
> But the general form of encrypting something is something like:
>
> tar -c <directory> | gzip -1 --rsyncable | aescrypt -e -p <key> - | split
> -b 4096m -d -a 3 - <filename>.
>
> Although that exposes the key on a multiuser system. It might give low
> performance, at which point you might need something like.
>
> tar -c <directory> | buffer | gzip -1 --rsyncable | aescrypt -e -p <key> -
> | split -b 4096m -d -a 3 - <filename>.
>
> or something of the kind.
>
> Splitting the backup is only useful for 'wire tranfers' in which even
> rsync may choke on large files. Keeping files smaller than this 4GB in my
> experience makes it easier to transfer
> the entire thing.
>
> Although it is not as pleasant to store a backup in this way. But I guess
> if the need arises you can recombine with "cat *.00? >
> completefile.tgz.aes".
>
> Not sure if this helps though, but it something to consider.
>
> Regards, Xen.
>
>
> --
> kubuntu-users mailing list
> kubuntu-users at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/kubuntu-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/kubuntu-users/attachments/20160103/020adac1/attachment.html>