Corona hat mich erwischt, mit mäßigen Auswirkungen. Und die M2 SSD in meinem Server ist „geplatzt“, mit deutlichen Auswirkungen. Und eine der beiden HDDs im RAID sagt ihren nahenden Tod via S.M.A.R.T.-Warnung voraus – zumindest das soll ohne Auswirkungen bleiben.
Eine unwillkommene Gelegenheit also dem RAID 1 zu unverminderter Stabilität (und mehr Kapazität) durch den Tausch beider Festplatten gegen neue zu verhelfen. Und da dies nicht das erste Mal ist und sicher auch nicht das letzte Mal sein wird, diesmal mit Mitschrift.
Ausgangsituation
Mein Heim-Server verwendet (aktuell) Ubuntu 22.04 Server als Betriebssystem. Die beiden 2,5″ Seagate Barracuda Festplatten sind als /dev/sda und /dev/sdb eingebunden. Sie wurden aus dem inzwischen verkauften ASRock Desk Mini in den neuen 19″-Server übernommen.
Via Linux Software RAID wird ein RAID 1 /dev/md0 über die beiden Platten realisiert. Das ASUS A320I Mainboard unterstützt hot-plug, d.h. die Platten können im laufenden Betrieb abgezogen oder angesteckt werden.
Der Wechsel der Festplatten wird im laufenden Betrieb stattfinden. Ich beuge Datenverlusten durch regelmäßige, ausgelagerte und geprüfte Backups mit Borgmatic vor.
Warnung
Die im folgenden beschriebenen Schritte sind auf meine Hard- und Software-Konstellation ausgerichtet und haben dort fehlerfrei funktioniert. Dennoch kann selbst bei korrekter Ausführung das Risiko des Datenverlusts niemals ganz ausgeschlossen werden.
Das Nachvollziehen der hier beschriebenen Schritte geschieht auf eigene Gefahr!
Festplatte aus RAID entfernen
Zunächst gilt es eine der beiden Festplatten zu entfernen (hier: /dev/sda). Da diese vom RAID aktuell verwendet wird, muss sie zunächst als fehlerhaft markiert werden (es sei denn, sie ist es bereits):
$ sudo mdadm --manage /dev/md0 --fail /dev/sdaIm nächsten Schritt wird die fehlerhafte bzw. als fehlerhaft markierte Festplatte aus dem RAID entfernt:
$ sudo mdadm --manage /dev/md0 --remove /dev/sdaUm das Entfernen der Platte vorzubereiten und die Identifizierung zu erleichtern, wird als nächstes die Platte in den Sleep-Modus geschickt. Bei SSDs ist dieser Schritt natürlich nicht notwendig:
$ sudo hdparm -Y /dev/sdaUnd schließlich (aus reiner Vorsicht) melden wir die Platte noch im Kernel ab. Damit sollte das Entfernen nun sicher sein:
$ echo 1 | sudo tee /sys/block/sda/device/deleteNun steht der physikalische Tausch der Platten an, den ich an dieser Stelle natürlich nicht im Detail beschreiben möchte. Ist die neue Platte eingebaut und wieder online, beginnt man mit der Anmeldung am RAID.
Festplatte in RAID aufnehmen
Da die neue Platte (3,5″ 4TB WD RED Plus) fabrikfrisch und ohne Initialisierung daherkam, musste zunächst eine Partitionstabelle angelegt werden, auch wenn die gesamte Platte ohne dedizierte Partitionen verwendet wird:
$ sudo cfdisk -z /dev/sdaIst auch dies geschehen, kann die Platte – wie gesagt, als Ganzes – am RAID angemeldet werden:
$ sudo mdadm --manage /dev/md0 --add /dev/sdaDie Linux RAID-Software beginnt nun mit der Synchronisierung der 2. Platte, d.h. im Wesentlichen werden die Informationen der verbliebenen „alten“ Platte (/dev/sdb) auf die neue (/dev/sda) übertragen.
Das nimmt einige Zeit in Anspruch und während dieser Zeit ist das RAID recht „empfindlich“, da bis zum Abschluß der Synchronisierung logisch nur eine Platte für das RAID zur Verfügung steht. Bei höheren RAID-Leveln (5,6) sieht das natürlich anders aus und bei RAID 0 ist mit dem Ausfall einer Platte eh „Schicht im Schacht“.
Über den Fortschritt der Synchronisierung kann (und muß) man sich immer wieder informieren. Ein Tausch der verbliebenen, „alten“ Platte /dev/sdb ist erst nach vollständiger Synchronisierung möglich und erfolgt dann analog zu den obigen Schritten.
Der Möglichkeiten zur Analyse lauten:
$ sudo mdadm --detail /dev/md0bzw.
$ cat /proc/mdstatDie Ausgaben zum ersten Befehl ist umfangreich, aber eher zusammenfassend, der relevante Wert befindet sich in „Rebuild Status“:
/dev/md0:
Version : 1.2
Creation Time : Fri Apr 1 17:19:01 2022
Raid Level : raid1
Array Size : 1953382464 (1862.89 GiB 2000.26 GB)
Used Dev Size : 1953382464 (1862.89 GiB 2000.26 GB)
Raid Devices : 2
Total Devices : 2
Persistence : Superblock is persistent
Intent Bitmap : Internal
Update Time : Wed Nov 30 19:10:58 2022
State : active, degraded, recovering
Active Devices : 1
Working Devices : 2
Failed Devices : 0
Spare Devices : 1
Consistency Policy : bitmap
Rebuild Status : 32% complete
Name : example:0 (local to host example)
UUID : a3738222:357f6cb8:b4014413:62be2f37
Events : 109210
Number Major Minor RaidDevice State
2 8 16 0 active sync /dev/sdb
3 8 0 1 spare rebuilding /dev/sdaDer zweite Befehl führt zu einer kürzeren, aber detaillierteren Anzeige. Die Ausgabe sollte der folgenden ähneln, natürlich mit unterschiedlichen (und bei mehrfachem Aufruf ansteigenden) Angaben zum Fortschritt:
Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10]
md0 : active raid1 sdb[2] sda[1]
1953382464 blocks super 1.2 [2/1] [U_]
[>....................] recovery = 0.2% (5148736/1953382464) finish=398.8min speed=81402K/sec
bitmap: 5/15 pages [20KB], 65536KB chunk
unused devices: <none>Nun heißt es Geduld zu haben, bis das Recovery abgeschlossen ist und der Wechsel der verbleibenen Platte nach dem gleichen Muster vollzogen werden kann.
RAID und Filesystem vergrößern
In meinem Falle wurden 2x2TB Platten gegen 2x4TB Platten getauscht. Entsprechend vergrößerte sich der für RAID1 zur Verfügung stehende Platz von 2TB auf 4TB. Dieses Mehr an Platz wird aber nicht automatisch genutzt. Fragt man den genutzten Speicher mittels mdadm ab, so werden nur 2TB berichtet.
$ sudo mdadm --detail /dev/md0
/dev/md0:
Version : 1.2
Creation Time : Fri Apr 1 17:19:01 2022
Raid Level : raid1
Array Size : 1953382464 (1862.89 GiB 2000.26 GB)Der folgende Befehl dehnt das RAID nun auf den gesamten, zur Verfügung stehenden Platz aus:
$ sudo mdadm --grow /dev/md0 --size maxEin erneuter Aufruf von mdadm bestätigt die neue Größe:
$ sudo mdadm --detail /dev/md0
/dev/md0:
Version : 1.2
Creation Time : Fri Apr 1 17:19:01 2022
Raid Level : raid1
Array Size : 3906886488 (3.64 TiB 4.00 TB)
[...]Nur – so wie das RAID nicht unmittelbar den gesamten, verfügbaren Platz auf den Datenträgern verwendet hat, so nutzt auch das Filesystem auf dem RAID nicht ohne weiteren Eingriff den verfügbaren Platz, wie mittels df festgestellt werden kann:
$ df -h /srv
Filesystem Size Used Avail Use% Mounted on
/dev/md0 1.8T 271G 1.5T 16% /srvAber auch das lässt sich beheben, mit dem entsprechenden Werkzeug des Filesystems. Da ich ext4 verwende, ist resize2fs das Mittel der Wahl:
$ sudo resize2fs /dev/md0
resize2fs 1.46.5 (30-Dec-2021)
Filesystem at /dev/md0 is mounted on /srv; on-line resizing required
old_desc_blocks = 233, new_desc_blocks = 466
The filesystem on /dev/md0 is now 976721622 (4k) blocks long.Nochmal das Ergebnis mit df prüfen und fertig:
$ df -h /srv
Filesystem Size Used Avail Use% Mounted on
/dev/md0 3.6T 271G 3.2T 8% /srvPostskriptum
Im Nachhinein hat sich herausgestellt, dass der nahende Tod der installierten 2,5″ 2TB Seagate Barracuda-Platten ein Fehlalarm war, verursacht durch die tatsächlich endgültig zerstörte WD Green. Auf letzterer war leider das Betriebssystem installiert (non-raid). Fairerweise sei darauf hingewiesen, dass die WD Green Serie ausdrücklich nicht auf Dauerbetrieb ausgelegt ist. Grundsätzlich setze ich gerne auf Western Digitial und so wird als Ersatz in Kürze eine WD Red SA500 eingebaut.
Nach dem Ersetzen der SSD, dem Neuaufsetzen des OS und dem Einspielen des Backups waren auch die S.M.A.R.T.-Werte der „alten“ Platten wieder einwandfrei. Aber die Neuen waren halt schon geliefert, was will man machen …