Given that you have all the basic prerequisites, particularly ECC RAM, I think ZFS (through the ZFS On Linux implementation) might be a usable option.
Unlike btrfs, which borrows a lot of design ideas from ZFS, ZFS is a tried and true (volume manager and) file system. Sure, the Linux port has some rough edges that are being smoothed out over time, but the code and design has been tested in quite a number of real-world failure scenarios.
You could use ZFS either with two separate partitions in a mirror configuration, or with one partition and setting copies=2 on the pool's root file system. The disk space and I/O performance overhead of these would be similar. Either will allow you to migrate to larger disks, or multi-disk configurations, as your needs change with time. You can use raidz vdevs (with varying levels of redundancy: one, two, or three disks' worth) but this presents problems should you ever want to change redundancy levels.
I would suggest seriously considering running ZFS on top of LUKS.
The opposite (running LUKS on top of ZFS) is also possible, but significantly more involved. You could also run something like ecryptfs on top of unencrypted ZFS, but this potentially leaks significant amounts of file system metadata.
In other words, create LUKS containers (one for each drive or partition), then use those containers to create a ZFS pool. Running ZFS on top of LUKS should be sufficient to prevent an offline attacker in most scenarios, although it will present little obstacle for an online attacker. Whether this is a problem depends on your threat model, but for off-site backups, offline access is often the more important aspect to consider.
Running two separate partitions as distinct LUKS containers should help against damage to the LUKS header making both copies inaccessible, but other methods can do this as well (for example, a securely stored LUKS header backup). Running a single partition LUKS container for each drive will allow ZFS to make decisions about storing file system metadata in diverse, redundant locations.
If you go with copies=2, make sure you set that immediately when creating the pool. In other words, you want something like:
cryptsetup luksFormat /dev/sdx
cryptsetup luksOpen /dev/sdx sdx-crypt
zpool create -O copies=2 tank /dev/mapper/sdx-crypt
and not
cryptsetup luksFormat /dev/sdx
cryptsetup luksOpen /dev/sdx sdx-crypt
zpool create tank /dev/mapper/sdx-crypt
zfs set copies=2 tank
because the latter does not fully replicate the root file system metadata until that metadata gets rewritten.
Note that as with any copy-on-write file system, ZFS does best when disk utilization is kept below about 75-80%, and you should expect fragmentation over time. For backups, this should not be a major concern.
1
Nice answer, here is another stack exchange link with more setup information: http://serverfault.com/questions/586973/zfs-raid-and-luks-encryption-in-linux.
– StackAbstraction – 2015-09-02T13:24:38.793Thanks for the really extensive answer. If I understood correctly, you prefer ZFS over btrfs because of the stability of the implementation? What about the solution with using RAID1 on two partitions? If you perform scrubbing regularly, it should also be good against bit rot, right? – alesc – 2015-09-02T13:41:44.303
2ZFS questions tend to get more love on [sf]. @alesc, I prefer ZFS over Btrfs because ZFS has seen plenty of real-world use (and failures) outside of experimental setups, and particularly for the scenario you are asking about their feature sets are comparable or ZFS is better. I'd personally prefer a single partition with
copies=2and letting ZFS handle the redundancy, but two partitions should work as well and in specific failure modes may be more reliable, as stated in my answer. (If you test your backups regularly, as you should, then this should not be a major decision point.) – a CVn – 2015-09-02T13:49:11.013The only major feature I can see that Btrfs has that ZFS doesn't is the ability to change the redundancy levels of non-mirror device sets without recreation. With ZFS, you are stuck with the redundancy level you pick originally. This is the difference between home setups being grown piecemeal, and enterprise setups being set up in large swatches with advance planning. For backups, that feature difference should not be a major consideration; you can still grow your setup just as easily in either. – a CVn – 2015-09-02T13:54:38.443
Thanks again! I have managed to use your answer to successfully create an encrypted and redundant external hard drive. I used the
copies=2variant. At this stage, I would just like to ask for the difference betweenzpool unmountandzpool export. Which one should I use in my scenario? – alesc – 2015-09-02T16:51:56.6571@alesc There is no
zpool unmount; you probably meanzfs unmount. It's the difference between file systems and pools. The simple answer (I'd encourage you to post a separate question for more details) is to always usezpool exportbefore physically powering off or disconnecting the single drive that makes up your pool. (There is alsozpool offlineto take a specific storage device offline while keeping the pool available, for example to replace a drive, but this is a very different operation.)zpool exportmakes sure all buffers are flushed and the pool is marked as not in use. – a CVn – 2015-09-02T19:28:00.727@MichaelKjörling I was thinking about the
copies=2and was wondering if it will really help with bit rot. Since the disk is encrypted, a single bit flip won't affect a single bit in the filesystem but rather a whole encrypted block. How does one recover from that scenario and willcopies=2really help to restore the corrupted data? – alesc – 2015-09-06T08:55:25.750@alesc You are probably better off asking that as a separate question, but the short version of that is that ZFS checksums blocks (try
sudo zfs get checksum backup -r) which can be up to 128 KiB in size, and if the checksum indicates an error, redundant data is used (assuming that the redundant data is good) to recover.copies=2ensures that there exists redundant data (raidz or mirrors are other ways). Encryption doesn't really enter into the picture because ZFS doesn't see the encryption, only the plaintext. You as the user or administrator doesn't need to do anything, it is automatic. – a CVn – 2015-09-06T11:51:07.797