Projekt Homebase: Exkurs Backup Stage 2

hr kennt diese Geräte.

Weiß, glatt, minimalistisch – irgendwo zwischen Wohnzimmermöbel und Designobjekt. Keine sichtbaren Schrauben, kein Lüftergeräusch, nichts, was einen daran erinnert, dass da eigentlich ein ganz normaler Computer drinsteckt. Alles fühlt sich ein bisschen an wie ein Produkt von Apple: auspacken, einschalten, App installieren – fertig. Keine Fragen, keine Entscheidungen, einfach nur „Trust the system“.

Und ganz ehrlich: Für 90 % der Menschen ist genau das perfekt. Keine Shell, keine Logs, keinerlei Gebastel.

Ich dachte lange Zeit, ich wäre auch so jemand. Tja. So kann man sich irren.

Meine erste Backup-Strategie war eine einzelne 12-TB-USB-Festplatte. Das funktioniert schon – zumindest theoretisch. Praktisch ist es digitales Hoffen: keine Automatisierung, keine Telemetrie, keine Redundanz. Man legt sie in die Schublade und betet still, dass sie beim nächsten Einstecken noch dreht.

Dann sah ich das Ubiquiti UniFi NAS 2.

Wunderschönes weißes Gehäuse, kleines blaues OLED-Display, perfekt ins UniFi-Ökosystem integriert. Auspacken, anmelden, Cloud-Account anlegen, ein paar Klicks – und das Ding läuft. Alles sauber, alles elegant, alles wie aus einem Guss.

In meinem Kopf lief sofort „Apple Time Capsule 2.0“. Tech-Liebe auf den ersten Blick.

ARM-CPU mit vier Kernen, 4 GB RAM, Strom über PoE, 2.5 GbE – auf dem Papier genau das, was man sich für ein sparsames, modernes Backup-System wünscht. Und für rund 200 Euro ehrlich gesagt fast schon verdächtig günstig. Also gekauft, zwei Platten eingeschoben, fünf Minuten später war das Gerät produktiv.

Ubiquity UNAS 2

Das Gerät lief also. Leise, stabil, schick. Genau so, wie man es sich wünscht.
Kein Drama, kein Basteln, einfach nur ein kleines, weißes Kästchen, das brav seinen Dienst tat.

Eigentlich perfekt.

Im nächsten Schritt meiner Rebel-Homebase-Reise wollte ich meinen „Dicken“, den AMD-Server, neu aufsetzen und sauber in den Cluster integrieren. Also: erst mal ein ordentliches Backup auf die neue, tolle Appliance schieben. Vorher dachte ich mir allerdings, ich binde das NAS noch schnell in mein frisch aufgesetztes Monitoring mit Prometheus und Grafana ein. Ein bisschen Telemetrie schadet nie. Wissen ist besser als Hoffen.

Und dann lief ich frontal gegen eine Wand.

Das proprietäre Betriebssystem ließ genau das zu, was es zulassen wollte. Und sonst nichts.
Kein Node-Exporter, kein Zugriff auf Systemmetriken, über SNMP im Grunde nur Netzwerk-Traffic. Keine CPU-Temperatur, keine Plattenwerte, kein Health-Status, nicht mal ein sauberer Füllstand.

Ironischerweise konnte das kleine OLED-Display vorne all diese Informationen anzeigen. Ich durfte sie nur nicht haben.

In dem Moment musste ich an ein Gespräch mit meinem Freund Cornelius denken, mit dem ich kurz zuvor über die Hardware von Ubiquiti und diesen angenehm glänzenden, aber ziemlich geschlossenen Kosmos gesprochen hatte. Damals klang das noch theoretisch. Jetzt saß ich davor und starrte auf die praktische Demonstration.

Und genau da verdampfte die Euphorie.

Was ich gekauft hatte, war kein Werkzeug. Es war eine Appliance. Eine hübsche Black Box mit Display, aber ohne echte Kontrolle. Nichts Eigenes installieren, keine brauchbaren Telemetriedaten nach Grafana schieben, kein RAM-Upgrade und ohne Cloud-Account oder UniFi-Ökosystem fühlt sich das Ganze plötzlich erstaunlich unfrei an, hier geht dann nämlich wenig

Für viele ist das perfekt. Wirklich. Einschalten und vergessen. Für mich war es ein Fehler.

Ich habe genau das getan, was ich sonst immer kritisiere:
Ich habe Freiheit gegen Bequemlichkeit getauscht.

Man muss immer einen Plan B haben.

Der naheliegende Reflex war zuerst: zurück zu Synology. Die bauen seit Jahren solide Kisten, die halbwegs jeder kennt, halbwegs jeder bedienen kann und die in vielen Haushalten und kleinen Büros einfach unauffällig ihren Dienst tun.

Aber ganz ehrlich: So richtig wollte ich nicht zurück.

Zu viel proprietäres Zeug, zu viel „nur mit unseren Paketen, nur in unserem Kosmos“. Und nach dem ganzen Festplatten-Theater der letzten Jahre hatte ich auch wenig Lust, mich wieder freiwillig in ein künstlich verknapptes Ökosystem einzusperren. Funktional gut, ja. Offen oder frei? Eher nicht so ganz.

Also weiter suchen.

Und dann fiel mir plötzlich ein Name ein, den ich fast vergessen hatte: Ugreen. Da war doch mal diese Kickstarter-Kampagne vor ein paar Jahren. Ein unscheinbares NAS, damals noch eher „Underdog aus China“ als etablierter Hersteller.

Ein bisschen recherchiert, Datenblätter gelesen. Zweite Teekanne aufgesetzt. Nochmal gelesen. Diesmal mit dem Fokus auf Systemoffenheit. Und diesmal klang das alles erstaunlich vernünftig.

Eine N100-CPU, also echte x86 statt vernageltem Spielzeug-ARM. Zwei HDD-Slots. Zwei zusätzliche NVMe-Slots. Eine kleine eMMC nur fürs System. 2,5-Gigabit-Netzwerk. Ab Werk mit 8 GB RAM, aber austauschbar. (Und laut der Community laufen hier DDR5-RAM-Module mit bis zu 32 GB. Auch wenn diese derzeit unbezahlbar sind).

Und vor allem: kein goldener Käfig, sondern die Option, einfach mein eigenes OS zu installieren. Kein Cloud-Zwang. Kein Herstellerkonto. Kein „Trust the system“. Nur Hardware.

Genau das, was ich wollte.

Optisch komplett unspektakulär, eher schwarzer Werkzeugkasten als Designobjekt . Aber plötzlich fühlte sich das wieder nach Technik an und nicht nach einem Designer-Möbelstück. Perfekt für ein leises, ehrliches Level-2-Backup.

Ugreen DXP2800

Also ab zum Hardware-Dealer meines Vertrauens. Und ja, sie hatten die DXP2800 von Ugreen tatsächlich auf Lager. Preispunkt: 300 Euro.

Und plötzlich fühlte sich die ganze Diskussion herrlich nüchtern an. Rund 100 Euro mehr als die UniFi-Appliance. Aber dafür volle Kontrolle, offene Plattform, eigenes OS, RAM tauschbar, NVMe-Slots. Also nicht „hübsch integriert“, sondern „mach damit, was du willst“. Und das volle Potenzial für eine steile Lernkurve – ihr werdet sehen.

Im Grunde 100 Euro Aufpreis für Freiheit. Ein schlechter Deal ist das nicht. Dann kam die RAM-Frage. 8 GB out of the Box. Upgrade auf 32 GB? 590 Euro. Auf 16 GB? 220 Euro. Da musste ich kurz lachen. Nicht, weil es technisch kompliziert wäre, sondern weil RAM preislich offenbar wieder in einer Phase ist, in der Goldbarren die vernünftigere Anlageform darstellen. Für ein bisschen Speicher zahlt man plötzlich fast das halbe NAS noch einmal. Mein innerer Schwabe hat die Preistafel gesehen und leise „Nein“ gesagt. Man muss ja nicht jeden Upgrade-Impuls sofort ausleben. Probieren wir es erst mal so.

Was darfs denn bitte sein?

Das neue NAS stand da: schwarze Kiste, ehrliche Hardware, bereit für irgendetwas Sinnvolles. Also die naheliegende Frage: Welches OS bekommt den Job?

Erster Reflex: Unraid oder TrueNAS.

Beides etablierte Systeme, große Community, tausend How-tos, quasi die zwei alten Hasen im Home-NAS-Universum. Mit Unraid hatte ich sogar schon vor ein paar Jahren einige sehr positive Erfahrungen sammeln können. Unraid ist technisch echt charmant, keine Frage. Ausgereift, flexibel, angenehm zu bedienen. Aber: Closed Source und Boot vom USB-Stick.

Und da zuckt bei mir sofort irgendwas im Hinterkopf. Nicht, weil es schlecht wäre, ganz im Gegenteil. Sondern weil es sich in meinem Szenario einfach falsch anfühlt. Wenn ich schon „Rebel Homebase“ baue, dann bitte ohne proprietären Kern und seriennummer-gelockten USB-Dongle als Lebensader. Ich wollte Kontrolle, nicht wieder eine Black Box, diesmal in bunt.

Also: TrueNAS.

ZFS. Snapshots. Checksummen. Seriöse Storage-Technik. Wir sind hier schließlich nicht zum Spielen. 😄

Ich hatte sogar noch zwei 1-TB-NVMes und eine 128-GB-NVMe in der Kramkiste liegen. Der Plan also: TrueNAS auf die interne 32-GB-eMMC, dazu 2 × 12-TB-HDDs und 2 × 1-TB-NVMes. Und dann mal schauen, welche netten ZFS-Konstruktionen man daraus bauen kann. Cache, Log, Spielwiese. Das Nerd-Herz schlägt schneller.

Theorie: hervorragend. Praxis: Nope.

TrueNAS ließ sich schlicht nicht installieren. Die eMMC machte Zicken. Partition 2 wurde nicht erkannt. Wipen, neu partitionieren, nullen, fluchen, wiederholen – alles durchgespielt. Jeder Trick aus irgendwelchen Foren-Threads seit 2020 wurde ausprobiert. Immer wieder derselbe Punkt: Abbruch.

Man sitzt davor und denkt sich: „Ernsthaft? Ich betreibe Kubernetes-Cluster im Keller, aber scheitere an einer 32-GB-Bootplatte.“

Nebenbei: Im Internet liest man öfter Beschwerden, dass Ugreen das Original-OS nicht separat anbietet und man auf solche Experimente verzichten sollte. Deshalb hatte ich ganz am Anfang ein komplettes RescueZilla-Backup der eMMC gezogen. Einfach aus Paranoia. Beste Entscheidung des Tages.

Bei Bedarf findet ihr das hier: Link.

Denn irgendwann kam dieser eine, befreiende Gedanke: Warum kämpfe ich eigentlich gegen das Ding? Warum versuche ich, eine Appliance mit einem Spezial-Storage-OS glücklich zu machen, wenn mein kompletter Rebel-Cluster sowieso auf Ubuntu läuft?

Ubuntu und Debian. Rein in den Maschinenraum.

Ubuntu Server 24.04 LTS installiert sich auf der kleinen eMMC völlig unspektakulär. Kein Drama, kein Partition-2-Fehler. Einfach durchlaufen lassen, Reboot, Login-Prompt. Großartig. Genau so soll Infrastruktur sein: langweilig.

Die Routine sitzt inzwischen irgendwie. IP-Adresse festnageln. Hostname und Domain setzen. Richtigen DNS eintragen. Wenn wir schon dabei sind, auch gleich unseren eigenen NTP-Server. Einer der Hauptgründe war ja die Telemetrie – also direkt den Node Exporter für Prometheus/Grafana installieren.

Läuft.

Das Einzige, was „out of the box“ nicht will, sind die LEDs. Die machen fröhliches Lauflicht wie ein Gaming-PC. Geschenkt. Optik. Kümmern wir uns später drum. SSH-Zugriff? Check. Ab jetzt alles remote. So muss das sein.

Der Plan war dann: ZFS bequem über Cockpit mit dem 45Drives-Plugin verwalten. Also schnell das 45Drives-Repository eingebunden, Pakete installiert, einmal apt update, einmal apt install, fertig. So dachte ich. Bam.

Ubuntu 24.04 LTS!!! ist „zu neu“. Unsupported by 45Drives.

Ab da begann der Teil, den man in Blogposts normalerweise verschweigt. Skripte patchen. Pfade anpassen. 404-Fehler. Umbenannte Repositories. Halb kaputte Dependencies. 45Drives zielt noch auf 20.04 ab. Ich saß also auf einer zu frischen LTS und fühlte mich plötzlich wie ein Beta-Tester. Nach ein paar Stunden habe ich aufgegeben und mir gedacht: Komm, dann eben ohne GUI. Zurück zur Kommandozeile. Da lernt man wenigstens wieder was.

lsblk – alle Platten da. Also bauen wir das halt per Hand. Zwei HDDs als Spiegel: sudo zpool create -f tank mirror /dev/sda /dev/sdb

Und die beiden NVMes ebenfalls:
sudo zpool create -f turbo mirror /dev/nvme0n1 /dev/nvme1n1

zpool status zeigte zwei glückliche, gespiegelte Pools. Das war einer dieser kleinen Siege, die einen irrational glücklich machen. Also Samba manuell installiert. Getestet. Läuft. Zwischendurch noch Webmin ausprobiert. Sieht aus wie Windows 95 im Browser, macht aber stoisch seinen Job.

Und trotzdem: ständig Kleinkram. Kernel zu neu. Fehlende Module. Fehlende Header. Paketmanager sagt „Alles installiert“, DKMS sagt „Kenn ich nicht“. Rechteprobleme. Kaputte Links. Dieses klassische Linux-Bingo, das um Mitternacht plötzlich sehr unromantisch wird.

Und dann hing da noch dieses eine strukturelle Problem im Hintergrund: Lizenzen. Der Linux-Kernel steht unter GPL, ZFS unter CDDL. Heißt übersetzt: Die großen Distributionen dürfen ZFS nicht einfach sauber „out of the box“ mitliefern. Also immer Basteln, Module nachladen, Workarounds, Spezialfälle, Kompilieren. Technisch lösbar, aber nie elegant und immer mit der Angst vor dem nächsten großen Update.

Nach ein paar weiteren Stunden kaputt-konfigurierter Neuinstallationen habe ich den puristischen Ubuntu-Weg irgendwann verworfen.

Nächster Versuch: Debian 12 „Bookworm“. Der Fels in der Brandung. Das Betriebssystem, das läuft, wenn alles andere schon aufgegeben hat. Ist euch mal aufgefallen, dass wir seit Jahren bessere, schnelle CPUs, RAM-Timings und Festplatten haben, gefühlt die Responsiveness aber immer träger und schwammiger wird? Bei dem Debian-Server hatte ich ein Aha-Erlebnis. Gott, ist das alles schnell! Installation? Blitzschnell durch. ZFS drauf, Pools erstellt? Quasi in Echtzeit.

Also nochmal Cockpit, 45Drives, SMB probiert. Vielleicht diesmal. Spoiler: gleiche Runde wie vorher.

Zwei Stunden später war es drei Uhr morgens, ich starrte auf Logs und dachte mir nur: Genug für heute. Deckel zu. Bett.

Rollback.

Samstagmorgen. Eine Nacht drüber zu schlafen wirkt manchmal besser als jedes Debugging-Tool. Der Kopf ist wieder klar, der Puls normalisiert sich, und plötzlich sieht man die Dinge weniger dogmatisch.

Offensichtlich war meine „Maschinenraum-Lösung“ nicht die optimale Strategie. Ja, man kann sich alles selbst zusammenschrauben. Aber nur weil man es kann, heißt das noch lange nicht, dass man es sollte.

Also nochmal von vorne denken. Unraid? Hatten wir schon. Technisch gut, aber Closed Source. Proxmox VE? Kann ZFS out of the box, ja. Aber das ist eigentlich ein Hypervisor, kein NAS. Ich wollte Storage, keinen weiteren halben Cluster-Knoten. Das wäre wie mit einem Katana Brot zu schneiden.

Bleibt also wieder: TrueNAS?

Das war ja eigentlich von Anfang an der logische Kandidat. Gescheitert war es nur an dieser zickigen eMMC. Also kam der bequeme Gedanke: Warum kämpfe ich überhaupt mit der eMMC? Warum nicht einfach eine der 128-GB-NVMes als Systemplatte nehmen und gut ist? Technisch völlig okay. Aber irgendwie… fühlte sich das falsch an. Eine schnelle NVMe nur fürs OS zu „verheizen“, während sie als Cache oder Pool viel sinnvoller wäre? Während für das OS ein vorgesehener Speicher fest verlötet ist? Das nagte.

Und gleichzeitig ließ mich eine Beobachtung nicht los: Ubuntu und Debian ließen sich ja installieren. Die Hardware war also grundsätzlich okay. Das Problem musste irgendwo im Detail liegen. Also nochmal Recherche. Noch mehr Recherche. Foren, Release Notes, irgendwelche obskuren Threads von Leuten mit exakt demselben Fehlerbild.

Und dann: Natürlich. Mit einem kleinen Kniff geht es doch.

Nicht die aktuelle Version, sondern TrueNAS 24.04 Dragonfish. Zwei Generationen älter. Die installiert sich völlig problemlos auf der eMMC, als wäre nie etwas gewesen. Von dort aus dann ganz entspannt das In-place-Upgrade auf TrueNAS 24.10 Electric Eel und anschließend auf TrueNAS 25.04 Fangtooth. Mit Zwischenschritt, reine Vorsicht. Ich hatte für diese Woche genug Überraschungen.

Und dann dieser seltene, magische Moment:

Reboot. Login. Alles da. Keine Fehlermeldung. Kein Theater. Es läuft. Auf der eMMC. Nach all dem Frust war die Lösung am Ende fast banal. Natürlich.

Aus dem namenlosen, schwarzen Metallkasten ist ein Individuum geworden. In meinem Netzwerk hat das Kind nun einen Namen: wintermute.pandolin.online. Fest verankert unter der IP 192.168.1.99, damit es keine Missverständnisse mehr gibt.

Reden wir kurz über Storages. ich erzähle hier den meisten von Euch nichts Neues.

Wir müssen also die eMMC schonen. Sie ist das schwächste Glied in der Kette. Also habe ich das Setup noch einmal grundsätzlich überdacht. Die eMMC bekommt ab jetzt genau eine Aufgabe: System starten. Sonst nichts. Keine produktiven Daten, keine Workloads, keine Logs.

Für die eigentliche Arbeit hatten wir ja wesentlich bessere Werkzeuge im Regal liegen. Und wenn man schon mit TrueNAS unterwegs ist, dann können wir professionell denken, in reiner ZFS-Logik: Pools, VDEVs, Datasets.

Was machen wir nun? Jeweils zwei Platten spiegeln. Die beiden HDDs als Mirror. Die beiden NVMes ebenfalls als Mirror. Ja, das halbiert die nutzbare Kapazität, aber dafür kann sich im Zweifel einfach eine Platte verabschieden und das System läuft weiter. Redundanz schlägt Effizienz. Gerade bei Backups.

Die HDDs übernehmen die grobe Arbeit. Die NVMes dagegen hängen als sogenannte Special VDEV im Pool. Das klingt nach ZFS-Zauberei und ist es irgendwie auch. TrueNAS legt dort automatisch die Metadaten und Verzeichnisstrukturen ab – genau die kleinen Dinge, bei denen klassische Festplatten ins Schwitzen geraten.

Das Ergebnis: Obwohl die Daten auf drehenden Scheiben liegen, fühlt sich das System blitzschnell an, weil das „Denken“ auf den NVMes passiert und nur das „Lagern“ auf den HDDs.

Trotzdem blieb ein Gedanke: Zwei Terabyte nur für Metadaten sind eigentlich ziemlicher overkill. OK, das ist das gesamte Rebel HomeBase Projekt.
Aber ... zum Glück gibt es noch eine großartige Option in TrueNas namens „Small Block Size“. Damit sagt man ZFS im Grunde: Alles unterhalb einer bestimmten Größe gilt als „klein“ und soll bitte automatisch auf dem schnellen Medium landen. Und genau diese kleinen Dateien sind ja die Hölle für HDDs. Fotos, Dokumente, Thumbnails, Icons, tausende Mini-Dateien.

Ich habe mich hier für 128 KB entschieden, ein ganz brauchbarer Sweet Spot. Alles darunter bleibt auf dem NVMe-Mirror, alles darüber wandert auf die HDDs. Ohne manuelles Tiering, ohne Tricks, einfach automatisch. Kleine Dateien schnell, große Dateien günstig. So simpel kann es manchmal sein. Total abstrakt vom Nutzer.

Wichtig war nur, beim Anlegen wirklich „Metadata/Special VDEV“ auszuwählen und den Rest bewusst zu ignorieren. Kein SLOG, kein L2ARC, kein Dedup.

Am Ende stand also eine ziemlich bodenständige Architektur da: ein Pool, zwei Mirrors, jede Platte mit klarer Aufgabe.

Das System-Dataset umziehen (eMMC-Schutz)

Das ist die wichtigste Maßnahme. Aktuell schreibt TrueNAS alle paar Sekunden Logs auf die eMMC. Das stoppen wir jetzt:

1. WebGUI: System Settings -> Advanced.
2. System Dataset -> Configure.
3. System Dataset Pool von boot-pool auf den neuen Pool tank umstellen und Save.

TrueNAS verschiebt die Datenbanken auf die NVMes. Die eMMC wird ab jetzt quasi nur noch beim Booten gelesen, was ihre Lebensdauer massiv verlängert.

Da war noch was...

Das Monitoring. Statt einer schweren „App“ (Docker) nutzen wir die Puristen-Lösung: Eine winzige Binärdatei direkt auf dem Pool. Kein Overhead, maximale Transparenz.

1. Vorbereitung auf dem Pool

In TrueNAS auf System Settings -> Shell folgende Befehle eingeben:

# Ordner erstellen
mkdir -p /mnt/tank/system/node_exporter

# In den Ordner wechseln
cd /mnt/tank/system/node_exporter

# Node Exporter laden (Version 1.9.0 ist aktuell)
wget https://github.com/prometheus/node_exporter/releases/download/v1.9.0/node_exporter-1.9.0.linux-amd64.tar.gz

# Entpacken
tar xvf node_exporter-1.9.0.linux-amd64.tar.gz

# In den entpackten Ordner gehen
cd node_exporter-1.9.0.linux-amd64

2. Testen!

Bevor wir das Ganze automatisieren, testen wir, ob der Exporter die 12-TB-Platten und den N100 sieht:

./node_exporter

• Wenn da steht Listening on :9100, testen wir das im Browser: http://192.168.99:9100/metrics.
• Jede Menge Text? Dann funktioniert es!
• Ich hatte noch die entsprechenden Settings für den Storage auf meinem Monitor-Zima-Blade, die Telemetriedaten waren sofort im Dashboard zu sehen, schön!
• Zurück zur Shell, STRG + C, um den Test zu beenden. Achtung. Wenn Du den Test jetzt beendest, dann streut Dein N100 auch keine Daten mehr. Noch startet hier nichts automatisch.

3. "Autostart" per Init-Script)

Truenas bringt eine eigene Script-Verwaltung. Sorgen wir dafür, dass der Exporter nach jeden Neustart von selbst startet.

1. TrueNAS WebGUI: System Settings -> Advanced.
2. Init/Shutdown Scripts -> Add.
   • Description: Node Exporter Service
   • Type: Command
   • Command:

nohup /mnt/tank/system/node_exporter/node_exporter-1.9.0.linux-amd64/node_exporter > /dev/null 2>&1 &

4. When: Post Init (Das bedeutet: Sobald der Pool tank bereit ist, startet der Exporter).

Einmal speichern und neu starten bitte...
Wir haben hier die perfekte Lösung im Vergleich zum Docker Container. Container brauchen mehrere hundert MB Ram, hier läuft ein Prozess, der nur ein paar MB verbraucht. Und solange die RAM-Preise so exorbitant sind, naja, sind wir hier knausrig.
Im Gegensatz zu einem Docker-Container der auch erst jede Menge Rechte bekommen muss um aus seiner Box auszubrechen sehen wir hier wirklich alles sofort. Temperaturen, NVME-Status, ZFS-Metriken. Alles liegt auf dem Pool, damit wird auch die eMMC geschont.

Und das war’s jetzt eigentlich.

Eine Entscheidung wurde revidiert, ein Gerät getauscht und ein Mindset bestätigt. Bei der Wahl des Betriebssystems war der Weg das Ziel, nur um am Ende wieder am Anfang anzukommen und festzustellen: Der erste Instinkt war der richtige. Open Source ja, aber gerne die professionelle Version davon.

Ich habe 100 Euro mehr für Hardware und etliche Stunden in die Lernkurve investiert. Der Gewinn? Ein System, das nicht nur 'hübsch' ist, sondern das ich bis in die letzte Shell-Zeile verstehe. Jetzt richte ich noch User samt Freigaben ein und befülle den Tresor mit Daten. wintermute.pandolin.online ist bereit.

Und im nächsten Teil? Da lassen wir die Vernunft endgültig hinter uns und ziehen mit dem Ryzen in die Schlacht.

P.S.: 6 Stunden später. Die Daten sind umgezogen. Schauen wir noch schnell, ob die 128 kb Grenze etwas bewirkt hat und der 1 TB-Mirror ein paar mehr Dateien beherbergt als nur die Metadaten mit ein paar hundert Megabyte (wenn es hoch kommt.

Ein schneller Check geht über:

zpool list -v tank

Ein schönes Erfolgsergebnis. Die Dateien unter 128 KB belegen im Special Mirror 1 714 GB. Das Konstrukr funktioniert wie es soll.