Hallo frostschutz, danke für deine schnelle und ausführliche Anleitung.
frostschutz schrieb:
Arny80Hexa schrieb:
Also traditionell indem du ein Backup machst und dann selbiges auf ein dann verschlüsseltes RAID einspielst...
Die Idee ist mir auch schon gekommen. Allerdings hab ich gerade keinen Speicher mit gut 11TB rum liegen. 😉
Ansonsten hängt es davon ab wie risikofreudig du bist.
Geht so. Die Platten (HGST Deskstar NAS) sind nicht älter als ein Jahr und laufen gut gekühlt durchschnittlich nur 3-4 Stunden Täglich. Der Umbau von 4x4TB Raid5 auf 5x4TB Raid6 lief damals rund 40 Stunden und gab keine Zwischenfälle. Allerdings wäre ein Datengau von 11TB Daten auch schon echt fies.
Wenn du z.B. bereit bist für die Dauer der Umstellung auf Redundanz zu verzichten, kannst du 2 Platten aus dem RAID6 rauswerfen, mit diesen beiden Platten ein neues RAID6 bauen (und verschlüsseln). Dann kannst du schonmal 8TB Daten rüberschieben. Dann das Dateisystem verkleinern, das RAID verkleinern, zwei weitere Platten freimachen die du ins andere RAID steckst, verschlüsseltes Dateisystem vergrößern und dann den nächsten Schwung Daten rüberschieben. Und wenn alles drüben ist dann eben alle Platten im neuen RAID haben. Nur wenn dir dabei eine Platte eingeht dann wars das halt, aus vorbei.
Wie gesagt, ich würde zwar nicht meine Hand dafür ins Feuer legen, allerdings traue ich den Platten schon ein bisschen was zu. Alternativ war ich eh am Überlegen in absehbarer Zeit auf größere Platten umzustellen. Ich wollte warten bis die 10TB-Platten draußen sind und dann die bis dahin bezahlbaren 8TB-HDD's in meinen Server einbauen. Der Grund dafür ist auch schnell gefunden. Ich hab 10 SATA-Ports auf meinem Board. Aktuell 6x4TB (Raid), 1x SSD und 1x BluRay Laufwerk. Sind also nur noch 2 Ports frei. Wenn ich die nun auch wieder mit 4TB Platten voll stopfe, bekomme ich beim Umrüsten auf größere Platten ein kleines Problem.
D.h. nach deinem Vorschlag wäre es wahrscheinlich am sinnvollsten bis zu dem Zeitpunkt, dass 8TB-HDD's bezahlbar sind, abzuwarten und dann mit den 8TB-Platten nach deinem Vorschlag das Raid umzubauen.
Du kannst auch direkt auf dem RAID in-place verschlüsseln. Dazu musst du das Dateisystem um 2MiB verkleinern um Platz für den LUKS-Header am Anfang zu schaffen, und dann unverschlüsselte Daten in den verschlüsselten Container schreiben. Da sich die Daten dabei alle um 2MiB nach rechts verschieben, muss dieser Kopiervorgang entweder rückwärts ablaufen (ddrescue mit Rückwärtsgang) oder die 2MiB zuverlässig zwischengepuffert werden (die meisten Pufferprogramme garantieren keine Mindestfüllung). Bricht der Vorgang ab hast du ein halb verschlüsseltes und damit defektes Dateisystem.
Gefühlt klingt das nach einer sehr mutigen Variante.
Das ist alles nicht so ohne und es gibt kein 1-Klick-Tool dafür. Selbst mit einem Tool ist totaler Datenverlust möglich.
Hab ich nicht erwartet! 😉
Bisher kann ich das Raid6, wenn es voll läuft, mit beliebig vielen HDD's erweitern. Besteht diese Möglichkeit nach der Verschlüsselung weiterhin?
Was ist im Falle eines HDD-Ausfalls zu tun / zu beachten, wenn das Laufwerk verschlüsselt ist?
Das unterscheidet sich nicht, gleiche Prozedur wie ohne Verschlüsselung.
Ich muss hier noch mal kurz einhaken. Was sich mir noch nicht ganz erschließt, sind die unterschiedlichen Funktionsweisen der verschiedenen Verschlüsselungsmöglichkeiten (ecryptfs, lvm und luks sind mir bekannt) unter Linux. Du schlägst an der Stelle luks vor. Ich habe gerade Heute erst zufällig mit einer VM rum gespielt, bei welcher ich ein Raid1 Simuliere. Es sind 2 Raid Partitionen. 1. für /boot zweite für einen lvm-Kontainer (lvm volume group). In dem lvm-Kontainer wiederum habe ich 3 logical lvm Volumes. Das erste Volume beinhaltet die root-Partiton und ist unverschlüsselt (ziel war es nur einen bestimmten Service auf der Maschine zu verschlüsseln). Die beiden weiteren Volumes (swap und /opt) sind lvm-verschlüsselte Volumes.
Wenn ich das jetzt richtig verstanden habe, ist bei dieser Methode das gesamte logische Volume verschlüsselt. Ich weiß von Früher aus der Windows-Welt (TrueCrypt), dass es alternativ auch die Möglichkeit gibt auf einer bestehenden Partition verschlüsselte Container zu erstellen, die dann eben mit wachsen, desto mehr Daten beinhaltet sind (ob die auch schrumpfen weiß ich gerade nicht). Wie verhält sich das im Falle von den drei genannten Methoden (ecryptfs, lvm und luks)? Ist bei deiner Variante dann die gesamte Partition verschlüsselt, oder ist das "nur" ein Container? Also - mal zielgerichtet gedacht - welche Schritte tut man, wenn ich das Raid erweitere? HDD als Spare hinzufügen. Raid "growen" (um die neue Platte). Dateisystem vergrößern. Und dann?
Weiterhin im Falle des Platten-Ausfalls: Ich nehme an, dem Raid-Verbund selbst ist total egal, welche Daten (ob verschlüsselt oder nicht) es beinhaltet und startet einfach eine Byte-weise Restauration, wie ich es gewohnt bin!?
Bei AES-NI praktisch keine, solange du bei aes-xts-plain64 (o.ä. aes-cipher) bleibst. Ohne AES-NI ist auch bei einer guten CPU so mit ~100M/s bei 100% CPU-Belastung Schluss.
Aber ein 4770T sollte ja AES-NI haben (grep aes /proc/cpuinfo
sollte Flags: ... movbe popcnt aes xsave avx ... liefern).
Gehe ich von aus. Schaue ich später mal. Das ist dann aber auch standardmäßig aktiviert und von Ubuntu verwendet?
Ich befürchte ich habe da bei den Raid-Parametern ein bisschen was verstellt.
Kann man ohne weitere Information nichts zu sagen. Am besten bleibt man bei den Defaulteinstellungen, wenn man keinen sehr guten Grund hat, was anderes zu nehmen...
Leider ist die Urinstallation schon ein wenig her. Ich hatte damals in der Anleitung gelesen, dass es Formeln gibt, um gewisse Werte (ich glaube das hatte was mit der "Chunk"-Größe zu tun?) an die Gegebenheiten des Raids anzupassen. Entscheidender Faktor war hier die Platten-Anzahl im Raid und noch paar andere Dinge. Ich finde leider die Anleitung nicht mehr, ist aber für das eigentliche Thread-Thema jetzt auch nicht so sehr relevant.
Tut mir leid für die vielen Fragen, ich möchte das ganze Thema halt verstehen und nicht nur blind irgendwelche Anleitungen runter arbeiten ohne zu wissen was ich da mache und was das für Konsequenzen hat. Flexibilität (erweitern etc.) und Sicherheit (Verschlüsselung und Ausfallsicherheit) sind halt bei meinen Vorstellungen gleichermaßen zu beachten.
Ach ja, dazu noch eine letzte Frage. Der Server läuft wie erwähnt nicht dauerhaft (ist nicht nötig), ich kann ihn aber aus der Ferne einschalten. Ich kenne dass von meiner lvm-Testinstallation, dass ich noch während des Bootvorganges die Passphrase zum entschlüsseln eingeben muss. Lässt sich das auch anders gestalten, dass ich das Laufwerk erst bei Bedarf entschlüssle und einhänge? Am angenehmsten wäre es wie bei der Variante, wo ich mit ecryptfs das home-Verzeichnis verschlüssle, welches entsperrt wird, wenn ich mich als Nutzer einlogge. Aber über die Konsole wäre auch ok, Hauptsache nicht während des Bootvorganges. Welche Möglichkeit habe ich hier?
Vielen Dank nochmals! Beste Grüße. Arny