Dado que você tem todos os pré-requisitos básicos, especialmente o ECC RAM, eu acho que o ZFS (através da implementação do ZFS no Linux ) pode ser utilizável opção.
Diferentemente do btrfs, que empresta muitas ideias de design do ZFS, o ZFS é um sistema de arquivos testado e comprovado (gerenciador de volumes e). Claro, a porta do Linux tem algumas arestas que estão sendo suavizadas ao longo do tempo, mas o código e o design foram testados em um grande número de cenários de falhas do mundo real.
Você poderia usar o ZFS com duas partições separadas em uma configuração espelhada ou com uma partição e definindo copies=2 no sistema de arquivos raiz do pool. O espaço em disco e a sobrecarga de desempenho de E / S destes seriam semelhantes. Você poderá migrar para discos maiores ou configurações com vários discos, pois as suas necessidades mudam com o tempo. Você pode usar o raidz vdevs (com vários níveis de redundância: um, dois ou três discos), mas isso apresenta problemas caso você queira alterar os níveis de redundância.
Eu sugiro seriamente considerar a execução do ZFS sobre o LUKS.
O oposto (executando o LUKS no topo do ZFS) também é possível, mas significativamente mais envolvido. Você também pode executar algo como ecryptfs em cima do ZFS não criptografado, mas isso potencialmente vaza quantidades significativas de metadados do sistema de arquivos.
Em outras palavras, crie contêineres LUKS (um para cada unidade ou partição) e use esses contêineres para criar um pool do ZFS. Executar o ZFS em cima do LUKS deve ser suficiente para evitar um invasor offline na maioria dos cenários, embora represente um pequeno obstáculo para um invasor online. Se isso é um problema depende do seu modelo de ameaça, mas para backups externos, o acesso off-line é geralmente o aspecto mais importante a ser considerado.
A execução de duas partições separadas como contêineres LUKS distintos deve ajudar a evitar danos ao cabeçalho LUKS, tornando as duas cópias inacessíveis, mas outros métodos também podem fazer isso (por exemplo, um backup de cabeçalho LUKS armazenado com segurança). A execução de um contêiner LUKS de única partição para cada unidade permitirá que o ZFS tome decisões sobre o armazenamento de metadados do sistema de arquivos em diversos locais redundantes.
Se você for com copies=2 , certifique-se de definir isso imediatamente ao criar o pool. Em outras palavras, você quer algo como:
cryptsetup luksFormat /dev/sdx
cryptsetup luksOpen /dev/sdx sdx-crypt
zpool create -O copies=2 tank /dev/mapper/sdx-crypt
e não
cryptsetup luksFormat /dev/sdx
cryptsetup luksOpen /dev/sdx sdx-crypt
zpool create tank /dev/mapper/sdx-crypt
zfs set copies=2 tank
porque o último não replica completamente os metadados do sistema de arquivos raiz até que esses metadados sejam reescritos.
Observe que, como acontece com qualquer sistema de arquivos copy-on-write, o ZFS é melhor quando a utilização do disco é mantida abaixo de 75 a 80%, e você deve esperar a fragmentação ao longo do tempo. Para backups, isso não deve ser uma grande preocupação.