Angesichts der Tatsache, dass Sie über alle Grundvoraussetzungen verfügen, insbesondere über ECC-RAM, ist ZFS (über die Implementierung von ZFS On Linux ) möglicherweise eine verwendbare Option.
Im Gegensatz zu btrfs, das viele Designideen von ZFS entlehnt, ist ZFS ein bewährtes (Volume Manager und) Dateisystem. Sicher, der Linux-Port weist einige raue Kanten auf, die im Laufe der Zeit ausgeglichen werden, aber der Code und das Design wurden in einer Reihe von realen Fehlerszenarien getestet.
Sie können ZFS entweder mit zwei separaten Partitionen in einer Spiegelkonfiguration oder mit einer Partition und Einstellung copies=2im Root-Dateisystem des Pools verwenden. Der Speicherplatz und der Aufwand für die E / A-Leistung wären ähnlich. Entweder können Sie auf größere Festplatten oder auf Konfigurationen mit mehreren Festplatten migrieren, wenn sich Ihre Anforderungen mit der Zeit ändern. Sie können raidz vdevs verwenden (mit unterschiedlichen Redundanzstufen: eine, zwei oder drei Festplatten), dies ist jedoch problematisch, falls Sie jemals die Redundanzstufe ändern möchten.
Ich würde vorschlagen, ernsthaft in Betracht zu ziehen, ZFS über LUKS auszuführen.
Das Gegenteil (Ausführen von LUKS auf ZFS) ist ebenfalls möglich, jedoch wesentlich aufwändiger. Sie könnten auch so etwas wie ecryptfs auf unverschlüsseltem ZFS ausführen, aber dadurch gehen möglicherweise erhebliche Mengen an Dateisystem-Metadaten verloren.
Mit anderen Worten, erstellen Sie LUKS-Container (einen für jedes Laufwerk oder jede Partition) und verwenden Sie diese Container dann, um einen ZFS-Pool zu erstellen. Das Ausführen von ZFS auf LUKS sollte in den meisten Szenarien ausreichen, um einen Offline-Angreifer zu verhindern, obwohl dies für einen Online-Angreifer kein Hindernis darstellt. Ob dies ein Problem ist, hängt von Ihrem Bedrohungsmodell ab. Bei Offsite-Sicherungen ist jedoch der Offline-Zugriff häufig der wichtigere Aspekt.
Das Ausführen von zwei separaten Partitionen als separate LUKS-Container sollte helfen, den LUKS-Header nicht zu beschädigen, sodass auf beide Kopien nicht zugegriffen werden kann. Andere Methoden können dies jedoch ebenfalls tun (z. B. eine sicher gespeicherte LUKS-Header-Sicherung). Durch das Ausführen eines LUKS-Containers mit einer Partition für jedes Laufwerk kann ZFS Entscheidungen über das Speichern von Dateisystem-Metadaten an verschiedenen, redundanten Speicherorten treffen.
Wenn Sie mitmachen copies=2, stellen Sie sicher, dass Sie dies sofort beim Erstellen des Pools einstellen. Mit anderen Worten, Sie möchten etwas wie:
cryptsetup luksFormat /dev/sdx
cryptsetup luksOpen /dev/sdx sdx-crypt
zpool create -O copies=2 tank /dev/mapper/sdx-crypt
und nicht
cryptsetup luksFormat /dev/sdx
cryptsetup luksOpen /dev/sdx sdx-crypt
zpool create tank /dev/mapper/sdx-crypt
zfs set copies=2 tank
da letztere die Metadaten des Root-Dateisystems erst dann vollständig replizieren, wenn diese Metadaten neu geschrieben werden.
Beachten Sie, dass ZFS wie bei jedem schreibgeschützten Dateisystem am besten funktioniert, wenn die Festplattenauslastung unter 75-80% liegt und Sie mit einer Fragmentierung im Laufe der Zeit rechnen müssen. Für Sicherungen sollte dies kein großes Problem sein.