Vom Gaming PC zu PlayStation 5 und leisem Mini-PC, das war unverändert das Ziel. Der erste Versuch mit einem Minisforum EliteMini TH80 sah vielversprechend aus, aber letztendlich war ein Wechsel notwendig: Zu einem Intel NUC12WSKi5 mit Core i5-1240P im „Slim“ Format.
(mehr …)Blog
-
Minisforum Elite Mini TH80
Zu Ende 2022 habe ich eine Entscheidung getroffen: Statt den in die Jahre gekommenen Gaming-PC aufzurüsten wurde dieser entsorgt und durch einen kleinen, kompakten Office-PC ersetzt – den Minisforum Elite Mini TH80. Gut, dass die Playstation 5 bereits vorhanden war.
(mehr …) -
BMW 530e iPerformance: Fazit nach 3 Jahren
Drei Jahre habe ich jetzt einen BMW 530e iPerformance, also ein Plugin Hybrid Electric Vehicle (PHEV) als Dienstwagen fahren dürfen. Gestern war die Rückgabe bzw. der Wechsel gegen ein neues Auto. Obwohl das Neue stets der Feind des Guten ist, blicke ich mit ein wenig Wehmut auf die Zeit mit dem 530e zurück.
(mehr …) -
Linux Software RAID – Festplatte(n) tauschen
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/sda
Im nächsten Schritt wird die fehlerhafte bzw. als fehlerhaft markierte Festplatte aus dem RAID entfernt:
$ sudo mdadm --manage /dev/md0 --remove /dev/sda
Um 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/sda
Und 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/delete
Nun 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/sda
Ist auch dies geschehen, kann die Platte – wie gesagt, als Ganzes – am RAID angemeldet werden:
$ sudo mdadm --manage /dev/md0 --add /dev/sda
Die 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/md0
bzw.
$ cat /proc/mdstat
Die 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/sda
Der 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 max
Ein 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% /srv
Aber 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% /srv
Postskriptum
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 …
-
Neue Hardware für den Zigbee-Hub und Home Assistant
Vor fast 2 Jahren habe ich mich erstmals bewusst mit der Zigbee-Technologie und ihrer Integration in Home Assistant (HA) beschäftigt. Die seinerzeit gewählte Hardware und Software haben weitestgehend einwandfrei ihren Dienst verrichtet. Doch wiederkehrende Probleme wecken den Wunsch nach Veränderung, Probleme, die mit neuer Hardware und alter Software adressiert werden sollen …
(mehr …) -
Zigbee Hub mit Raspberry Pi und Raspbee II
Auch wenn das Jahr 2020 in Summe besser abgeschrieben wird, das ein oder andere Vorhaben konnte dennoch umgesetzt werden. Und so kam es diesmal zu einem „funktionalen“ Weihnachtsgeschenk an meine Eltern: Die Vorbereitung für ein „Smart Home“ auf Basis von Home-Assistant, Phoscons Raspbee II-Modul und des Zigbee Protokolls.
(mehr …) -
ASRock DeskMini A300
Seit einigen Jahren dient ein HP ProLiant N54L Microserver mir als „Heimserver“. Ein grundsolides Gerät, leise, wartungsarm, stabil. Die AMD Turion II CPU ist allerdings festverlötet und stößt mit ihren 2,2 GHz an ihre Grenzen, ebenso wie die max. 8 GB RAM. Zeit für etwas Neues, stärker, größer – und kleiner: Der ASRock DeskMini A300.
(mehr …) -
BMW 530e iPerformance: Die ersten 10.000km
Seit Anfang Dezember fahre ich ein teil-elektrifiziertes Fahrzeug, konkret einen BMW 530e iPerformance, Modelljahr 2019. Jetzt, gut 9 Wochen später sind die ersten 10.000 Kilometer „abgespult“. Zeit für ein erstes, wie immer subjektives Zwischen-Fazit.
(mehr …) -
Docker und Raspbian auf einem Raspberry Pi
Docker auf einem Raspberry Pi zu installieren ist keine große Sache und auch sinnvoll, denn die kleine „Handy-Platine“ ist durchaus in der Lage mehrere Anwendungen in Containern zu betreiben. Auch ich habe die Prozedur schon einige Male durchlaufen, aber bis dato noch nie niedergeschrieben. Eine Nachlässigkeit, die ich hiermit korrigiere.
(mehr …) -
Homegear-Gateway mit CC1101 und Raspberry Pi 3
In einem verzweifelten Versuch die Verbindungsprobleme mit meiner Homematic-Installation endlich in den Griff zu bekommen, wurde ein weiterer Raspberry Pi 3 angeschafft, um in Verbindung mit einem CC1101-Modul ein zusätzliches Homegear-Gateway zu realisieren. Dieses Mal wurde mitgeschrieben, welche Schritte dafür notwendig sind …
(mehr …)