NAS mit ODROID-HC4 - Nachlese

Ergänzend zur Artikelserie über das Aufsetzen eines kleinen, günstigen NAS für das Heimnetzwerk, betreiben wir hier etwas Nachlese und kümmern uns noch um ein paar offene Punkte:

• Gehäuselüfter
• Desaster-Recovery
• Armbian-Backup
• Plattentausch

Gehäuselüfter

Den Gehäuselüfter, der Bestandteil des ODROID-HC4 ist und sich bisher nicht regte, haben wir bisher noch gar nicht betrachtet. Tatsächlich wird er auch nicht unbedingt benötigt. Die CPU-Temperatur beträgt – jedenfalls in meinem Setup – meist um die 50°C. Selbst ein langwieriger Btrfs Balance-Prozess (als ich die zweite Festplatte angeschlossen hatte und auf RAID1 konvertierte) trieb die Temperatur nicht über 60°C hinaus.

Dennoch ist man beruhigter, wenn man weiss, dass von dieser Seite keine Gefahr droht. Auf Nachfrage im Odroid-Forum wurde mir auch schnell Auskunft erteilt: Im Prinzip wird der Lüfter unterstützt, jedoch gibt es noch kein Paket samt Konfigurationsdatei, womit der Lüfter out-of-the-box funktioniert (Stand: 11.10.2021).

Es ist jedoch ein Leichtes, das selbst einzurichten. Wir installieren das Paket fancontrol (apt install fancontrol) und erstellen die Datei /etc/fancontrol mit folgendem Inhalt:

INTERVAL=10
DEVPATH=hwmon0=devices/virtual/thermal/thermal_zone0 hwmon2=devices/platform/pwm-fan
DEVNAME=hwmon0=cpu_thermal hwmon2=pwmfan
FCTEMPS=hwmon2/pwm1=hwmon0/temp1_input
FCFANS= hwmon2/pwm1=hwmon2/fan1_input
MINTEMP=hwmon2/pwm1=50
MAXTEMP=hwmon2/pwm1=60
MINSTART=hwmon2/pwm1=20
MINSTOP=hwmon2/pwm1=28
MINPWM=hwmon2/pwm1=0
MAXPWM=hwmon2/pwm1=255

Danach reicht ein Neustart des fancontrol Service mittels systemctl restart fancontrol.service und der Lüfter verrichtet von nun an seine Arbeit.

Desaster Recovery

Ein Backup zu machen ist schon einmal die halbe Miete. Man sollte den Ernstfall aber vor Augen haben und bestenfalls auch mal durchexerzieren. Hier also die grobe Schilderung, wie bei mir der (erprobte) Wiederherstellungsprozess aussieht.

Hinweis 1: Ich verwende Arch Linux und habe den Ernstfall auch nur damit simuliert. Bei anderen Distributionen ist ggf. anders vorzugehen. Mein System verwendet übrigens UEFI in Verbindung mit systemd-boot. 
Hinweis 2: Damit man es beim Wiederherstellen der Daten einfacher hat, sollte man vorher dem User borg auf dem NAS ein Passwort zuweisen. Das habe ich in Teil 2 der Serie noch unterlassen.

Vorbereitungen

Zunächst bootet man von einem USB-Stick das Arch Linux Livesystem und stellt am besten gleich auf eine deutsche Tastaturbelegung um:

# loadkeys de

Hängt man via Ethernetkabel am LAN, wird automatisch per DHCP eine IP-Adresse vergeben und wir sind mit dem Heimnetz verbunden.

Nun wird die SSD oder HDD des Rechners partitioniert. Ich verwende, eine optionale Swap-Partition mal aussen vor gelassen, meist eine Partition für boot (samt EFI) und eine für den ganzen Rest, wobei ich hier noch ein Subvolume für / und für home anlege.

Also, mittels fdisk /dev/sda wird eine neue GPT-Partitionstabelle angelegt (Befehl g). Danach folgen die Partitionen für boot (Befehl n – +500M genügen hier – und anschliessend mit t den Partitionstyp EFI System vergeben!) und für das Btrfs Filesystem (nochmal Befehl n und die Vorgabewerte akzeptieren).

Die folgenden Befehle erstellen die Dateisysteme und Subvolumes:

# mkfs.vfat /dev/sda1
# mkfs.btrfs /dev/sda2
# mount /dev/sda2 /mnt
# btrfs subvolume create /mnt/@root
# btrfs subvolume create /mnt/@home
# umount /mnt

Jetzt hängen wir die Dateisysteme ein und erstellen die Systemverzeichnisse, die das Backup (richtigerweise) ausgelassen hat:

# mount -o subvol=@root,compress=zstd /dev/sda2 /mnt
# mkdir /mnt/{boot,proc,sys,dev,home}
# mount /dev/sda1 /mnt/boot
# mount -o subvol=@home,compress=zstd /dev/sda2 /mnt/home

Soweit die Vorbereitung der Festplatte. Jetzt muss im Livesystem noch das borg Paket nachinstalliert werden:

# pacman -Sy
# pacman -S borg

Wiederherstellen der Daten

Sind die Vorbereitungen abgeschlossen, geht es an die Wiederherstellung der Daten. borg extract erledigt dies (wobei man mit borg list zunächst nachschauen kann, welche Backuparchive vorhanden sind):

# cd /mnt
# borg extract borg@droidnas.fritz.box:/mnt/backup/myrepo::system-20211013-113108
borg@beenas.fritz.box's password: ***
Enter passphrase for key ssh://borg@droidnas.fritz.box/mnt/backup/myrepo: ***
# cd home
# borg extract borg@droidnas.fritz.box:/mnt/backup/myrepo::home-20211013-142809
borg@beenas.fritz.box's password: ***
Enter passphrase for key ssh://borg@droidnas.fritz.box/mnt/backup/myrepo: ***

Nach Eingabe der Borg-Kommandos benötigt man also zwei Passwörter: Das für das Anmelden des Benutzers borg und das für das Aufschliessen des Backup-Repositorys. Während borg an der Wiederherstellung der Daten arbeitet, kann man sicherlich einen (oder mehrere) Kaffee trinken.

Nachbereitung

Die Daten sind jetzt also wieder hergestellt. Jetzt müssen wir sichergehen, dass das System auch wieder bootet. Dazu wechseln wir mittels arch-chroot in das neue, gerade wiederhergestellte System.

# cd /
# arch-chroot /mnt

Wichtig: Nicht vergessen sollte man, jetzt die alten UUIDs der Partitionen sowohl in /etc/fstab (sofern hier UUIDs verwendet wurden) als auch in den systemd-boot Einträgen in /boot/loader/entries/ an die neuen UUIDs anzupassen!

Mittels mkinitcpio -p linux erstelle ich nun die initial ramdisk neu, wobei das womöglich nicht notwendig ist. Läuft das Kommando aber durch, ist das schonmal ein gutes Zeichen, dass alles passt. Danach wird noch mit bootctl install der bootloader frisch installiert. Ist auch hier keine Fehlermeldung zu sehen, starten wir das System neu:

# exit
# umount -R /mnt
# reboot

Das System lassen wir jetzt ohne USB-Stick booten. Läuft alles glatt, landen wir in unserem altbekannten System und können weiterarbeiten als wäre nichts gewesen. :)

Gibt es hingegen ein Problem, kann man wieder das Livesystem starten und sich auf Fehlersuche begeben. Ich habe die Prozedur schon ein paar Mal durchgeführt, um etwa das Notebook zu wechseln oder wenn am PC auf eine neue Festplatte migriert werden musste. Auch kann man das Ganze in einer virtuellen Maschine durchspielen, wobei hier die eine oder andere Warnmeldung auch der Virtualisierungsumgebung zuzuschreiben wäre.

Armbian-Backup

Die Linux-Clients im Heimnetzwerk können einfach und sicher ihre Backups mittels Borg auf dem NAS ablegen. Doch was ist mit dem Armbian-Betriebssystem an sich? Man könnte sicherlich lokal ein borg-Backup auf die RAID-Festplatten machen. Da auf der SD-Karte jedoch EXT4 als Dateisystem verwendet wird, sind Snapshots hier nicht möglich (was nicht unbedingt ein Hindernis sein muss). Ich habe mich jedoch dazu entschieden, einfach ein Image von der SD-Karte zu ziehen – so viel ändert sich an dem System ja nicht, als dass man das so oft machen müsste.

Dazu einfach den ODROID-HC4 herunterfahren und die Karte an einen anderen Linuxrechner anschliessen. Das folgende Kommando erstellt ein Image von der kompletten SD-Karte und legt es komprimiert ab:

# dd if=/dev/sdX bs=4M | gzip > 2021-10-11_Armbian_OdroidHC4.img.gz

Wobei natürlich /dev/sdX an den tatsächlichen Devicenamen anzupassen ist.

Im Falle eines Falles lässt sich das Image einfach auf eine Ersatzkarte flashen und schon ist das NAS wieder einsatzbereit.

Plattentausch

Früher oder später wird eine der Platten ausfallen. Dann gilt es zunächst zu ermitteln, welche denn nun den Geist aufgegeben hat.

Wenn das Dateisystem nicht gemountet wurde, teilt einem z. B. dmesg diese Information mit:

BTRFS error (device sdX): devid 2 uuid xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx is missing

Wenn man sich vorab Notizen gemacht hat, welche Platte (Disk Identifier über fdisk erfragen!) mit welcher devid in welchem SATA-Slot steckt, lässt sich nun eindeutig ermitteln, um welche Platte es sich handelt. Gehen wir mal davon aus, dass es sich bei devid 2 um die Platte im hinteren Slot handelt. Der Einfachheit halber gehen wir ferner davon aus, dass die neue Festplatte gleich gross ist. Meine Vorgehensweise ist folgende:

1. System herunterfahren.
2. Defekte HDD entfernen und stattdessen neue HDD in den Slot stecken.
3. System hochfahren.
4. RAID im degraded mode mounten.
5. RAID wiederherstellen (`btrfs replace`).
6. Ggf. Grösse des Dateisystems anpassen (`btrfs resize`).

Nach dem Hochfahren des Systems muss also das RAID mit der Option -o degraded eingehängt werden, da der Kernel ein Dateisystem mit fehlenden Disks nicht mountet.

# mount -o degraded /dev/sda1 /mnt/temp

btrfs device usage /mnt/temp sollte nun etwa folgendes zeigen:

/dev/sda1, ID: 1
   Device size:             3.64TiB
   Device slack:            3.50KiB
   Data,RAID1:              1.59TiB
   Metadata,RAID1:          3.00GiB
   System,RAID1:           32.00MiB
   Unallocated:             2.05TiB

missing, ID: 2
   Device size:             3.64TiB
   Device slack:            3.50KiB
   Data,RAID1:              1.59TiB
   Metadata,RAID1:          3.00GiB
   System,RAID1:           32.00MiB
   Unallocated:             2.05TiB

Nach dem Partitionieren der neuen Platte soll Btrfs diese nun anstelle der defekten verwenden:

# btrfs replace start 2 /dev/sdb1 /mnt/temp

Der replace-Prozess wird nun in Hintergrund durchgeführt, was durchaus einige Stunden dauern kann.

Wichtig: Um die Redundanz vollständig wieder herzustellen, müssen jetzt noch die Chunks, die zwischenzeitlich im single profile gespeichert wurden, ins RAID profile umgewandelt werden:

# btrfs balance start -dconvert=raid1,soft -mconvert=raid1,soft /mnt/temp

Spätestens wenn dieser Vorgang abgeschlossen ist, kann das RAID wie gewohnt verwendet und die Subvolumes wieder eingehängt werden. Einige Dienste, die wegen des nicht gemounteten Dateisystems nicht starten konnten (z. B. der Calibre Server), müssen jedoch neu gestartet werden.

Schauen wir uns nun noch die Fälle an, wenn die neue Festplatte eine andere Kapazität aufweist.

Austausch mit einer kleineren Festplatte

Weist die neue HDD eine kleinere Kapazität aus, sagen wir einmal 3TB, muss erst mal das Dateisystem auf der verbliebenen Platte (mit `-o degraded` mounten) verkleinert werden (kleiner als die kleinste Kapazität):

# btrfs filesystem resize 1:2500GiB   /mnt/temp

Danach wird, wie oben beschrieben, der btrfs replace-Prozess gestartet. Ist dieser abgeschlossen, sollte man noch sicherstellen, dass die Kapazitäten aller Festplatten (wieder) komplett genutzt werden, weswegen wir folgendes Kommando für die beiden devids nacheinander ausführen:

# btrfs filesystem resize <devid>:max /mnt/temp

Austausch mit einer grösseren Festplatte

Hier kann man sich das Verkleinern des Dateisystems sparen – ein anschliessendes btrfs resize für das Dateisystem der neuen Platte (im Beispiel devid 2) reicht aus:

# btrfs filesystem resize 2:max /mnt/temp

Übrigens, angenommen wir haben eine defekte 4TB Festplatte mit einer 6TB Festplatte ausgetauscht. Unser RAID1 besteht nun also aus der grossen 6TB und aus der anderen, noch intakten 4TB-Platte. Wenn wir nun diese auch noch auf die gleiche Weise durch eine 6TB-Platte austauschen, haben wir die Kapazität unseres NAS erhöht. Man kann also dadurch auf neue Speichermedien migrieren, z. B. um neue und/oder grössere Platten in Einsatz zu bringen, ohne auf den Ausfall einer Platte zu warten.