8

I have a Linux and a FreeBSD computer, both encrypted (LUKS and geli respectively). I am wondering how to make backups that would also be encrypted and would be readable to both (so that if one of the computers fails I could quickly recover the data using the other one).

Unfortunately it seems that bot LUKS and geli are kernel modules for theiy respective systems that have never been ported to the respective other one. Judging from the several threats on BSD/Linux compatible filesystems it seems that it is difficult enough to make unencrypted backups that would be readable to both (ext2 apparently being the only option for a filesystem that would allow this).

So my thoughts were to setup a virtual FreeBSD in the Linux' KVM which would be able to read and write a geli encrypted external disk and transfer the data to an unencrypted virtual ext2 volume inside the Linux' LUKS-encrypted filesystem (and the other way around). This, however, seems terribly complicated and does not really feel like the right way to do it.

Are there any better / easier / more preferrable ways? Or is the way explained above currently the best possible option?

Thanks; I appreciate any thoughts on the matter.

Improve this question
3
  • 2
    The only think I see on this list en.wikipedia.org/wiki/… that is supported on both is eCryptFS en.wikipedia.org/wiki/ECryptfs it isn't block level encryption though. It is a filesystem layer.
    – Zoredache
    Commented Nov 1, 2012 at 18:51
  • 1
    I would sooner set up another box with my favorite OS to serve and store the backups.
    – Ярослав Рахматуллин
    Commented Nov 1, 2012 at 22:31
  • Thanks very much to both of you for your thoughts. I hope some time in the future someone will port LUKS to FreeBSD or geli to Linux (I unfortunately lack both the necessary programming skills / experience and the time to acquire them.)
    – 0range
    Commented Nov 6, 2012 at 14:53

4 Answers 4

Reset to default
3

Let's establish a couple of assumptions. Do comment if those are not correct.

  1. you run machines with different operating systems, and potentially different platforms.
  2. you describe it for the case with 2 machines, and Linux and FreeBSD
  3. your machines use encrypted filesystems
  4. you want to create backups of your data, and want those backups to be encrypted too
  5. you want to be able to access data in those encrypted backups from any of the platforms contributing to the archive

(comment added to make a distinction between forms of encryption)

You mention you would like to be able to access the others systems data, from the surviving machine. One way could be to store unecrypted backups, on the local machine, on it's encrypted filesystem. Another could be to store encrypted backups, on the local machine, on an not encrypted filesystem. I suggest to store encrypted backups, on not encrypted filesystems.

However, as an aside - there is always a concern over encrypted backups: - you really need to be careful with the key - partial corruption usually kills the whole backup

my suggestion: use

to create backups to one or multiple containers both machines can access.

To keep it all inside your LAN, you could:

  1. create a "backup" filesystem on both hosts, to store the encrypted backup "packages". It does not need to an be encrypted filesystem, as the backup "packages" (brackup calls them "chunks") stored on it will be encrypted
  2. export these filesystems, e.g. with NFS, and mount it on the other hosts, respectively
  3. when you create backups, dump them to the local filesystem, and mirror them to the NFS-mounted directory on the other host. This has the nice side effect of having two instances of your backup files.

you now will have the following filesystems on your servers:

on tux, your Linux machine:

/dev/foo            /           # encrypted filesystem
/dev/bar            /tuxdump    # unencrypted filesystem, local backup
beastie:/daemondump /daemondump # NFS backup destination

on beastie, you FreeBSD machine:

/dev/flurb          /           # encrypted filesystem
/dev/baz            /daemondump # unencrypted filesystem, local backup
tux:/tuxdump        /tuxdump    # NFS backup destination

depending on the amount of data you need to backup, you could also think about an offsite container, any cloud provider would do. I'm currently playing around with configuring my S3 containers so that old stuff gets aged out to Glacier, that looks very promising, pricewise.

Improve this answer
5
  • not exactly. i don't need it to be block-by-block and i don't need it to be over network (though the tools you suggest seem very interesting). the problem is rather (as it had been correctly understood by Zoredache and Ярослав Рахматуллин) that if either of the systems break down for some reason i need some way to access the backups. so the backups should be stored on an encrypted filesystem (on another disk) accessible to both systems. this poses a problem as both the native encryption systems and the native filesystems of linux and freebsd are incompatible. sorry for not responding earlier.
    – 0range
    Commented Nov 22, 2012 at 3:16
  • oh, and I should mention that some of those tarballs are just manually encrypted for me as my PGP addressee. Smarter setups later on have two files, one archive encrypted with a symmetric key, and the key encrypted with PGP, both in yet another tarball, so files don't get lost on transfer. None of that is as nicely automated as the mentioned scripts, but it did the job.
    – Florenz Kley
    Commented Nov 23, 2012 at 21:51
  • I've never heard of duplicity, but it sounds like exactly what I'm looking for! Do you know how old is it? Is it stable? I cannot find any dates of when the project has started.
    – cnst
    Commented Jan 27, 2013 at 20:59
  • Duplicity [duplicity.nongnu.org] has been around since 2002, I'm using it since ca. 2004.
    – Florenz Kley
    Commented Jan 30, 2013 at 12:22
  • @0range - cleaned up the "encryption" distinction a bit. What I'm proposing is not block-by-block, it's file-based. Suggest to use unecrypted filesystems, because they can be read by both systems. Store encrypted backups on them, they, too, can be read on both platforms by the respective native tools. That should tick the box on both your requirements, encryption and readability, on both platforms.
    – Florenz Kley
    Commented Jan 30, 2013 at 12:37
2

Duplicity - great tool for this task, uses GPG for encryption. I am using it for some time and I really recommend.

As alternatives you can try:

  • obnam - is a new project, but has some nice features (it is a little slow if using through ssh/scp)
  • burp - encryption with password
Improve this answer
2
  • see my comment to Florenz Kley's answer above. (and thanks for suggesting those tools)
    – 0range
    Commented Nov 22, 2012 at 3:18
  • Sorry, I could only add comment here. These tools are not block-by-block, but FS (you can backup FS and restore it even on windows). GPG is a standard for encryption – it also works on both. These programs are not network only, you can backup dir to dir. So, with duplicity you can backup both machines and restore encrypted backup everywhere where you have duplicity and GPG key.
    – spinus
    Commented Nov 22, 2012 at 8:34
2

TrueCrypt should work both under Linux and FreeBSD. Although I regularly use TrueCrypt only under Windows and haven't tried FreeBSD Truecrypt myself. YMMV.

Improve this answer
1

You can backup the files of your machines using ordinary rsync on the other machines hard drive. As you're using local encryption anyways, it's encrypted with the local systems encryption and transmission is secured by TLS. Updates are fast and you stick with well proven encryption and backup mechanisms.

If you just have to backup files on some untrusted system, plain GPG worked well for me. I automated some encryption and FTP transfer with python, which runs nicely for two years already.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .