Étant donné que vous disposez de tous les prérequis de base, en particulier de la RAM ECC, je pense que ZFS (par le biais de l'application ZFS sous Linux ) pourrait être une option utilisable.
Contrairement à btrfs, qui emprunte beaucoup d'idées de conception à ZFS, ZFS est un système de fichiers (gestionnaire de volume et) éprouvé. Bien sûr, le portage Linux a quelques défauts qui sont en train d'être corrigés avec le temps, mais le code et la conception ont été testés dans un grand nombre de scénarios d'échec dans le monde réel.
Vous pouvez utiliser ZFS soit avec deux partitions séparées dans une configuration miroir, soit avec une partition et en définissant les paramètres suivants copies=2 sur le système de fichiers racine du pool. L'espace disque et les surcharges de performance E/S sont similaires. L'un ou l'autre vous permettra de migrer vers des disques plus grands, ou des configurations multi-disques, au fur et à mesure que vos besoins évoluent. Vous pouvez utiliser des vdevs raidz (avec différents niveaux de redondance : un, deux ou trois disques) mais cela pose des problèmes si vous souhaitez changer de niveau de redondance.
Je vous suggère d'envisager sérieusement d'exécuter ZFS au-dessus de LUKS.
L'inverse (exécuter LUKS au-dessus de ZFS) est également possible, mais beaucoup plus compliqué. Vous pouvez également exécuter quelque chose comme ecryptfs au-dessus de ZFS non chiffré, mais cela peut entraîner des fuites importantes de métadonnées du système de fichiers.
En d'autres termes, créez des conteneurs LUKS (un pour chaque lecteur ou partition), puis utilisez ces conteneurs pour créer un pool ZFS. L'exécution de ZFS au-dessus de LUKS devrait être suffisante pour empêcher un attaquant hors ligne dans la plupart des scénarios, mais elle ne présentera que peu d'obstacles pour un attaquant en ligne. Le fait que cela soit un problème dépend de votre modèle de menace, mais pour les sauvegardes hors site, l'accès hors ligne est souvent l'aspect le plus important à considérer.
L'exécution de deux partitions séparées en tant que conteneurs LUKS distincts devrait permettre d'éviter qu'un endommagement de l'en-tête LUKS rende les deux copies inaccessibles, mais d'autres méthodes peuvent également y remédier (par exemple, une sauvegarde de l'en-tête LUKS stockée de manière sécurisée). L'exécution d'un conteneur LUKS à partition unique pour chaque lecteur permettra à ZFS de prendre des décisions concernant le stockage des métadonnées du système de fichiers dans des emplacements divers et redondants.
Si vous optez pour copies=2 Assurez-vous de le définir immédiatement lors de la création du pool. En d'autres termes, vous voulez quelque chose comme :
cryptsetup luksFormat /dev/sdx
cryptsetup luksOpen /dev/sdx sdx-crypt
zpool create -O copies=2 tank /dev/mapper/sdx-crypt
et non
cryptsetup luksFormat /dev/sdx
cryptsetup luksOpen /dev/sdx sdx-crypt
zpool create tank /dev/mapper/sdx-crypt
zfs set copies=2 tank
car ce dernier ne réplique pas complètement les métadonnées du système de fichiers racine jusqu'à ce que ces métadonnées soient réécrites.
Notez que comme pour tout système de fichiers de type "copy-on-write", ZFS fonctionne mieux lorsque l'utilisation du disque est maintenue en dessous d'environ 75-80%, et vous devez vous attendre à une fragmentation dans le temps. Pour les sauvegardes, cela ne devrait pas être un problème majeur.
