btrfs Dateisystem über RAID1 + LUKS einrichten

Hörbört

Ensign
Registriert
Dez. 2018
Beiträge
243
Hallo zusammen,

ich möchte gerade zwei HDDs als Datenspeicher meines Eigenbau-NAS einbinden.
Zu kombinieren sind hier RAID1, LUKS-Verschlüsselung und btrfs als Dateisystem.

Der Vollständigkeit wegen liste ich hier alle relevanten Schritte auf, aber Hilfe benötige ich erst bei Schritt 4, dem korrekten Erstellen des btrfs filesystems.

1. Erstelle ein RAID1 (/dev/md0) aus /dev/sdX und /dev/sdY per mdadm
Bash:
sudo mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sdX /dev/sdY

2. LUKS-Verschlüsselung per cryptsetup für das raid device
Bash:
sudo cryptsetup -y -v luksFormat /dev/md0

3. Entschlüsseln zur weiteren Verwendung → /dev/mapper/RAID1LUKS
Bash:
sudo cryptsetup luksOpen /dev/md0 RAID1LUKS

4. Nun möchte ich per mkfs.btrfs das filesystem für /dev/mapper/RAID1LUKS erstellen.

Hier bräuchte ich nun aber etwas Hilfe, da ich nicht ganz verstehe wie die die Optionen (-d/--data) und (-m/--metadata) in meinem Fall gesetzt werden müssen. Mögliche Werte sind 'dup', 'single' oder das RAID level (hier 'raid1').


Die Möglichkeiten, die ich sehe:

a) Da die Platten per mdadm im RAID1 laufen, wäre der Wert 'raid1' für beide Optionen naheliegend.
Bash:
sudo mkfs.btrfs --data='raid1' --metadata='raid1' /dev/mapper/RAID1LUKS

b) Andererseits wende ich mkfs.btrfs auf das vom LUKS-layer gemappte device /dev/mapper/RAID1LUKS an, wodurch das aus Sicht des filesystems dann ja kein RAID device mehr ist. Sollte ich also doch die defaults für single-device setups nehmen?
Bash:
sudo mkfs.btrfs --data='single' --metadata='dup' /dev/mapper/RAID1LUKS

Leider habe ich auch aus der btrfs Dokumentation nicht heraus lesen können, was die technische Konsequenz der jeweiligen Optionen ist.
Vielen Dank schonmal für die hoffentlich reinflatternden Antworten.
 
Zuletzt bearbeitet: (copy-paste Fehler korrigiert)
  • Gefällt mir
Reaktionen: kieleich, Iapetos und Hörbört
Hörbört schrieb:
b) Andererseits wende ich mkfs.btrfs auf das vom LUKS-layer gemappte device /dev/mapper/RAID1LUKS an, wodurch das aus Sicht des filesystems dann ja kein RAID device mehr ist. Sollte ich also doch die defaults für single-device setups nehmen?
Wie du selbst erkannt hast, wird das so nicht gehen. Ich kenne mich mit btrfs nicht aus, nutze selbst ZFS, aber kann man nicht auch bei btrfs nativ verschluesselung nutzen? Falls ja, erstelle dir direkt mit btrfs ein verschluesselets Raid 1, nur so bekommst du alle features von btrfs.
 
Btrfs kann nicht nativ verschlüsseln. Die unterste Ebene muss also ein LUKS-Layer sein.
 
Leider ist Raid6 auch noch immer nicht ready, daher bin ich ebenfalls vor längerem bereits ins ZFS Lager gewechselt.
 
Salamimander schrieb:
Ich glaube, du hast da etwas missverstanden. Das Raid1 in btrfs bezieht sich auf die Integrierte Raid1 Funktionalität. Da du btrfs über nur ein Device anlegst, brauchst du da keine Raid Option mehr.
Danke für die Klarstellung. Wenn im Laufe des Tages nicht doch noch andere Aussagen rein kommen werde ich also meine Option b) durchführen.

NJay schrieb:
Wie du selbst erkannt hast, wird das so nicht gehen. Ich kenne mich mit btrfs nicht aus, nutze selbst ZFS, aber kann man nicht auch bei btrfs nativ verschluesselung nutzen? Falls ja, erstelle dir direkt mit btrfs ein verschluesselets Raid 1, nur so bekommst du alle features von btrfs.
Native Verschlüsselung ist bei btrfs leider noch nicht drin.
Wäre eine native Verschlüsselungs-Option bei btrfs dabei würde ich auch direkt die btrfs-eigene RAID-Funktionalität verwenden und das Setup wäre vermutlich ein Einzeiler.
Immerhin bringt mein Setup soweit ich das gelesen habe keine merklichen Performance-Einbußen mit sich.

Iapetos schrieb:
Btrfs kann nicht nativ verschlüsseln. Die unterste Ebene muss also ein LUKS-Layer sein.
(LUKS → RAID) oder (RAID → LUKS) geht beides und macht fast keinen Unterschied.
Ich habe mich für RAID1 via mdadm als untersten Layer entschieden, da ich dann ein Passwort weniger eingeben muss ... naja, Luxusproblem :D
 
Hörbört schrieb:
Native Verschlüsselung ist bei btrfs leider noch nicht drin.
Wäre eine native Verschlüsselungs-Option bei btrfs dabei würde ich auch direkt die btrfs-eigene RAID-Funktionalität verwenden und das Setup wäre vermutlich ein Einzeiler.:D
Gibt es einen Grund warum du BTRFS nutzen moechtest? Ansonsten wuerde ich dir ZFS ans Herz legen. Laeuft auch unter Linux, mit Ubuntu z.B. sogar out-of-the box.
 
neben bei ist besser im schritt 1) partitionen zu verwenden
 
Hörbört schrieb:
(LUKS → RAID) oder (RAID → LUKS) geht beides und macht fast keinen Unterschied.
Ich habe mich für RAID1 via mdadm als untersten Layer entschieden, da ich dann ein Passwort weniger eingeben muss
Es ist nicht sinnvoll, einen LUKS-Container auf einen btrfs-RAID1 zu propfen. Das bietet dir (aus gutem Grunde) auch keine Installationsroutine an. RAID1 ist ein integrales Feature des btrfs-Dateisystem und kein Layer!
 
Iapetos schrieb:
Es ist nicht sinnvoll, einen LUKS-Container auf einen btrfs-RAID1 zu propfen.
Da hast du Recht, aber das steht das auch nirgends :D Das RAID realisiere ich schon zuvor klassisch via mdadm
Ergänzung ()

kieleich schrieb:
neben bei ist besser im schritt 1) partitionen zu verwenden
Kannst du mir den Grund etwas ausführen, weshalb ich als erstes Partitionen anlegen sollte?

Ich finde es ganz ansprechend, dass vor der Entschlüsselung keinerlei Informationen (also auch Partitionierung) ersichtlich sind.
Zudem lässt sich mMn ein LVM komplett durch die Verwendung von btrfs subvolumes ersetzen.
 
Zuletzt bearbeitet:
Die Daten sind halt futsch, wenn dann doch irgend wann einmal doch eine Partitionstabelle da ist - weil das einfach der Standard ist und es unzählige Möglichkeiten gibt so was anzulegen - einmal Windows booten reicht z.B. schon aus - passiert ungefragt.

Wenn du das sicher verhindern kannst dann ist es kein Problem aber ist eben so wie Fahrrad freihändig fahren, klar funktioniert aber sinnlos unnötig.

Partitionstabelle frisst 2MB Platz (wegen Alignment), mdadm frisst mehr, LUKS ebenso.

Partitionstabelle enthält praktisch keine Infos, mdadm LUKS metadaten dafür, jede Menge...

viel riskiert aber nix gespart und nix gewonnen
 
  • Gefällt mir
Reaktionen: Hörbört
Zurück
Oben