> On 18/11/2016, at 3:49 pm, Volker Kuhlmann <[email protected]> wrote: > > On Thu 17 Nov 2016 12:07:01 NZDT +1300, Pete Mundy wrote: > >> I have a reciprocal arrangement with a friend. We both have fibre >> connections with no data caps, so we each host a USB drive & Raspberry >> Pi belonging to the other. We each store (encrypted) backups at the >> other's site. The (rsync) backups are scripted to occur nightly during >> the early hours of the morning so as to not have any affect on our >> links during the day. > > Nice! Would you mind outlining your encryption methodology, please? If > you were e.g. creating a tar file at your end, encrypting hat, and then > rsyncing it to your friend you'd loose any advantages of rsync.
Yep sure, no probs! The rsync destination is a actually a mounted disc image, which is stored on an SMB share, accessed via an SSH tunnel. So before the rsync command is executed, my backup script first opens an SSH tunnel to the remote-end Pi, then mounts the SMB share via the tunnel, then mounts the disc image stored within the share (and after the backup, closes them all down in reverse). The source of my data (and the device that runs the backup) is a Mac OS X desktop, and the disc image was a standard AES-256 encrypted sparseimage file created using Apple's Disc Utility app. So I get the advantages of rsync while also having the off-site data all encrypted (and in fact it's double-encrypted while in transit due to passing through the SSH tunnel!). I presume a similar approach could be taken if your source device was a Linux box too, although I'm not sure about how one would create (or mount) an encrypted read/write disc image. I'd be interested though if anyone else knows! Pete
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Linux-users mailing list [email protected] http://lists.canterbury.ac.nz/mailman/listinfo/linux-users
