Serie: NAS mit ODROID-HC4 - Teil 1: Basis

  Martin Brodbeck   Lesezeit: 5 Minuten  🗪 10 Kommentare

Einrichten eines kleinen, günstigen NAS.

serie: nas mit odroid-hc4 - teil 1: basis

Mit dieser Artikelserie soll das Einrichten eines kleinen, günstigen NAS erläutert werden. Linux basierte Clients im Haushalt sollen darauf ihre Backups ablegen. Damit eine defekte NAS-Festplatte keinen Daten-GAU verursacht, werden die Daten per RAID1 gespiegelt. Der generische Ansatz (kein Fertigsystem) soll uns dabei helfen, auch andere Wünsche an das NAS zu erfüllen, wie z. B. ein Calibre Server.

Es sind folgende Teile geplant:

  1. Hardware und Betriebssystem
  2. Backups mit Borg
  3. Calibre Server
  4. Samba Server

Hardware und Betriebssystem

Für unser NAS benötigen wir einen ODROID-HC4 samt Netzteil. Dieser günstige Single Board Computer bietet neben einer mehr als ausreichenden ARM CPU (Cortex A55) und 4GB RAM auch zwei SATA-Anschlüsse. Hierbei werden die Festplatten wie bei einem Toaster von oben in die Schlitze gesteckt. Zwei 4TB-HDDs von Western Digital (WD Red) dienen als Datenhalde. Als Datenträger für das Betriebssystem kommt eine 32GB microSD Karte zum Einsatz.

Die Wahl des Betriebssystems fällt auf armbian (Bullseye). Dieses lässt sich einfach installieren und fusst auf der stabilen Debian Distribution.

Der ODROID-HC4 wird übrigens via Ethernetkabel an das LAN angeschlossen, z. B. direkt an eine Fritz!Box.

Installation des Betriebssystems

Das entsprechende Image kann man von der armbian Webseite herunterladen und mittels eines geeigneten Tools, z. B. belenaEtcher, auf die microSD Karte schreiben. Weil armbian noch nicht mit dem neuen Petitboot System des HC4 zurechtkommt, müssen wir vorab Petitboot entfernen. Ohne eingelegte microSD-Karte booten wir den Computer und wechseln in die Petitboot-Shell. Folgende Kommandos löschen Petitboot, wodurch das System in der Folge u-boot startet, was mit armbian kompatibel ist:

# flash_eraseall /dev/mtd0
# flash_eraseall /dev/mtd1
# flash_eraseall /dev/mtd2
# flash_eraseall /dev/mtd3

Durch Ziehen des Netzsteckers wird das Gerät ausgeschaltet und die microSD Karte kann eingelegt werden. Nach erneuter Stromgabe startet nun zum ersten Mal das armbian-System, das auch gleich das Dateisystem auf die Größe der microSD Karte anpasst. Nach Eingabe einiger Daten wie root-Passwort, Erstellen eines normalen Benutzers, Angaben zu Lokalisierung usw. ist das System bereit zum Einsatz.

Btrfs und RAID1

RAID Level 1, also das Spiegeln von Daten, gilt für das Dateisystem Btrfs als stabil, weswegen wir es hier auch gerne dafür einsetzen. Die Integration der RAID-Funktionalität in das Dateisystem erspart uns das Aufsetzen von LVM und wir kommen in den Genuss weiterer Annehmlichkeiten wie das Anlegen dynamischer "Partitionen" (Subvolumes), ohne vorher deren Grösse vorgeben zu müssen.

Zunächst erstellen wir auf den beiden Festplatten mittels fdisk /dev/sda bzw. fdisk /dev/sdb je eine frische gpt-Partitionstabelle (Befehl g) und eine grosse Partition über die gesamte Platte (Befehl n und Vorgaben akzeptieren). Anschliessend teilen wir Btrfs mit, dass es diese als RAID1-Verbund nutzen soll:

# mkfs.btrfs -m raid1 -d raid1 /dev/sda1 /dev/sdb1

Option: In meinem Fall bin ich tatsächlich etwas anders vorgegangen und habe zunächst nur eine der Festplatten angeschlossen. Diese habe ich wie beschrieben partitioniert und zunächst nur ein normales Btrfs-Dateisystem angelegt:

# mkfs.btrfs /dev/sda1

Das hat den Vorteil, dass man sich bei der Zuordnung "welche Festplatte ist wo eingesteckt" leichter tut, was im Falle einer defekten Platte ("Welche ist das bloss?") nützlich sein kann. Man kann sich also in Ruhe mittels fdisk -l /dev/sda den Disk Identifier notieren. Später kann das Dateisystem dann einfach zu einem RAID1 Verbund erweitert werden. Nach Anschliessen der zweiten Festplatte (ggf. das System dafür Herunterfahren) partitioniert man diese, notiert sich den Disk Identifier, und konvertiert dann auf RAID1. Dazu mountet man das bereits erstellte Dateisystem der ersten Platte und fügt dann die Zweite hinzu:

# mount /dev/sda1 /mnt
# btrfs device add /dev/sdb1 /mnt
# btrfs balance start -dconvert=raid1 -mconvert=raid1 /mnt
# umount /mnt

Das Basissystem ist nun soweit vorbereitet. Im nächsten Teil erstellen wir das erste Btrfs Subvolume und richten das NAS für remote Borg-Backups ein.

Tags

NAS, RAID1, ODROID-HC4, microSD, HC4, Petitboot, Dateisystem, Armbian

joerg
Geschrieben von joerg am 8. Oktober 2021 um 11:03

Freu mich auf die noch folgenden Teile thumbs up Gibt es vergleichbare Hardware-Alternativen zum Odroid HC4?

Martin
Geschrieben von Martin am 9. Oktober 2021 um 13:27

Alternativen… Gute Frage. Vielleicht weiß da noch jemand was. Ich habe lediglich vor ca. 3 Jahren mit einem ODROID-XU4 in Verbindung mit einem CloudShell 2 Case (wird nicht mehr vertrieben) experimentiert. Da hatte ich Stabilitätsprobleme (file system errors). Das lag vermutlich an der USB<->Sata Bridge (die beim HC4 nicht mehr nötig ist).

Stefan
Geschrieben von Stefan am 8. Oktober 2021 um 20:10

Genau dieses Unterfangen steht auch auf meiner todo-Liste, eigentlich mit FreeBSD, aber die Linux-Unterstützung scheint besser zu sein. Bedenken, die häufiger zu lesen sind, beziehen sich auf die Platzierung der Festplatten und deren Vibrationen. So mancher befürchtet Langzeitfolgen. Wie seht ihr das?

kamome
Geschrieben von kamome am 9. Oktober 2021 um 12:20

Habe damit zwar keine Praxiserfahrung, aber bei heutigen Festplatten würde ich hoffen, dass das System die Vibrationen verkraftet – mit manchen Server-Platten von vor über 20 Jahren hätte ich da größere Bedenken.

Martin
Geschrieben von Martin am 9. Oktober 2021 um 13:32

Langzeiterfahrungen habe ich auch noch keine. Wenn das Ding in einer ruhigen Ecke auf stabilem Grund steht, habe ich da aber eigentlich wenig Bedenken. NAS-Platten tolerieren ja auch durchaus gewisse Vibrationen, die in anderen NAS-Gehäusen auch nicht ausbleiben. Auf einem wackligen Schuhschränkchen im Flur, wo Kinder darum herumtollen, das wäre vermutlich problematisch… ;-)

KableX
Geschrieben von KableX am 12. Oktober 2021 um 23:50

Hoi zäme.

Mal eine grundsätzliche Frage dazu. Kann ich so einen Eigenbau-NAS auch für eine Nextcloud-Lösung gebrauchen? Wenn ja wie realisiere ich das am besten? Im Netz finde ich zwar sehr viele verschiedene Blogs, Tutorials etc für Nextcloud auf dem Pi oder einem Linux-PC/Laptop und Eigenbau-NAS-Lösungen, aber irgendwie keine Lösung wo das zusammen bringt (ausser ein NAS kaufen und dort NC als App laufen lassen, eher nicht mein Fall). Oder ich bin (mittlerweile vor lauter Recherche) blind, kann auch sein. Vielen Dank auf jeden Fall, auch für eure Arbeit an/auf/mit der Webseite und eure Artikel. Immer wieder spannend und interessant. VG.

Martin
Geschrieben von Martin am 13. Oktober 2021 um 07:46

Ja, selbstverständlich kannst du auf dem NAS Nextcloud installieren. Du kannst da nach einem nextcloud-auf-raspi-installieren-Tutorial vorgehen (z. B. https://pimylifeup.com/raspberry-pi-nextcloud-server/). Dann legst du einfach das datadirectory auf das RAID, so wie es hier für Borg oder Calibre gemacht wurde. Interessant wirds halt beim SSL-Zertifikat und der Anbindung nach "außen". Da ich die Nextcloud auch für Kalender usw. auf dem Smartphone verwende, habe ich sie lieber auf einem (bei mir ohnehin vorhandenen) virtuellen privaten Server ("im Internet") installiert.

KableX
Geschrieben von KableX am 14. Oktober 2021 um 23:46

Hoi Martin Vielen Dank für deine Antwort. Für den Heimgebrauch daheim sollte das eigentlich genügen. Ein gekauftes NAS ist, wie schon erwähnt, nicht mein Fall. VG

Andrej
Geschrieben von Andrej am 2. Februar 2022 um 22:57

Danke für den Artikel. Hab mir das Teil auch bestellt, da ich schon länger darüber nachdenke.

Wie ist deine bisherige Langzeit Erfahrung?

Martin
Geschrieben von Martin am 7. Februar 2022 um 10:03

Läuft noch wie geschmiert. Allerdings habe ich den Netzwerkdienst von NetworkManager auf systemd-networkd umgestellt. Mit NetworkManager gab es ab und an Probleme, die IP-Adresse zu bekommen. (siehe https://forum.armbian.com/topic/19159-odroid-hc4-sometimes-renewing-ip-fails/#comment-131358)