Software RAID mit bestehendem System

[simmeone]

Hallo Gemeinde,

ich habe eine Frage zu meinem bestehendem System. Es handelt sich um einen kleinen Debian Server, der E-Mail-, Cloud-Zeugs, DHCP, DNS und einen Medienserver laufen hat. Aktuell ist das ganze auf nur einer SSD installiert, auf der ein wöchentliches Backup Skript läuft. Ich würde dem System gerne eine zweite Platte hinzufügen und daraus ein RAID1, mit Hilfe von mdadm, fummeln wollen.

1. Frage: geht das im Nachhinein überhaupt? Wenn ja, was muss ich eventuell beachten, vor allem, was das Booten betrifft, gibts bestimmt irgendwelche hässlichen Fallstricke.
2. Frage: bei der Gelegenheit würde ich, nachdem das Spiegeln durch ist, die alte Platte aus dem Array nehmen und gegen eine neue Platte ersetzen wollen. Funktioniert das?

Ja, ich könnte das System einfach neu aufsetzen, aber aktuell läuft es stabil und macht, was es soll. Das Ding neu aufzusetzen würde mit Sicherheit wieder einige Stunden Arbeit (eventuell auch Tage) kosten und an alle Fettnäpfchen kann ich mich mit Sicherheit nicht mehr erinnern

Hat jemand sowas schon mal gemacht? Vielen Dank an euch.

Grüße
Markus

[bluestar]

Du solltest mal deine Partitionierung und deine Bootvariante klassisch oder UEFI erläutern.

[simmeone]

Boot ist UEFI, die Partitionen sind folgende
* System /
* Log /var/log
* Home /home
* Nextcloud/nextcloud
* Swap
* Media /media

[bluestar]

Boot ist UEFI, die Partitionen sind folgende
* System /
* Log /var/log
* Home /home
* Nextcloud/nextcloud
* Swap
* Media /media

Also 6 Partitionen? Oder LVM?

[simmeone]

Partitionen sind das alles. Genau.

[heisenberg]

Zeig' mal die Ausgabe der folgenden Befehle (bitte in [c​ode] ... [/code] - Tags):

mount
lsblk

---

Ansonsten: Ja. Du kannst die ein System nachträglich über ein Rescue zu einem RAID-umbauen. Ist aber schon nicht ganz die Anfänger-Geschichte. Und in Kombination mit UEFI komme ich da selbst etwas ins schwimmen. D. h. mit UEFI habe ich das selbst so noch nicht gemacht und weiss nicht exakt die Schritte, die da durchzuführen sind.

Im Endeffekt wäre da die Reihenfolge:

1. Neue zusätzliche Platte einbauen
2. RAID-1 mit einer fehlenden Platte ("degraded") initialisieren
3. RAID partitionieren
4. Daten über rescue auf die neuen RAID-Partitionieren kopieren
5. Bootloader aktualisieren
6. Alte Platte abklemmen und schauen ob bootet.
7. Wenn es mit dem "degraded" RAID funktioniert, dann die alte Platte identisch mit der neuen Platte partitionieren: (sfdisk -d /dev/dev-neueplatte | sfdisk /dev/dev-alteplatte)
8. Alte Platte als RAID-Disk mit mdadm integrieren und synchronisieren lassen.
9. Wenn anschließend alles funktioniert, kann man bei Gelegenheit die alte Platte wieder mittels mdadm entfernen und dafür eine weitere Neue auf dem gleichen Weg integrieren.

[simmeone]

Hier lsblk output, ich sehe gerade, das sich bei den mount Punkten ein bisschen was geändert hat, da ich zusätzlich zwei Platten eingebaut habe, die im RAID1 Verbund laufen.

Code: Alles auswählen

NAME      MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sda         8:0    0 465.8G  0 disk  
├─sda1      8:1    0  48.2G  0 part  /
├─sda2      8:2    0   3.7G  0 part  [SWAP]
├─sda3      8:3    0     1K  0 part  
├─sda5      8:5    0 381.1G  0 part  
├─sda6      8:6    0  26.2G  0 part  
└─sda7      8:7    0   6.5G  0 part  /var/log
sdb         8:16   0 931.5G  0 disk  
└─md0       9:0    0 931.4G  0 raid1 
  ├─md0p1 259:0    0     1K  0 part  
  ├─md0p5 259:1    0    35G  0 part  /home
  ├─md0p6 259:2    0   600G  0 part  /owncloud
  └─md0p7 259:3    0 296.4G  0 part  /media
sdc         8:32   0 931.5G  0 disk  
└─md0       9:0    0 931.4G  0 raid1 
  ├─md0p1 259:0    0     1K  0 part  
  ├─md0p5 259:1    0    35G  0 part  /home
  ├─md0p6 259:2    0   600G  0 part  /owncloud
  └─md0p7 259:3    0 296.4G  0 part  /media

hier die mount Ausgabe

Code: Alles auswählen

sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
udev on /dev type devtmpfs (rw,nosuid,relatime,size=8104296k,nr_inodes=2026074,mode=755)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,nodev,noexec,relatime,size=1624500k,mode=755)
/dev/sda1 on / type ext4 (rw,noatime,discard,errors=remount-ro)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
cgroup2 on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate,memory_recursiveprot)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
none on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,relatime,mode=700)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=30,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=11349)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,pagesize=2M)
mqueue on /dev/mqueue type mqueue (rw,nosuid,nodev,noexec,relatime)
tracefs on /sys/kernel/tracing type tracefs (rw,nosuid,nodev,noexec,relatime)
debugfs on /sys/kernel/debug type debugfs (rw,nosuid,nodev,noexec,relatime)
sunrpc on /run/rpc_pipefs type rpc_pipefs (rw,relatime)
fusectl on /sys/fs/fuse/connections type fusectl (rw,nosuid,nodev,noexec,relatime)
configfs on /sys/kernel/config type configfs (rw,nosuid,nodev,noexec,relatime)
/dev/md0p5 on /home type ext4 (rw,noatime,discard)
/dev/md0p7 on /media type ext4 (rw,noatime,discard)
/dev/md0p6 on /owncloud type ext4 (rw,noatime,discard)
/dev/sda7 on /var/log type ext4 (rw,noatime,discard)
tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=1624496k,nr_inodes=406124,mode=700,uid=1000,gid=1000)

sda5 und sda6 werden derzeit nicht gemountet. Und ich habe noch mal geschaut, anscheinend habe ich klassische Boot-Methode verwendet.

[simmeone]

Zeig' mal die Ausgabe der folgenden Befehle (bitte in [c​ode] ... [/code] - Tags):

mount
lsblk

---

Ansonsten: Ja. Du kannst die ein System nachträglich über ein Rescue zu einem RAID-umbauen. Ist aber schon nicht ganz die Anfänger-Geschichte. Und in Kombination mit UEFI komme ich da selbst etwas ins schwimmen. D. h. mit UEFI habe ich das selbst so noch nicht gemacht und weiss nicht exakt die Schritte, die da durchzuführen sind.

Im Endeffekt wäre da die Reihenfolge:

1. Neue zusätzliche Platte einbauen
2. RAID-1 mit einer fehlenden Platte ("degraded") initialisieren
3. RAID partitionieren
4. Daten über rescue auf die neuen RAID-Partitionieren kopieren
5. Bootloader aktualisieren
6. Alte Platte abklemmen und schauen ob bootet.
7. Wenn es mit dem "degraded" RAID funktioniert, dann die alte Platte identisch mit der neuen Platte partitionieren: (sfdisk -d /dev/dev-neueplatte | sfdisk /dev/dev-alteplatte)
8. Alte Platte als RAID-Disk mit mdadm integrieren und synchronisieren lassen.
9. Wenn anschließend alles funktioniert, kann man bei Gelegenheit die alte Platte wieder mittels mdadm entfernen und dafür eine weitere Neue auf dem gleichen Weg integrieren.

Noch eine kurze Klarstellung, wenn das System mit dem degraded RAID startet, muss ich doch prinzipiell die alte Platte nicht wieder reinstöpseln, sondern kann gleich eine neue nehmen, die integrieren, oder muss ich den Weg über die alte Platte trotzdem noch machen?

[MSfree]

Noch eine kurze Klarstellung, wenn das System mit dem degraded RAID startet,

Ich halte ein RAID1 aus 2 SSD für nicht besonders sinnvoll.

SSDs verschleißen mit der Zeit (keine Panik, die halten trotzdem sehr viel aus). Bei zwei gespiegelten SSDs ist aber die Schreiblast auf beiden SSDs identisch, so daß, wenn eine SSDs ausfällt, die zweite bereits genauso verschlissen ist. Die Wahrscheinlichkeit, daß diese dann auch binnen kurzer Zeit aufällt, ist durchaus gegeben.

Wäre es nicht sinnvoller, die zweite SSD einfach einmal pro Woche per dd von der ersten SSD zu klonen? Sollte die erste ausfallen, kann man einfach von der zweiten booten, die dann deutlich weniger Schreiblast ertragen mußte als die erste. Man erspart sich damit auch die RAID-Problematik ansich, mit degrdierten Installationen und anderen damit eventuell verbundenen Problemen.

[simmeone]

Noch eine kurze Klarstellung, wenn das System mit dem degraded RAID startet,

Ich halte ein RAID1 aus 2 SSD für nicht besonders sinnvoll.

SSDs verschleißen mit der Zeit (keine Panik, die halten trotzdem sehr viel aus). Bei zwei gespiegelten SSDs ist aber die Schreiblast auf beiden SSDs identisch, so daß, wenn eine SSDs ausfällt, die zweite bereits genauso verschlissen ist. Die Wahrscheinlichkeit, daß diese dann auch binnen kurzer Zeit aufällt, ist durchaus gegeben.

Wäre es nicht sinnvoller, die zweite SSD einfach einmal pro Woche per dd von der ersten SSD zu klonen? Sollte die erste ausfallen, kann man einfach von der zweiten booten, die dann deutlich weniger Schreiblast ertragen mußte als die erste. Man erspart sich damit auch die RAID-Problematik ansich, mit degrdierten Installationen und anderen damit eventuell verbundenen Problemen.

Das ist auch eine gute Idee, das klingt sogar fast sympatischer! Cooler Einfall.

[heisenberg]

Wäre es nicht sinnvoller, die zweite SSD einfach einmal pro Woche per dd von der ersten SSD zu klonen?

Die Idee finde ich gut. Das müsste aber dann das System jeweils heruntergefahren werden und von einem anderen System gebootet werden für den dd. dd im laufenden System ist ja jetzt erst mal nicht konsistent. Wenn da noch Datenbanken im Spiel sein sollten, mutiert das andernfalls zu russisch Roulette.

D. h. dass ist entweder viel manuelle Arbeit oder etwas Scripting-Aufwand.

[MSfree]

Das müsste aber dann das System jeweils heruntergefahren werden und von einem anderen System gebootet werden für den dd.

Eventuell laufende Datenbanken, die ihre Daten auf der System-SSD halten, kann man anhalten bevor man dd startet, und hinterher wieder starten.

OK, das Dateisystem ist damit eventuell nicht ganz konsistent, aber das sollte der sowieso beim Booten laufende fsck auffangen können, wenn man im Notfall auf die zweite SSD zurückgreifen muß.

Man könnte auch einfach eine erste Kopie mit dd anlegen und im weiteren Verlauf mit rsync die zweite SSD aktuell halten.

[simmeone]

Ich habe damals das System auch mittels dd auf eine neue SSD kopiert und las vorher, dass der dd Befehl nur beim einem heruntergefahrenem System sauber funktioniert.
Die Idee, eine Grundkopie mittels dd zu erstellen und alles andere mit rsync über einen cron Job zu erledigen, klingt für mich recht charmant. Ich glaube, den Gedanken werde ich weiterverfolgen. Vielen Dank für die guten Ideen.

[MSfree]

Ich habe damals das System auch mittels dd auf eine neue SSD kopiert und las vorher, dass der dd Befehl nur beim einem heruntergefahrenem System sauber funktioniert.

Das Problem mi dd ist, daß sich das Quellmedium verändern kann, während auf das Zielmedium geschrieben wird. Man hat also unter Umständen eine nicht konsistente Kopie auf dem Zielmedium, was zuerst mal das Dateisystem betrifft. Diese Unstimmigkeiten lassen sich aber mit dem Dateisystemcheck, der beim Booten ausgeführt wird, beheben. Anders sieht es allerdings z.B. mit Datenbanke aus, aber die könnte man vorher anhalten.

Die Idee, eine Grundkopie mittels dd zu erstellen und alles andere mit rsync über einen cron Job zu erledigen, klingt für mich recht charmant.

Ich würde die Ziel-SSD nicht dauerhaft mounten, damit nichts versucht, versehentlich drauf zu schreiben. Ich würde das in einem Script einrichten, das

• die Partition(en) der Ziel-SSD mountet
• rsync ausführt
• und zuletzt die Partition(en) der Ziel-SSD wieder unmountet.

Du könntest dann im ungemounteten Zustand sogar eine Kopie mit dd auf eine dritte SSD ziehen. Diese könnte man in einem zweiten Rechner auf Funktionalität testen.

[simmeone]

Ich habe damals das System auch mittels dd auf eine neue SSD kopiert und las vorher, dass der dd Befehl nur beim einem heruntergefahrenem System sauber funktioniert.

Das Problem mi dd ist, daß sich das Quellmedium verändern kann, während auf das Zielmedium geschrieben wird. Man hat also unter Umständen eine nicht konsistente Kopie auf dem Zielmedium, was zuerst mal das Dateisystem betrifft. Diese Unstimmigkeiten lassen sich aber mit dem Dateisystemcheck, der beim Booten ausgeführt wird, beheben. Anders sieht es allerdings z.B. mit Datenbanke aus, aber die könnte man vorher anhalten.

Die Idee, eine Grundkopie mittels dd zu erstellen und alles andere mit rsync über einen cron Job zu erledigen, klingt für mich recht charmant.

Ich würde die Ziel-SSD nicht dauerhaft mounten, damit nichts versucht, versehentlich drauf zu schreiben. Ich würde das in einem Script einrichten, das

• die Partition(en) der Ziel-SSD mountet
• rsync ausführt
• und zuletzt die Partition(en) der Ziel-SSD wieder unmountet.

Du könntest dann im ungemounteten Zustand sogar eine Kopie mit dd auf eine dritte SSD ziehen. Diese könnte man in einem zweiten Rechner auf Funktionalität testen.

Klingt nach einem Plan, den ich so umsetzen werde!

[heisenberg]

Kann natürlich auch sein, dass das für den vorliegenden Fall tut und das vielleicht auch für den Rest des PC-Lebens hier.

Ich würde es selbst aber trotzdem ohne weitere Massnahmen nicht so machen. Ich finde die Vorgehensweise mit dd im laufenden Betrieb grundsätzlich nicht gut. Das ist inkonsistent und das schreit gerade danach, dass das unvorhergesehenerweise in der Zukunft mit irgendwelcher Software mal Probleme machen könnte, oder dass man das schlicht bei irgendwas vergisst und nicht berücksichtigt.

Wenn es zusätzlich noch eine separate Datensicherung gibt, die alles wesentliche einbezieht (Dateien per rsync, DB-Dumps, ... ) und an einem anderen Ort sichert und dieses dd nur dafür da ist, dass, wenn die primäre SSD ausfällt, halt die zweite benutzt wird, dann wäre das für mich ok. Wenn das halt aus irgend einem Grund dann nicht funktioniert oder das resultierende System nicht sauber läuft, dann installiert/konfiguriert man halt neu und spielt die Nutzdaten vom Backup ein.