Probleme mit RAID 1 - HW und SW

[NAB]

Ich hab mir zwar gedacht das ich mir lvm spare.. irgendwie fehlt mir bei lvm die Kontrolle, was wohl sicherlich auch dem fehlenden Wissen her geschuldet ist. Es ist sicher sehr gut wenn man stets einfach neuen Festplattenplatz einhängen kann, aber was wenn etwas am lvm system schiefläuft? alles futsch?

Ja, ich mag lvm auch nicht sonderlich ... warum es hier und da über den grünen Klee gelobt wird, kann ich nicht nachvollziehen. Es ist halt einfach eine zusätzliche Verwaltungsschicht, die man auch noch manuell einbinden muss, wenn man das System mal von einer Live-CD aus retten oder backupen muss. Aber "schief gelaufen" ist mir da noch nie was ... es scheint recht solide zu sein.

Ich seh zu, dass ich drum herum komme. Dementsprechend lege ich - in deinem Raid-Setup - mehrere Partitionen an, bau daraus mehre Raids zusammen, und in die Raids kommt dann je ein Crypt-Container, und darein dann ein ext4. Nachteil: man hat mehrere Passworte. Das löse ich mit "decrypt_derived", also quasi mit einer hinterlegten Schlüsseldatei.

Den Ansatz, eine Partitionstabelle im Raid anzulegen, hab ich mal versucht - Nachteil: die Partitionen werden nicht automatisch erkannt. Auch nicht beim Booten. Ich musste irgendwie mit "kpartx" nachhelfen und mir meine Datenplatten per Script ins System einbinden. Das ist also noch blöder als lvm.

So unterm Strich ... brauchst du überhaupt mehrere Partitionen? Warum nicht ein großes Raid, darein einen Crypt-Container, und da rein ein großes ext4? Statt Partitionen machst du Unterverzeichnisse und mountest die mit "bind" dahin, wo du sie haben willst.

[Trollkirsche]

Ich hab mir zwar gedacht das ich mir lvm spare.. irgendwie fehlt mir bei lvm die Kontrolle, was wohl sicherlich auch dem fehlenden Wissen her geschuldet ist. Es ist sicher sehr gut wenn man stets einfach neuen Festplattenplatz einhängen kann, aber was wenn etwas am lvm system schiefläuft? alles futsch?

Ja, ich mag lvm auch nicht sonderlich ... warum es hier und da über den grünen Klee gelobt wird, kann ich nicht nachvollziehen. Es ist halt einfach eine zusätzliche Verwaltungsschicht, die man auch noch manuell einbinden muss, wenn man das System mal von einer Live-CD aus retten oder backupen muss. Aber "schief gelaufen" ist mir da noch nie was ... es scheint recht solide zu sein.

Ich seh zu, dass ich drum herum komme. Dementsprechend lege ich - in deinem Raid-Setup - mehrere Partitionen an, bau daraus mehre Raids zusammen, und in die Raids kommt dann je ein Crypt-Container, und darein dann ein ext4. Nachteil: man hat mehrere Passworte. Das löse ich mit "decrypt_derived", also quasi mit einer hinterlegten Schlüsseldatei.

Den Ansatz, eine Partitionstabelle im Raid anzulegen, hab ich mal versucht - Nachteil: die Partitionen werden nicht automatisch erkannt. Auch nicht beim Booten. Ich musste irgendwie mit "kpartx" nachhelfen und mir meine Datenplatten per Script ins System einbinden. Das ist also noch blöder als lvm.

So unterm Strich ... brauchst du überhaupt mehrere Partitionen? Warum nicht ein großes Raid, darein einen Crypt-Container, und da rein ein großes ext4? Statt Partitionen machst du Unterverzeichnisse und mountest die mit "bind" dahin, wo du sie haben willst.

Hehe genau so gehe ich grad vor. Habe mich nun doch für lvm entschlossen und habe es genauso umgesetzt. Der freie Speicher der 2x8TB Platten habe ich als ein physikalisches Raid Volumen deklariert. Dann habe ich in der Raid Config das MD Gerät für die 2 Raid Volumen erstellt.

Aus den aus 2 Raid Volumen neu hervorgegangenen, logischen Volumen habe ich ein verschlüsselten Container erzeugt und darin wieder eine grosse lvm partition. Dasselbe werde ich auch mit der SSD Systemplatte machen ausser das ich dort EFI und /boot partition separat angelegt habe und nicht verschlüsseln werde.

Zurzeit überschreibt er grad das 8TB Raid Volumen mit Zufallszahlen. dauert ewig

Ich gebe selbstverständlich Bescheid ob alles geklappt hat.

Bis dann!

[NAB]

Aus den aus 2 Raid Volumen neu hervorgegangenen, logischen Volumen habe ich ein verschlüsselten Container erzeugt und darin wieder eine grosse lvm partition.

Hmmm ... genau dann hättest du dir den zusätzlichen Schritt, da noch ein LVM reinzulegen, sparen können. Du kannst ein ext4 direkt in den verschlüsselten Container legen.

Zurzeit überschreibt er grad das 8TB Raid Volumen mit Zufallszahlen. dauert ewig

Das machst du aber nur einmal! Falls es einen zweiten Versuch gibt, überspringst du diesen Schritt.

[Trollkirsche]

Aus den aus 2 Raid Volumen neu hervorgegangenen, logischen Volumen habe ich ein verschlüsselten Container erzeugt und darin wieder eine grosse lvm partition.

Hmmm ... genau dann hättest du dir den zusätzlichen Schritt, da noch ein LVM reinzulegen, sparen können. Du kannst ein ext4 direkt in den verschlüsselten Container legen.

Zurzeit überschreibt er grad das 8TB Raid Volumen mit Zufallszahlen. dauert ewig

Das machst du aber nur einmal! Falls es einen zweiten Versuch gibt, überspringst du diesen Schritt.

Ich finde das eigentlich noch ganz gut das ich per lvm dynamisch einfach weitere Disks reinhängen kann und diese dann auf logischer Ebene den Partitionen hinzufügen kann. Mein Server kann 8 Festplatten fassen, dann erspar ich mir die doofe rumpartitioniererei. Ich muss mich zwar sicherlich noch in lvm reinfuchsen, aber das wird schon. Wenn alle Stricke reissen werde ich noch über ein Backup verfügen, welches ich mir per Script und Crontab dann anlegen werde.

übung macht den meister

Das sieht schon sehr gut aus. Alle Daten bis auf die boot Partitionen sind dann verschlüsselt. Als nächstes versuche ich ebenfalls die Konfiguration mit diesem decrypted-derived-script hinzukriegen.

6%.....

[Lord_Carlos]

Sofern du ECC Ram hast kann ich ZFSonLinux auch sehr empfehlen. Da hast du dann raid und Dateisystem in einem.

ZFS braucht kein ECC ram. Das ist ein alter Mythos.
ZFS ohen ECC ram ist auch nicht schlechter als andere Dateisystem ohne ECC.

Genau wie man kein 1GB ram fuer jeden 1TB ZFS Speicher braucht. Auch ein alter Mythos.

[fireburner]

Sofern du ECC Ram hast kann ich ZFSonLinux auch sehr empfehlen. Da hast du dann raid und Dateisystem in einem.

ZFS braucht kein ECC ram. Das ist ein alter Mythos.
ZFS ohen ECC ram ist auch nicht schlechter als andere Dateisystem ohne ECC.

Genau wie man kein 1GB ram fuer jeden 1TB ZFS Speicher braucht. Auch ein alter Mythos.

Ich hatte keins von beiden behauptet
Aber ZFS ist natürlich umso mehr zu empfehlen, wenn man ECC hat. Zumindest ziehe ich es dem btrfs vor (zumindest noch). Und im Zusammenspiel mit ECC RAM sind das ja die einzigen die eine konsistente Fehlerkorrektur haben

Das der RAM Verbrauch steigt, kommt sowieso nur bei deduplication vor. (habe ich noch nie getestet).

Zurück zum Thema:
Trollkirsche: Ich frage mich warum du ins raid sowohl en encrypted volume als auch ein unverschlüsseltes gelegt hat?
Mich würde übrigens rein aus Interesse der Output von

Code: Alles auswählen

lsblk

interessieren, wenn dein System fertig installiert ist.

[NAB]

Ich finde das eigentlich noch ganz gut das ich per lvm dynamisch einfach weitere Disks reinhängen kann und diese dann auf logischer Ebene den Partitionen hinzufügen kann. Mein Server kann 8 Festplatten fassen, dann erspar ich mir die doofe rumpartitioniererei. Ich muss mich zwar sicherlich noch in lvm reinfuchsen, aber das wird schon.

Es gab hier mal einen Thread ... jemand hatte sich ein großes LVM über zwei Festplatten angelegt. Eine Platte war ihm abgeraucht. Seine Frage war, wie er an die restlichen Daten auf der zweiten Platte rankommt. Antwort: gar nicht.

LVM ist in dieser Konfiguration genauso fragil wie ein Raid0.

Nun machst du alles richtig, du legst ein Raid1 darunter, landest dann also bei der Sicherheit eines Raid10. Wenn du das LVM erweiterst, sollte da dann auch ein Raid1 drunterliegen - logisch, oder? Und Backups sind natürlich auch eine gute Idee.

Als nächstes versuche ich ebenfalls die Konfiguration mit diesem decrypted-derived-script hinzukriegen.

Lies "man crypttab"! Von Stretch!

Insbesondere die Abschnitte zu "keyscript" und "initramfs". Du musst die Option "initramfs" mit angeben, sonst funktioniert es nicht. Dieser Hinweis fehlt in sämtlichen Tutorials, die vor Stretch geschrieben wurden.

[fireburner]

...
Nun machst du alles richtig, du legst ein Raid1 darunter, landest dann also bei der Sicherheit eines Raid10. Wenn du das LVM erweiterst, sollte da dann auch ein Raid1 drunterliegen - logisch, oder? Und Backups sind natürlich auch eine gute Idee.

Nein. Durch LVM wird aus einem Raid 1 kein Raid10. Es bleibt Raid1.

[NAB]

Nein. Durch LVM wird aus einem Raid 1 kein Raid10. Es bleibt Raid1.

Ja, natürlich. Das habe ich auch nicht behauptet. Ich sprach von der "Sicherheit eines Raid10". Bei einem Raid10 darf eine Platte ausfallen. Bei einem Raid0 nicht.

[Trollkirsche]

Halli hallo,

Sodele das System steht. Beide 8 TB Festplatten werden nun über Raid1 SW eingebunden. Die Systempartitionen habe ich über eine weitere Volume Group eingebunden, ebenfalls LVM. Somit ist nun das gesamte System verschlüsselt.

Gestern abend habe ich noch eine 1 TB Platte fürs Image Backup präpariert, heisst mit dd, 0en überschrieben. Heute werde ich ein Image des Systems per Clonezilla anlegen und auf der 1 TB backuppen.

Ich habe noch 2x4TB USB Platten fürs Backup. Es werden also jeweils 2x4TB Backups für die Daten angelegt und noch 2x1TB für die Images der wichtigsten Systeme. Vielleicht hol ich mir dann noch paar grössere Platten fürs Backup später, man weiss ja nie, gerade da LVM für mich neu ist.

Sobald das Image Backup steht werde ich mich an das Script heranarbeiten, welches das PW für Luks nachberechnen kann.

Ich halte euch selbstverständlich weiterhin auf dem Laufenden

Bis dann und danke nochmal!

[NAB]

Sobald das Image Backup steht werde ich mich an das Script heranarbeiten, welches das PW für Luks nachberechnen kann.

Für "decrypt_derived" sieht der Gedanken folgendermaßen aus: du legst ein zweites Passwort in einem zweiten "Key Slot" an. Dieses Passwort ist unverschämt lang und kryptisch und wird automatisch aus dem ersten (entschlüsselten) Crypt-Container generiert. Du kannst es dir also nicht aussuchen.