Generelle Verständnissfrage zu RAID 1

[sidest81]

Hallo,
ich betreibe seit geraumer Zeit einen Debian 11 Server mit Software RAID1. Es läuft auch alles gut. Nur kam mir jetzt eine Frage in den Sinn, über die ich mir bislang noch überhaupt keine Gedanken gemacht habe.

Zur Situation:

Code: Alles auswählen

- Debian 11
- zwei SATA Platten /dev/sda und /dev/sdb
- diese sind wie folgt eingebunden:
  /dev/md0 mit /dev/sda1 und /dev/sdb1  
  /dev/md1 mit /dev/sda5 und /dev/sdb5  (swap)
- grub ist auf sda und sdb

Eigentlich sind es genau genommen 8 SATA Platten. Nämlich EINE /dev/sda, welche am ersten Controller (SATA1) "fest" angeschlossen ist und
sieben mal eine /dev/sdb, welche am zweiten Controller (SATA2) via Wechselrahmen angeschlossen ist. Also für Montag, Dienstag, Mittwoch... jeweils eine andere Platte.

Ich mache das, damit zum Einen die Daten als RAID gespiegelt sind und ich zusätzlich jeweils täglich eine aktuelle Spiegelung auf einer Platte habe, welche dann extern gelagert werden kann. Also schlage ich so quasi zwei Fliegen mit einer Klappe

Ich tausche also täglich die Platte (sdb) im Wechselrahmen aus und habe somit beim booten immer ein "kaputtes" RAID.

Code: Alles auswählen

cat /proc/mdstat
md1 : active (auto-read-only) raid1 sda5[2]
      3926016 blocks super 1.2 [2/1] [U_]
      
md0 : active raid1 sda1[2]
      484322304 blocks super 1.2 [2/1] [U_]
      bitmap: 4/4 pages [16KB], 65536KB chunk

Soweit alles ok. Nun zu meiner eigentlichen Frage:
Auf sda sind - da fix angeschlossen - immer die aktuellsten Daten drauf. Auf z.B. sdb -Montag sind am darauffolgenden Montag logischerweise die Daten vom Montag der Vorwoche drauf, welche nun überschrieben werden sollen.

Woher weiß ist denn aber, von welche Platte aus gebootet wurde?? Eigentlich sollte immer von sda gebootet werden, weil diese am ersten Controller hängt. Aber rein theoretisch ist auf sdb auch ein grub vorhanden und die Platte könnte auch booten. Es ist ja ein komplettes System der Vorwoche drauf. In dem Fall würde ich mir nämlich die Daten der Vorwoche von sdb auf die eigentlich aktuelle sda überschreiben.

Bisher hat das immer einwandfrei funktioniert. Heute habe ich aber folgendes gesehen:

Code: Alles auswählen

cat /proc/mdstat
md1 : active raid1 sdb5[3] sda5[2]
      3926016 blocks super 1.2 [2/1] [U_]
      [>....................]  recovery =  1.7% (68672/3926016) finish=1.8min speed=34336K/sec
      
md0 : active raid1 sdb1[3] sda1[2]
      484322304 blocks super 1.2 [2/1] [U_]
      	resync=DELAYED
      bitmap: 4/4 pages [16KB], 65536KB chunk

Hier ist nun zuerst sdb und dann erst sda aufgeführt von der Reihenfolge her; außerdem [U_] Das sagt mir doch, dass die "linke" Platte da ist und die "rechte" fehlt. Also würde sda hier gerade überspielt..?
Vor Einhängen der zweiten Platte hat er allerdings (s. oben) nur die sda erkannt und wohl auch davon gebootet. Zumindet ist meine Testdatei, welche nur auf sda war, immer noch vorhanden.
Die UUID von sda1 und sdb1 etc. sind identisch.

Wie kann ich feststellen, won welcher Platte also tatsächlich gebootet wurde. Und was hat das mit der Reihenfolge sda und sdb (=> md1 : active raid1 sdb5[3] sda5[2]) hier auf sich. Warum steht (zumindest manchmal) sdb er erster Stelle?

Danke schonmal für eure Hilfe
Simon

[cosinus]

Woher weiß ist denn aber, von welche Platte aus gebootet wurde?? Eigentlich sollte immer von sda gebootet werden, weil diese am ersten Controller hängt. Aber rein theoretisch ist auf sdb auch ein grub vorhanden und die Platte könnte auch booten. Es ist ja ein komplettes System der Vorwoche drauf. In dem Fall würde ich mir nämlich die Daten der Vorwoche von sdb auf die eigentlich aktuelle sda überschreiben.

Von welcher Platte gebootet wird, wird immer im BIOS bzw. UEFI bestimmt. In deiner RAID-Konfig sind ja auch "nur" die Partitionen, also rootfs plus swap. MBR, grub und Co befinden sich dann außerhalb der Kontrolle von mdadm. Hast du denn mal versucht von der anderen Platte zu booten? Du hast doch ein MBR-Schema, ich sehe nämlich hier nichts von einer EFI-Bootpartionen in deinem Post.

[sidest81]

Hallo,

also dann wird immer vom ersten Controller, hier also sda, gebootet und erst wenn die Platte fehlt oder defekt ist vom zweiten Controller, hier also sdb. Das ist im BIOS in der Boorteihenfolge so eingestellt. Hat auch bisher (sicher schon zwei Jahre) immer einwandfrei funktioniert.
Die sdb bootet im Fall des Falles - der zum Glück noch nie eingetreten ist - aber auch.

Mich hat nur die Reihenfolge bei

Code: Alles auswählen

cat /pro/mdstat
md1 : active raid1 sdb5[3] sda5[2]
      3926016 blocks super 1.2 [2/1] [U_]
      [>....................]  recovery =  1.7% (68672/3926016) finish=1.8min speed=34336K/sec

irritiert, weil eben hier sdb zuerst steht. Ist mir bislang halt nicht wirklich aufgefallen.

Mir geht es auch nur darum, nicht versehentlich die aktuellen Daten mit denen der Vorwoche zu überschreiben. Aber eigentlich ist es logisch, dass das BIOS bestimmt von welcher Platte gebootet wird.

Ich habe mal irgendwo gelesen, dass es wohl sein kann, dass 100000mal am SATA1 die Platte als sda bezeichnet wird und beim 100001mal dann als sdb. Kann dazu jemand was sagen?

Aktuell habe ich ein kleines Shell-Script, welches mir automatisiert die sdb ins RAID einhängt; also Paritionstabelle kopieren, ans Array anhängen... Das klappt natürlich nur, wenn sdb auch die fehlerhafte Platte im Array ist. Wenn sda aber plätzlich die fehlerhafte Platte ist und mein Script trotzdem versucht sdb als zweite Platte einzuhängen, wirft das Script logischerweise ein Fehler.

[cosinus]

also dann wird immer vom ersten Controller, hier also sda, gebootet

Wenn das so im BIOS/UEFI bei dir steht, dann ja. Selbst in recht betagter/alter Hardware, die nicht EFI-fähig ist, kann man einstellen, von welcher Platte zuerst gebootet werden soll.

und erst wenn die Platte fehlt oder defekt ist vom zweiten Controller, hier also sdb. Das ist im BIOS in der Boorteihenfolge so eingestellt. Hat auch bisher (sicher schon zwei Jahre) immer einwandfrei funktioniert.

Ja, Bootpriorität bei Festplatten.

Die sdb bootet im Fall des Falles - der zum Glück noch nie eingetreten ist - aber auch.

Mich hat nur die Reihenfolge bei [snip] irritiert, weil eben hier sdb zuerst steht. Ist mir bislang halt nicht wirklich aufgefallen.

Das würde ich ignorieren. Ich seh das bei meinem Büro-PC auch, in dem hab ich drei Platten drin: eine SSD und zwei baugleiche 4-TB-Platten. Bei fast jedem reboot tauschen die munter sda/sdb/sdc. Genau das ist der Grund dafür, die Dateisysteme in der /etc/fstab per UUID zu addressieren, nicht per /dev/sd[a-z][0-9] - bei Linux-RAID ist das eh wumpe, da wird das RAID-Laufwerk ja per /dev/md[0-9] angesprochen und mdmadm kümmert sich um den Rest.

Ich habe mal irgendwo gelesen, dass es wohl sein kann, dass 100000mal am SATA1 die Platte als sda bezeichnet wird und beim 100001mal dann als sdb. Kann dazu jemand was sagen?

Kann auch schon bei jedem (re)Boot passieren

Aktuell habe ich ein kleines Shell-Script, welches mir automatisiert die sdb ins RAID einhängt; also Paritionstabelle kopieren, ans Array anhängen... Das klappt natürlich nur, wenn sdb auch die fehlerhafte Platte im Array ist. Wenn sda aber plätzlich die fehlerhafte Platte ist und mein Script trotzdem versucht sdb als zweite Platte einzuhängen, wirft das Script logischerweise ein Fehler.

Geht mich zwar nichts an, aber ich finde du solltest dein Backup anders machen. Ich würde das RAID einfach so lassen wie es ist. Das ist für die Hochverfügbarkeit da, falls eine Disk ausfällt. Das tägliche/wöchentlich Backup kannst du per cronjob auf ein NAS oder externe Platte machen. Man kann unter Debian/Linux eigentlich auch alles im laufenden Betrieb sichern, DBs kann man vorher anhalten oder man sichert die zusätzlich anders zB mit sowas wie mysqldump. Das geht aber schon fast zu stark ins Detail

[sidest81]

Vielen Dank, Du hast meine Frage(n) beantwortet!

Mein "Fehler" ist letztlich im Shell-Script die fix eingestelle sdb als zweite RAID, was dann wohl auch mal sda oder so ein kann... Ging bisher immer gut Aber so hab ich das überhaupt erst gemerkt.

Zu Deiner Anmerkung bzgl. des Backups. Da gebe ich Dir grundsätzlich Recht. Ich hatte das auch alles mal per rsync etc. gemacht.
Es handelt sich allerdings hier um einen eher kleinen privaten Fileserver mit nicht ganz 500GB, der nur von mir genutzt wird. Hochverfügbar muss das Ding auch nicht wirklich sein. Da ist das RAID eigentlich schon überflüssig.

Für mich ist es so ganz praktisch, weil dadurch die ganzen alten Platten noch mal einen gewissen Sinn haben und ich mit einem einzigen (alten) Rechner noch mit BIOS gut hinkomme. So kann ich auf ein zusätzliches NAS etc. ganz verzichten. Un der Rechner ist auch nur dann angeschaltet, wenn ich an meinem Arbeitsplatz sitze.

Aber hier gibt es natürlich viele verschiedene Lösungen.

[cosinus]

Vielen Dank, Du hast meine Frage(n) beantwortet!

Freut mich, dass ich dir helfen konnte Hier hab ich aber ne Frage:

Mein "Fehler" ist letztlich im Shell-Script die fix eingestelle sdb als zweite RAID, was dann wohl auch mal sda oder so ein kann... Ging bisher immer gut Aber so hab ich das überhaupt erst gemerkt.

Du hattest da mit dem Script automatisch versucht, das RAID zu heilen?

[sidest81]

Du hattest da mit dem Script automatisch versucht, das RAID zu heilen?

Jein. Die Situation bei meinem Server ist ja jedesmal identisch: Platte sdb fehlt im Array. Also sind es immer dieselben Befehle die man - händisch - eingeben muss, um die "neue" Platte ins Array einzubinden. Das mache ich mit einem kleinen Shell-Script, um mir einfach die Tipparbeit zu ersparen. Mehr ist das nicht.

Keine Zauberei und funktioniert auch nur mit sdb

Code: Alles auswählen

#!/bin/sh
echo "RAID Platte wechseln"
# ggf. Partition klonen (=> fdisk -l)
# sfdisk -d /dev/sda | sfdisk --force /dev/sdb

/usr/sbin/mdadm --zero-superblock /dev/sdb1
/usr/sbin/mdadm --zero-superblock /dev/sdb5

# extra zuerst md1/sdb5, weil das schneller ist 
/usr/sbin/mdadm -a /dev/md1 /dev/sdb5
/usr/sbin/mdadm -a /dev/md0 /dev/sdb1

# zuletzt
# grub-install /dev/sda
# grub-install /dev/sdb
#
echo "watch -n 1 cat /proc/mdstat"
echo "...GRUB noch installieren..."

[cosinus]

Ui..das könnte nach hinten losgehen, wenn /dev/sdb nicht das Device ist, was du erwartest

[sidest81]

Jo, und genau das war ja eigentlich meine Frage, die mir da so gedämmert ist Hast Du aber beantwortet.

Ich muss eben nur aufpassen, dass sdb tatsächlich die Platte ist, die im Array getauscht wird oder eben mein Script mal dahingehend überarbeiten...

Zum Glück hatte ich die Zeile mit sfdisk im Script auskommentiert, weil die Partition ja immer identisch ist. Hätte ich das einkommentiert, dann gute Nacht

[cosinus]

Denk immer dran: als root hast du unglaubliche Macht alles tun zu können...aber damit auch die Pflicht, alles vorher sorgfältig zu prüfen.