Verschlüsseltes LVM mit meheren Platten

Alica_384

Cadet 1st Year
Registriert
Sep. 2016
Beiträge
14
Hi,

ich möchte einen verschlüsselten LVM Container über mehrere Festplatten erstellen. Die Platten sind rein als Datenspeicher gedacht, es befindet sich also kein Bootfähiges System drauf.

Ich mich mittlerweile ein bisschen schlau gelesen. https://wiki.archlinux.org/index.php/Dm-crypt/Encrypting_an_entire_system :rolleyes:

Anscheinend soll man nicht das LVM verschlüsseln, sondern die Partitionen darauf. LUKS auf LVM


Ich kenne mich aber leider mit LVM nicht sonderlich gut aus, und werde aus der Anleitung auch nicht wirklich schlau. Habe auch ein bisschen Angst mein System mit falschen Befehlen zu zerstören. Kennt jemand eine gute Anleitung für diesen Zweck?

Sehr gut wäre es, wenn die verschlüsselten Volumes automatisch gemountet werden und dazu das LUKS Keyfile auf meiner bereits verschlüsselten Home Partionen liegt. :love:
 
Gerade in Bezug auf "Datenspeicher" würde ich hier zu ZFS oder BTRFS greifen, die aber kein LVM benötigen: Zumindest ZFS kann sich auch selbst verschlüsseln, BTRFS sollte es in Zukunft auch können. Beide Dateisysteme können jedoch selbst Arrays bilden, was im Fehlerfalle recht nützlich ist.

Nur eine persönliche Empfehlung. Ich selber nutze seit Langem eher ZFS, mit ein paar scripten ist's komfortabel zu benutzen, auch über mehrere Maschinen hinweg. Meine Spielereien mit LVM hatten auch eher zu mehr Problemen geführt.
Einziger "Nachteil" an ZFS: Für einen sinnvollen Betrieb bei großen Datensätzen sollte man nicht allzu geizig mit RAM sein, auch ECC empfiehlt sich hier. Für einen Desktop-Rechner ist es nicht wirklich sinnvoll (geht aber, ist nur "überdimensioniert", man wirft hier mit Flugzeugträgern auf Pantoffeltierchen). Zielgruppe sind hier tatsächlich eher Fileserver. "Datenspeicher" eben.
 
ZFS on linux ist zumindestens was das "ZFS on Root" Setup angeht wirklich, wirklich umständlich aufzusetzen (hatte es letztens probiert auf Arch Linux, Eigene ISO bauen, hatte zwar alles geklappt, aber dann sind ja die ZFS Pakete noch an ältere Kernel Versionen gebunden und dann habe ich es gelassen).
Zudem soll ZFS on linux ggü. ZFS on freebsd instabiler sein und allgemein weniger ausgereift als die bsd Version. Daher würde ich dir gleich empfehlen btrfs zu nutzen und dir die Umstände für ZFS zu sparen.
 
Zuletzt bearbeitet:
"ZFS on root" ist auch etwas umständlicher, wird aber auch nicht wirklich benötigt. Die Systempartition kann durchaus bei ext4 verbleiben, ggf. auch ein BTRFS sein.

Stabilität war bei mir bisher kein Problem, nutze seit mehreren Jahren ZFS unter Debian (mittlerweile auch von debians eigenen repos!), das einzige Problem, das ich damit habe, ist auf einem FrankenDebian unter sid (ist aber auch nur eine Workstation, keine Infrastruktur), das die einzelnen Datensätze nicht mehr automatisch bei Systemstart einhängt. Die kritischen Systeme jedoch (unter stable) haben damit keine Probleme. Und selbst wenn: Die Daten werden dreifach vorgehalten, nearline-Backups gibt's ebenfalls, wenn irgend etwas verloren geht, war's nicht so wichtig.

BTRFS ist mir persönlich zu umständlich, liegt aber unter anderem auch daran, daß ich meine Scriptsammlung für BTRFS erst erstellen müsste, für ZFS ist sie über lange Jahre gewachsen und gereift. Die Zukunft unter Linux wird vermutlich aber eher BTRFS gehören.

ZFS on Linux und die BSD-Variante sind mittlerweile durchaus gleichauf.
 
Also die am meisten benutzte Variante ist LVM on LUKS. Ist zb auch der Standardweg bei einer Debianinstallation.

Ich stand vor einer Weile vor dem gleichen Problem.
Das LVM brauchst du nicht, wenn du da komplette Platten mit nur einer Partition hinzufügst. Zumal ohne Raid mit dem LVM über mehrere Festplatten auch der single point of failure steigt.
Ich hab am Ende einfach einen LUKS Container pro Datenfestplatte angelegt und dann den Key im /root/ des ebenfalls verschlüsselten Hostsystems abgelegt.
Die werden dann in der crypttab nach dem Hostsystem eingetragen und somit automatisch mit dem Key geöffnet, wenn sie an de Reihe sind.
 
Mmh, btrfs ist gar keine so schlechte Idee. Habe mal es mal probeweise eingerichtet:

Zuerst habe ich zwei 32GB Partitionen erstellt, dann:
dd if=/dev/random of=keyfile bs=1 count=64
cryptsetup --key-file keyile -v luksFormat /dev/sdb1
cryptsetup --key-file keyfile -v luksFormat /dev/sdc1
cryptsetup --key-file /etc/keyfile luksOpen /dev/sdb1 enc1
cryptsetup --key-file /etc/keyfile luksOpen /dev/sdc1 enc2
mkfs.btrfs -L vol1 -m raid0 -d raid0 /dev/mapper/enc1 /dev/mapper/enc2



Allerdings ist das Problem, dass die Platten nicht gleich groß sind, daher ist raid0 nicht ganz so optimal oder?
Eine andere Möglichkeit wäre die Option "-m single", aber dann nutzt der kein data striping und es gibt keinen Geschwindigkeitsvorteil oder irre ich mich?
 
Den Geschwindigkeitsvorteil hast Du auch so nicht wirklich, "klebst" Du einfach unterschiedlich große Platten/Partitionen aneinander. Ein RAID0 ist allerdings auch nicht allzu empfehlenswert für ein Datengrab, hier sollte man eher über ein RAID1 oder höher (RAID5, RAID6 oder geschachtelt) nachdenken, bzw. deren Pendants auf Dateisystemebene (z.B. RAIDz1).
 
ich würde kein raid5/6 mit btrfs nutzen solange die bugs, über die z.b. auf phoronix berichtet wurden, nicht ausgeräumt sind.
 
Über die Probleme mit Raid 5 und 6, habe ich auch gelesen. Scheint ja noch nicht solange bekannt zu sein (August 2016). Das spricht natürlich nicht gerade so für btrfs. Naja es ist eben noch nicht so viel getestet worden wie z.B. ext4. :schaf:

Wie dem auch sei, ich habe mich dazu entschlossen btrfs mit einem Raid 0 zu nutzen. In meinen Tests kam btrfs mit Raid-Verbund auch mit unterschiedlich großen Datenträgern super zurecht... und das ohne Speicherplatz zu vergeuden.
Ja ich bin mir bewusst, dass das Risiko eines Datenverlust verdoppelt wird. Ich hatte aber all die Jahre noch keinen einzigen Plattenausfall und überprüfe die SMART Werte regelmäßig. Es ist halt zu schwer dem Performance Boost zu wiederstehen. :rolleyes:


Vielen Dank für eure hilfreichen Beiträge, ihr habt mir in jedem Fall weiter geholfen :)
 
Zurück
Oben