On Tue, Oct 13, 2015 at 12:54 PM, Xen <l...@xenhideout.nl> wrote: > Hi Folks, > > I was wondering if I could ask this question here. > > Initially when I was thinking up how to do this I was expecting block > encryption to stay consistent from one 'encryption run' to the next, but I > found out later that most schemes randomize the result by injecting a > random block or seed at the beginning and basing all other encrypted data > on that. > > In order to prevent plaintext attacks I guess (the block at the beginning > of many formats is always the same?) and also to prevent an attacker from > learning the key based on multiple encryptions using the same key. > > However the downside is that any optimization scheme is rendered useless, > such as rsync's. > > What is a best practice for this, if any? >
If the backup is from an encrypted volume to another, depending on the scheme used, you could arrange rsync to see only decrypted data (with the transport protected by, say, ssh): for example, both destination and source using eCryptfs could have the decrypted volumes mounted during the backup. But this may not be necessary: Directly backing up an encrypted volume could still make use of rsync's delta algorithm:.in case of eCryptfs, for example, data is encrypted in blocks of page_size (e.g., 4kB), so only a few blocks may change during updates and subsequent rsync runs could be almost as efficient as on unencrypted volumes -- I haven't tested this though. If encryption is only to protect the data during transport, you can simply use ssh transport with rsync. If the idea is to protect the data at a remote backup destination, say on the cloud, rsync may not be the best option. For that I prefer duplicity which uses the rsync algorithm to transfer only deltas (uses librsync) but stores the backup as tar archives encrypted by GnuPG (both the initial full backup as well as incremental deltas). You lose the advantage of a mirror archive that rsync can maintain. Selva
-- Please use reply-all for most replies to avoid omitting the mailing list. To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
