Probleme mit RAID 1 - HW und SW

[Trollkirsche]

Hallo,

Ich habe hier mein NAS Server mit 2 8TB Festplatten rumstehen. Nun wollte ich zum ersten mal Raid1 einsetzen. Ich habe dies auf 2 Arten probiert. Einmal die Hardware Variante mit Bios. Dann noch den Linux Debian SW Raid, den man bei der Installation konfigurieren kann.

HW Raid:
Ich stelle im Bios die Storage Art auf RAID um. Anschliessend speichere ich die Bios Einstellungen, gehe in das Bios untermenu per Ctrl+I und erstelle ein Volume, dass den maximal verfügbaren Platz (6.9 TB) verwendet. Soweit so gut.

Nun starte ich von USB das Setup der neuste testing distro "Buster". Im Bootmenu gehe ich auf edit und füge "dmraid=true" hinzu, dort wo der eintrag mit --quiet steht.

Ich gehe die ganzen Setup Punkte durch und komme anschliessend zur Partitionierung. Hier sehe ich dann auch den Eintrag. Das Problem : Wenn ich eine neue Partitionstabelle des Gerätes herstelle, kann ich max. eine 1 TB erstellen, nicht 6.9, wie der Maximalspeicher im Bios noch angezeigt wurde.

Was mache ich falsch?

Wie muss ich genau vorgehen, damit ich ein HW Raid 1 System unter Linux zum Laufen bringe?

SW Raid:
Hier klappt alles, Server startet mit den Einstellungen.
Frage : Ist das normal das die Platten unentwegt drehen? Das macht mir ehrlich gesagt etwas Angst und ich frage mich, wie lange sie wohl brauchen bis sie bei der Last einfach abrauchen. Ich habe keine Erfahrung mit Raid, doch die permanente rödelei der Platten ist besorgniserregend und ich frage mich, ob das normal ist.

Ist zwar schade, aber ich will das meinen Platten nicht antun und habe mir überlegt, wohl oder übel ein kleines Script per crontab anzustossen, welche die 2 Platten per rsync abgleicht. Das ist für die Platten wohl sicher schonender..

Was meint ihr zu der ganzen Sache? Warum kann ich im HW Raid, welches ich bevorzugen würde, nur eine Partition von 1TB erzeugen, obwohl doch im Bios 6.9 TB angezeigt werden? Fehler von Linux selbst, da ich die neuste Distro verwende? Bin ich da evtl. falsch rangegangen? Wenn ja, was muss ich beachten, habt ihr evtl. einen Guide wie man dies unter Debian korrekt einrichtet? Drehen im HW Raid1 Modus die Festplatten auch wie blöde?

Vielen Dank für eure Hilfe.

[NAB]

Was mache ich falsch?

Du vermutest, dass auf deinem Mainbord ein Hardwareraid ist. Ich gehe davon aus, dass es ein proprietäres Softwareraid ist. Du brauchst dafür einen Linux-Treiber.

Wie muss ich genau vorgehen, damit ich ein HW Raid 1 System unter Linux zum Laufen bringe?

Dir ein Hardwareraid kaufen.

SW Raid:
Hier klappt alles, Server startet mit den Einstellungen.
Frage : Ist das normal das die Platten unentwegt drehen? Das macht mir ehrlich gesagt etwas Angst und ich frage mich, wie lange sie wohl brauchen bis sie bei der Last einfach abrauchen. Ich habe keine Erfahrung mit Raid, doch die permanente rödelei der Platten ist besorgniserregend und ich frage mich, ob das normal ist.

Fragst du dich oder uns?
Was meinst du mit "drehen"? Dass Festplatten sich drehen ist normal, ja. Irgendwann, nach Stunden ohne Zugriff fahren sie in den Standby. Dieser Zustand wird auf der Linux Systemplatte mitunter nie erreicht.

Oder meinst du permanente Zugriffe? Nein, das ist nicht normal. Das ist allerdings in den ersten Stunden normal, wenn der Kernel das Raid1 synchronisiert. Linux ist so blöd, dass es noch nicht mal weiß, dass du noch keine Daten auf dem Array hast, deswegen kopiert es geflissentlich Datenmüll von der einen Platte auf den Spiegel, jedes einzelne Bit.

Den Vorgang kannst du verfolgen mit

Code: Alles auswählen

cat /proc/mdstat

falls er noch läuft.

[Trollkirsche]

Was mache ich falsch?

Du vermutest, dass auf deinem Mainbord ein Hardwareraid ist. Ich gehe davon aus, dass es ein proprietäres Softwareraid ist. Du brauchst dafür einen Linux-Treiber.

Wie muss ich genau vorgehen, damit ich ein HW Raid 1 System unter Linux zum Laufen bringe?

Dir ein Hardwareraid kaufen.

SW Raid:
Hier klappt alles, Server startet mit den Einstellungen.
Frage : Ist das normal das die Platten unentwegt drehen? Das macht mir ehrlich gesagt etwas Angst und ich frage mich, wie lange sie wohl brauchen bis sie bei der Last einfach abrauchen. Ich habe keine Erfahrung mit Raid, doch die permanente rödelei der Platten ist besorgniserregend und ich frage mich, ob das normal ist.

Fragst du dich oder uns?
Was meinst du mit "drehen"? Dass Festplatten sich drehen ist normal, ja. Irgendwann, nach Stunden ohne Zugriff fahren sie in den Standby. Dieser Zustand wird auf der Linux Systemplatte mitunter nie erreicht.

Oder meinst du permanente Zugriffe? Nein, das ist nicht normal. Das ist allerdings in den ersten Stunden normal, wenn der Kernel das Raid1 synchronisiert. Linux ist so blöd, dass es noch nicht mal weiß, dass du noch keine Daten auf dem Array hast, deswegen kopiert es geflissentlich Datenmüll von der einen Platte auf den Spiegel, jedes einzelne Bit.

Den Vorgang kannst du verfolgen mit

Code: Alles auswählen

cat /proc/mdstat

falls er noch läuft.

Okay, gut das mit der erstmaligen Synchronisation der Partitionen mittels Software Raid zu wissen. D.h. nach ein paar Stunden sollte sich die Schreiberei legen. Danke dir.

Auf welche Variante sollte man generell setzen? Ich nehme mal an das das Raid aus dem Bios effizienter ist als der Linuxeigene Raid?

Dies hier ist mein Mainboard : http://www.asrockrack.com/general/produ ... C236M%20WS

Benötige ich in dem Falle noch Treiber falls ich das BIOS Raid verwenden möchte? Wenn ja, wie kann ich diese in das Linux Setup implementieren? Ich hatte zwar Probleme noch mit einer weiteren Firmware (M2 SSD), das ich jedoch mit dem nachinstallieren des Pakets misc-nonfree-firmware beheben konnte.

Ich kriege beim Boot auch noch irgendwelche ACPI Fehlermeldungen:
ACPI Error [DSSP] Namespace lookup failure, AE NOT_FOUND (20170728/psargs-364)
Error method parse/executeion failes \_SB.PCI0.SAT0.PRT3._STF, AE_NOT_FOUND

Entstehen diese Fehlermeldungen aufgrund des von dir benannten, fehlenden Treibers?

[Trollkirsche]

Ich seh grad das MSI auf ihrer HP gar keine Linux Treiber für RAID anbietet. Sämtliche Treiber sind für Windows...

Im Bios sehe ich noch folgende Einstellung unter Storage Sektion :
Launch Storage OpRom Policy : Steht zurzeit auf [Legacy only]

Steht die Funktion im Bezug zum Raid?

Ich habe nochmal zum Schauen auf Bios RAID umgestellt...in der Partitionierungssektion des Debian Installers sehe ich zwar die M.2 SSD, aber nicht die 2 8TB WD Red Platten.

Weiss einer, warum?

[fireburner]

Ich würde grundsätzlich immer zu einem SW Rais raten und zwar aus folgenden Gründen:
-geht dir beim HW Raid das Board oder der Controller kaput, kann es mitunter schwierig sein, das du dann mit einem neuen deine Daten wieder bekommst. Beim SW Raid kannst du Platten in jeden anderen Rechner stecken und dort initialisieren. Bei MDADM bin ich mir jetzt nicht sicher, ob da nicht dazu der Header gebackupt werden sollte.
-HW Raids bestehen meist aus irgendeiner proprietären Lösung und können mal besser und mal schlechter sein. ich würde dem aber keine wichtigen Daten überlassen. MDADM dagegebn ist eine freie SW Raid Lösung, wo du theoretisch genau nachvollziehen könntest wie das deine Daten managed.
-ein HW Raid bekommt wenn überhaupt kaum/keine fixes. Wenn dagegen im Code von MDADM Fehler auftauchen, können diese sehr schnell und einfach gepatched werden.

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

[NAB]

Auf welche Variante sollte man generell setzen? Ich nehme mal an das das Raid aus dem Bios effizienter ist als der Linuxeigene Raid?

Effizienter? Was soll da denn effizienter werden? Du betreibst olle mechanische Festplatten an Sata600 Ports. Dein Raid ist die meiste Zeit damit beschäftigt darauf zu warten, dass deine Platten endlich mal ein paar Byte rausrücken oder wegschreiben. Und bei der Energieffizienz bist du ohne zusätzliches Hardwareraid auch besser dran.

Der hier hat das ganz gut zusammengefasst:
http://www.tomshardware.co.uk/forum/id- ... apter.html
fireburner geht in die gleiche Richtung.

Dies hier ist mein Mainboard : https://us.msi.com/Motherboard/C236M-WO ... N/Overview

Geil ... MSI wird immer schlimmer ... für ihren Content brauchen sie die eine Klaut, für ihr Usertracking die andere Klaut ^^
Ich seh da nichts von "Hardware-Raid". Da ist auch kein Chip auf dem Mainboard, der Hardwareraid implementieren könnte. Da ist nur ein ganz normaler Intel C236 drauf, mit seinen 6 Sata-Ports. Intel implementiert Raid über seinen RST-Treiber (Hinweis: das ist Software!).

Ich kriege beim Boot auch noch irgendwelche ACPI Fehlermeldungen:
ACPI Error [DSSP] Namespace lookup failure, AE NOT_FOUND (20170728/psargs-364)
Error method parse/executeion failes \_SB.PCI0.SAT0.PRT3._STF, AE_NOT_FOUND

Entstehen diese Fehlermeldungen aufgrund des von dir benannten, fehlenden Treibers?

Nein, die entstehen weil MSI sein BIOS nicht gebacken kriegt. Mein billigst-MSI-Board wirft die gleichen Fehler. Schau mal nach einem BIOS-Update.

Im Bios sehe ich noch folgende Einstellung unter Storage Sektion :
Launch Storage OpRom Policy : Steht zurzeit auf [Legacy only]

Steht die Funktion im Bezug zum Raid?

Nein, die stehen im Zusammenhang mit BIOS- vs. UEFI-Boot.

Hier findest du Hinweise von Intel, welchen Treiber du unter Linux statt dem Intel RST für deinen Intel C236 benutzen sollst:
https://www.intel.com/content/dam/www/p ... -paper.pdf

[Trollkirsche]

Hallo ihr beiden,

Ihr seid echt super, habt mir sehr gut geholfen!

Ich habe leider das falsche Board gepostet. Hier das richtige :
http://www.asrockrack.com/general/produ ... ifications

Ich habs oben korrigiert. Sry.

Auch ein danke für die Hilfe mit dem Fehler. Habe auch gerade geschaut ob ich das Board updaten kann. Die aktuelle UEFI Version ist bei mir 2.10, die zweitälteste. das neuste Update hat ver 2.60. Mein Board scheint also ziemlich aktuell zu sein.

Ich bin da noch ziemlich vorsichtig mit flashen, habe mir mal so ein Board zerschossen..

Wie gravierend ist der Fehler der erscheint genau? Gibt es irgendwelche Auswirkungen, die ich im Betrieb des NAS Servers beachten müsste aufgrund des Errors?

Ok, sehr gut das alles über HW und SW Raid zu wissen. Ich werde in dem Falle auf eine SW Raid setzen. Die Vorteile die ihr aufzählt sind nicht zu verachten.

Was mich ein bisschen irritiert ist, dass ich die 3TB FAT32 Partition, die ich für multimedia zeugs geplant hatte, nicht benennen kann, wohingegen die ext4 partitionen klar benannt sind. Gibt es die Möglichkeit noch einen Namen zu setzen für FAT32 Partitionen? Warum wird NTFS nicht unterstützt?

Dann kann ich im Grunde jetzt starten mit der sauberen Installation des Servers.

Danke vielmal !

[NAB]

Tja, auch beim neuen Board kann ich kein Hardware-Raid entdecken. Selbst wenn du es benutzen wolltest - du hast keins.

Wie gravierend ist der Fehler der erscheint genau? Gibt es irgendwelche Auswirkungen, die ich im Betrieb des NAS Servers beachten müsste aufgrund des Errors?

Wie gesagt, ich hab die gleichen Fehler, und bisher keine Probleme feststellen können. Allerdings ist das auch kein NAS sondern eine simple Bürokiste. So recht schlau werd ich aus der Meldung auch nicht ... "SB.PCI0.SAT0.PRT3" hat irgendwas mit einer Festplatte zu tun, für die das BIOS wohl keine ACPI-Tabelle angelegt hat. Bisher bin ich der Meinung, dass es schnurz-egal ist und kein BIOS-Update rechtfertigt.

FAT auf 3TB? Hast du dir das gut überlegt? FAT ist uralt, da gibt's Dateigrößenbegrenzungen. Und warum? Wenn es ein NAS ist, greift Windows doch über Samba zu.

NTFS wird unterstützt, aber anscheinend nicht im Installer? Bin nie auf die Idee gekommen, das auszuprobieren. Du müsstest dir die Partition dann eigenhändig zu NTFS umformatieren und den Eintrag in der /etc/fstab anpassen ... wenn es wirklich NTFS sein soll.

[Trollkirsche]

Tja, auch beim neuen Board kann ich kein Hardware-Raid entdecken. Selbst wenn du es benutzen wolltest - du hast keins.

Wie gravierend ist der Fehler der erscheint genau? Gibt es irgendwelche Auswirkungen, die ich im Betrieb des NAS Servers beachten müsste aufgrund des Errors?

Wie gesagt, ich hab die gleichen Fehler, und bisher keine Probleme feststellen können. Allerdings ist das auch kein NAS sondern eine simple Bürokiste. So recht schlau werd ich aus der Meldung auch nicht ... "SB.PCI0.SAT0.PRT3" hat irgendwas mit einer Festplatte zu tun, für die das BIOS wohl keine ACPI-Tabelle angelegt hat. Bisher bin ich der Meinung, dass es schnurz-egal ist und kein BIOS-Update rechtfertigt.

FAT auf 3TB? Hast du dir das gut überlegt? FAT ist uralt, da gibt's Dateigrößenbegrenzungen. Und warum? Wenn es ein NAS ist, greift Windows doch über Samba zu.

NTFS wird unterstützt, aber anscheinend nicht im Installer? Bin nie auf die Idee gekommen, das auszuprobieren. Du müsstest dir die Partition dann eigenhändig zu NTFS umformatieren und den Eintrag in der /etc/fstab anpassen ... wenn es wirklich NTFS sein soll.

Ja ich belass es mal mit dem Fehler, wenn ich die Zeit finde melde ich mich mal bei MSI direkt und sprich sie darauf an.

Das ist mein erster Server, daher habe ich auch noch keine Erfahrung mit Samba, das war aber definitiv geplant. In dem Falle wird daraus natürlich eine ext4 Partition. Samba wär gleich nach der Installation des Servers gekommen, NFS ebenfalls

Das mit dem umformatieren klingt interessant und ich werde mich definitiv noch tiefer in das software raid (mdadm(?) einlesen. Für den Anfang belass ichs mal so und installier für den Windows Zugriff, wie von dir empfohlen, ext4.

Danke nochmal für die Hilfe!

[fireburner]

Ohne jetzt zu prüfen, ob das alles noch aktuell ist, wäre das hier bestimmt als Anfang zu mdadm zu empfehlen: https://wiki.debianforum.de/Software-RAID_Level_1
Ich selbst habe leider keine Erfahrung mit mdadm.

[Trollkirsche]

Link ist in den Favoriten

Ich nehme mal an es ist für Debian performancetechnisch keine Probleme, wenn ich eine im raid volume befindliche, verschlüsselte Partition erstelle?

Liege ich da richtig?

[NAB]

Ja ich belass es mal mit dem Fehler, wenn ich die Zeit finde melde ich mich mal bei MSI direkt und sprich sie darauf an.

Na, die werden gucken, wenn du ihnen mit einem ASRock-Mainboard kommst

Für den Anfang belass ichs mal so und installier für den Windows Zugriff, wie von dir empfohlen, ext4.

Eh ... hab ich? Eh, nein! Das habe ich nicht "empfohlen".

Wenn Windows (auch) direkt auf dem Server laufen soll, wird es mit ext4 nicht viel anfangen können.

Wenn Windows per Netzwerk auf die Mediendateien(?) zugreifen soll, dann wäre ext4 genau richtig. Samba zaubert dir darauf ein virtuelles Dateisystem namens CIFS mit dem Windows über das Netzwerk prima umgehen kann.

Zu mdadm musst du nicht mehr viel wissen ... das läuft einfach. Du solltest noch eine Bitmap erstellen:
https://blog.chr.istoph.de/mdadm-bitmap-erstellen/
das beschleunigt die Wiederherstellung im Fehlerfall erheblich.
Das gemeine an mdadm ist eher, dass es einfach funktioniert. Auch wenn eine Platte ausfällt, merkst du nichts davon ... es leuchtet keine Warnlampe auf dem Desktop. Eine Mail-Benachrichtigung oder ein regelmäßiger Blick auf /proc/mdstat kann also nicht schaden.

Im Link von fireburner finde ich den Hinweis auf "Bootloader und Partitionstabelle kopieren:" bedenklich. Erstens hat das nichts mit Raid zu tun, zweitens geht das je nach Partitionstabelle und Bootloader völlig schief.

Ansonsten ist die Samba-Konfiguration erst mal viel spannender.

Tipp: wenn es Medien-Archive sind, also z.B. einfach deine Film- und Musiksammlung, dann lege eine Nur-Lesen-Freigabe dafür an. Dann kann der nächste Windows-Cryptotrojaner deine Filme zwar angucken aber nicht verschlüsseln.

Ich nehme mal an es ist für Debian performancetechnisch keine Probleme, wenn ich eine im raid volume befindliche, verschlüsselte Partition erstelle?

Ehhhh ....
Also was die Verschlüsselung angeht, ist das performancetechnisch die beste Lösung ... wenn du Verschlüsselung haben willst. Verschlüsselung geht natürlich immer etwas auf die Performance - ich vermute, du wirst mit deinen "lahmen" Platten keinen Unterschied merken.

Was das "Partition erstellen" angeht ... willst du auf "/dev/md0" mehrere Partitionen erstellen, so mit gparted? Und eine davon verschlüsseln? Das geht, ist aber unüblich. Ich weiß nicht, ob du sie dann noch einfach über die fstab mounten kannst. Das könnte Gefrickel werden.

Wenn du damit meinst, im Raid einen verschlüsselten Container zu erstellen - ja, das geht, das machst du mit etwas Handarbeit am besten gleich im Debian Installer. Das ist die übliche Methode. Das nennt man dann halt "Container" und nicht "Partition". Dann ist das gesamte Raid verschlüsselt. Den Container kannst du entweder mit ext4 formatieren, oder "Logical Volumes" erstellen - das ist so ähnlich wie "Partitionen" - und diese wiederum mit ext4 formatieren. Auch das geht alles manuell direkt über den Debian-Installer.

[Trollkirsche]

Ja ich belass es mal mit dem Fehler, wenn ich die Zeit finde melde ich mich mal bei MSI direkt und sprich sie darauf an.

Na, die werden gucken, wenn du ihnen mit einem ASRock-Mainboard kommst

Für den Anfang belass ichs mal so und installier für den Windows Zugriff, wie von dir empfohlen, ext4.

Eh ... hab ich? Eh, nein! Das habe ich nicht "empfohlen".

Wenn Windows (auch) direkt auf dem Server laufen soll, wird es mit ext4 nicht viel anfangen können.

Wenn Windows per Netzwerk auf die Mediendateien(?) zugreifen soll, dann wäre ext4 genau richtig. Samba zaubert dir darauf ein virtuelles Dateisystem namens CIFS mit dem Windows über das Netzwerk prima umgehen kann.

Zu mdadm musst du nicht mehr viel wissen ... das läuft einfach. Du solltest noch eine Bitmap erstellen:
https://blog.chr.istoph.de/mdadm-bitmap-erstellen/
das beschleunigt die Wiederherstellung im Fehlerfall erheblich.
Das gemeine an mdadm ist eher, dass es einfach funktioniert. Auch wenn eine Platte ausfällt, merkst du nichts davon ... es leuchtet keine Warnlampe auf dem Desktop. Eine Mail-Benachrichtigung oder ein regelmäßiger Blick auf /proc/mdstat kann also nicht schaden.

Im Link von fireburner finde ich den Hinweis auf "Bootloader und Partitionstabelle kopieren:" bedenklich. Erstens hat das nichts mit Raid zu tun, zweitens geht das je nach Partitionstabelle und Bootloader völlig schief.

Ansonsten ist die Samba-Konfiguration erst mal viel spannender.

Tipp: wenn es Medien-Archive sind, also z.B. einfach deine Film- und Musiksammlung, dann lege eine Nur-Lesen-Freigabe dafür an. Dann kann der nächste Windows-Cryptotrojaner deine Filme zwar angucken aber nicht verschlüsseln.

Ich nehme mal an es ist für Debian performancetechnisch keine Probleme, wenn ich eine im raid volume befindliche, verschlüsselte Partition erstelle?

Ehhhh ....
Also was die Verschlüsselung angeht, ist das performancetechnisch die beste Lösung ... wenn du Verschlüsselung haben willst. Verschlüsselung geht natürlich immer etwas auf die Performance - ich vermute, du wirst mit deinen "lahmen" Platten keinen Unterschied merken.

Was das "Partition erstellen" angeht ... willst du auf "/dev/md0" mehrere Partitionen erstellen, so mit gparted? Und eine davon verschlüsseln? Das geht, ist aber unüblich. Ich weiß nicht, ob du sie dann noch einfach über die fstab mounten kannst. Das könnte Gefrickel werden.

Wenn du damit meinst, im Raid einen verschlüsselten Container zu erstellen - ja, das geht, das machst du mit etwas Handarbeit am besten gleich im Debian Installer. Das ist die übliche Methode. Das nennt man dann halt "Container" und nicht "Partition". Dann ist das gesamte Raid verschlüsselt. Den Container kannst du entweder mit ext4 formatieren, oder "Logical Volumes" erstellen - das ist so ähnlich wie "Partitionen" - und diese wiederum mit ext4 formatieren. Auch das geht alles manuell direkt über den Debian-Installer.

Na, die werden gucken, wenn du ihnen mit einem ASRock-Mainboard kommst

Stimmt lol

Nein das wird schon ein reiner Linux Server, da kommt kein Windows drauf. Ich möchte gern noch per KVM virtualisieren aber auch das werden nur Linux Distros. Von dem her ist ext4 für eine Partition, auf die mein Game PC dann zugreift perfekt. Das finde ich wirklich genial, wusste gar nicht das das geht. Ich ging bisher immer davon aus, dass die Partition, auf die Windows zugreift, ebenfalls vom Typ NTFS oder Fat32 sein muss.

Ich werde deinen Tipp beherzigen und die Partition per fstab im "ro" modus laufen lassen.

Nein ich werde nicht mit gparted formatieren. Alles wird direkt im Debian installer erledigt (die gesamte Partitionierung, die Erstellung der RAID Volumes, Raid-Konfiguration, die Erstellung der verschlüsselten physikalischen Volumes und der darin befindlichen Partitionen, boot partition, efi partition, swap usw.)

Das System wird auf eine verschlüsselte Partition auf der M.2 SSD 500 GB installiert, dort werden auch die VM auf einer verschlüsselten partition liegen. Sämtliche Daten kommen auf die 2 8TB Festplatten. Auch hier ist die ein oder andere Partition verschlüsselt.

Es werden aus Sicherheitsgründen keine Dateischlüssel hinterlegt. D.h. man muss paarmal zu Beginn das luks PW eingeben, hat aber den Vorteil das nichts auslesbar ist.

Weitere Vorschläge der Optimierung nehme ich liebend gern entgegen

[NAB]

Ich werde deinen Tipp beherzigen und die Partition per fstab im "ro" modus laufen lassen.

Nein! Das machst du per Samba, in der Definition der Freigabe. Such dir mal ein symphatisches Samba-Tutorial (für Samba4, nicht das alte Samba3), da wird das erklärt.

Alles wird direkt im Debian installer erledigt

Gute Idee! Dann läuft's nachher wenigstens auch reibungslos

Sämtliche Daten kommen auf die 2 8TB Festplatten. Auch hier ist die ein oder andere Partition verschlüsselt.

Das wird ne kleine Konfigurationsorgie im Debianinstaller. Stell dich darauf ein, dass du mehrere Anläufe brauchst, bis das so sitzt wie du es haben willst. Diese "Partitionen" legst du nicht als Partition an sondern du willst den gesamten Inhalt des Raid1 für "lvm" nutzen. Im lvm legst du dann einzelne "volumes" an. Einige dieser Volumes willst du dann noch verschlüsseln.

[Trollkirsche]

Ich werde deinen Tipp beherzigen und die Partition per fstab im "ro" modus laufen lassen.

Nein! Das machst du per Samba, in der Definition der Freigabe. Such dir mal ein symphatisches Samba-Tutorial (für Samba4, nicht das alte Samba3), da wird das erklärt.

Alles wird direkt im Debian installer erledigt

Gute Idee! Dann läuft's nachher wenigstens auch reibungslos

Sämtliche Daten kommen auf die 2 8TB Festplatten. Auch hier ist die ein oder andere Partition verschlüsselt.

Das wird ne kleine Konfigurationsorgie im Debianinstaller. Stell dich darauf ein, dass du mehrere Anläufe brauchst, bis das so sitzt wie du es haben willst. Diese "Partitionen" legst du nicht als Partition an sondern du willst den gesamten Inhalt des Raid1 für "lvm" nutzen. Im lvm legst du dann einzelne "volumes" an. Einige dieser Volumes willst du dann noch verschlüsseln.

Ok. Ich hab hier 1-2 Administrationsbücher rumstehen, Samba und Freigabe kommt gleich als nächstes, freu mich schon drauf Samba beherrschen zu lernen.

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?

Das ganze Partitionierungszeug läuft sonst tadellos. Man muss vor allem beachten, dass die Verschlüsselungskonfiguration ganz am Ende durchgeführt wird, im Falle das man in den Raid Volumes ebenfalls verschlüsselte Partitionen besitzt. Wichtig ist, dass die ganze Verschlüsselungskonfiguration nur in einem Male durchgeführt werden kann, sonst kanns zu Problemen kommen. Deshalb als erstes die Raid Volumes der 2 Platten erstellen, Raidkonfiguration, dann die verschlüsselten Partitionen für die Raid Volumes erstellen, Verschlüsselte Systempartitionen erstellen, Verschlüsselung konfigurieren und noch partitionen in diesen volumes erstellen. Dann kann man das System installieren.

[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!