Selva Nair <selva.n...@gmail.com> schreef:
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.
Hmmm, I know, but it would be like mounting the image within for
instance a block container (I would create a block container the size
of my quotum, and hope I can run LUKS or TrueCrypt there).
Then you mount that container and then store the images/volume in
there, and that then effectively is the volume's encryption. But I do
not like that scheme. The image itself is already a form of a block
container.
Mounting it would be pointless (it is not really a file-level
container, more like block-level).
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.
That's what I mentioned. It depends on whether the encryption
algorithm "randomizes" the encryption runs to make them different each
time, or not. Because if they are the same, you could use --rsyncable
on gzip and then what you say would be correct. But in practice, thus
far (I haven't tested it extensively with what I'm currently using)
you get a different encryption each run, which means all the blocks
are different.
If encryption is only to protect the data during transport, you can simply
use ssh transport with rsync.
Ya but it is more for remote storage (and even local storage, there
are different levels of "having to give up your passwords" and you may
have to give up one (your first) but you may still be in the position
to keep your seconds or thirds.
I have had a scheme where I had at least 3 different sets of passwords
and I can at my own leisure, so to speak, hand over the first when I
feel like it, and they will see an almost empty system except that all
normal applications are there -- just no email etc. Then, there is
another password and it only reveals non--offensive stuff. I mean,
what to call it. Non-controversial.
So when they get the second password they see only stuff that is not
very important. And then the 3rd password is even a hidden partition.
Stuff like that. I only forgot the password to the outer volume :P.
lol :(.
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.
So duplicity is a full solution. Meaning, probably, that it transfers
the data unencrypted or temporarily-encrypted, and then encrypts it at
the remote host with the given solution? All of these schemes require
some process running at the remote host.
This is also a (part) Windows solution I need. That is to say, either
the software encrypts the image, or I do it myself. You can do a cat
over ssh but that obviates the ability to have incremental stuff,
probably, unless you devise it really well. You could then encrypt it
remotely as it is received, but that is not really what you want
either. I mean partial transfers, or retranfers, or continuation of
tranfers. The only real solution for what I want is to have a delta on
the encrypted blocks.
So given that that is not possible, you delta the unencrypted file but
encrypt it remotely. However, that doesn't work with the solution I'm
using. It would also imply you directly store the file remotely, not
storing it locally first. All impossible, to day.
You probably cannot even mount a block device / file unless you are root.
So yeah, I don't know yet. Thanks for the thought though, I will think
about it.
Thanks, B.
--
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
