NAS selber bauen: Plattform, Speicherpfad und Betriebsgrenze vor der Einkaufsliste klären

Der häufigste NAS-Eigenbaufehler ist nicht die falsche CPU, sondern die falsche Reihenfolge. Viele Setups entstehen aus einer Teileliste und versuchen erst später zu klären, welche Daten wirklich kritisch sind, wie der Pool wachsen soll und wie im Fehlerfall wiederhergestellt wird.

Das BSI beschreibt Datensicherung ausdrücklich als regelmäßigen Prozess für wichtige Daten. Für ein DIY-NAS bedeutet das: Ein Speicher-Host ist erst dann sinnvoll geplant, wenn vor dem Kauf feststeht, welche Daten lokal schnell wiederhergestellt werden müssen, welche Daten extern gesichert werden und welche Dienste überhaupt auf demselben System mitlaufen dürfen.

Ein Eigenbau ist stark, wenn du diese Freiheitsgrade bewusst willst: anderes Gehäuse, andere Laufwerkslogik, anderer Backup-Pfad, andere Erweiterungsstrategie als bei einer Fertiglösung. Wenn du dagegen nur einen kleinen Dateiserver ohne Ausbau- und Wartungsambition suchst, solltest du sehr nüchtern prüfen, ob du wirklich einen Eigenbau pflegen willst.

Die wichtigste Hardwarefrage ergibt sich direkt aus der Plattform. Die offiziellen Dokumentationen zeigen deutlich, dass diese Systeme nicht denselben Betriebsstil erwarten.

Plattform	Offiziell dokumentierter Anker	Planungsfolge
TrueNAS Community Edition	TrueNAS 25.04 nennt aktuell x86_64, 8 GB RAM, 16 GB SSD als Boot-Device und zwei gleich große Devices für einen einzelnen Storage-Pool als Minimum	ZFS- und Storage-Fokus zuerst, danach CPU, RAM und Laufwerkslayout
openmediavault	OMV 8 dokumentiert ein separates System Drive Storage und Data Drive Storage; das Systemlaufwerk kann offiziell nicht für Shares oder User-Daten genutzt werden, und Installationen in LXC oder anderen containerbasierten Lösungen werden nicht unterstützt	Debian-basierter NAS-Pfad mit klarer Trennung von OS-Disk und Daten-Disk, aber mehr Eigenverantwortung für Service-Hygiene
Unraid	Die offizielle Preis- und Lizenzseite führt Starter bis 6 Storage Devices, Unleashed und Lifetime ohne Device-Limit; alle Stufen listen VM and Docker Management als Bestandteil	Lizenz-, Device-Count- und Mischsystem-Logik gehören direkt in die Architekturentscheidung

Wichtig ist also nicht, welches NAS-OS gerade beliebt ist, sondern welchen Betriebscharakter du willst: ZFS-zentrierte Storage-Appliance, Debian-basierter Dateiserver mit klarer Datenträgertrennung oder Mischsystem mit Lizenzgrenzen pro angeschlossenem Speicher. Erst daraus ergeben sich RAM-Ziel, CPU-Klasse, Bootmedium und Ausbaupfad.

Für kompakte Eigenbau-NAS-Projekte wird häufig der Intel Processor N100 als Low-Power-x86-Anker genutzt. Das Intel-Datenblatt ist dafür tatsächlich nützlich, weil es die Grenzen klar benennt: 4 Kerne / 4 Threads, 6 W TDP, maximal 16 GB RAM, kein ECC-Support, aber VT-x und VT-d.

Eigenschaft	Offizieller N100-Wert	Praktische Lesart
CPU	4C / 4T, bis 3,40 GHz	gut für kleine Datei-, Backup- und leichte App-Lasten, aber nicht automatisch für viele parallele Zusatzaufgaben
TDP	6 W	attraktiv für 24/7-Betrieb, wenn der Rest der Plattform ebenfalls sparsam bleibt
RAM	max. 16 GB, kein ECC	eine reale Grenze für speicherhungrige Storage-, VM- oder Mischlast-Pläne
Virtualisierung	VT-x und VT-d vorhanden	technisch nützlich, ersetzt aber keine Ausbauplattform mit viel RAM, vielen Bays oder vielen I/O-Reserven

Einordnung: Dass ein N100-Host oft gut für ein kleines OMV-, Backup- oder Datei-Setup passt, aber schneller an Grenzen kommt als ein größerer Tower- oder Server-Host, ist eine Inferenz aus diesen offiziellen Spezifikationen plus den Anforderungen der NAS-Plattformen. Der entscheidende Punkt ist nicht der CPU-Name, sondern der gesamte Ausbaupfad: Laufwerke, RAM-Obergrenze, Netzwerk, Kühlung und Wartbarkeit.

Für DIY-NAS-Projekte ist der Storage-Pfad fast immer wichtiger als die CPU-Klasse. TrueNAS nennt ein separates 16-GB-SSD-Boot-Device und zwei identisch große Devices für den ersten Pool als Mindestanker. Die Dokumentation sagt zudem klar, dass man Spinner oder USB-Sticks für das Boot-Device vermeiden sollte.

OMV formuliert dieselbe Grundregel noch härter: Das Systemlaufwerk kann offiziell nicht für Shared Resources oder User-Daten genutzt werden, und die Data Drive Storage muss eine andere Disk sein als das Systemlaufwerk. Damit ist Boot-und-Daten-Trennung nicht nur Best Practice, sondern Teil des unterstützten Betriebsmodells.

Planungsfrage	Warum sie vor dem Kauf beantwortet sein muss
Wie viele Laufwerke jetzt und in 12 bis 24 Monaten?	bestimmt Gehäuse, Backplane, Netzteilreserve, Controllerbedarf und Kühlkonzept
Wo liegt das Systemlaufwerk?	trennt OS-Wartung von deinem eigentlichen Datenpfad und reduziert spätere Umbauten
Wo liegen Apps, Datenbanken und Containerdaten?	entscheidet, ob dein Datenpool ruhig bleibt oder zum Mischpfad für alles wird
Wie wichtig sind Hot-Swap, Remote-Konsole oder schneller Laufwerkstausch?	ändert Plattform- und Gehäusewahl oft stärker als die CPU selbst

Ein NAS-Eigenbau wird meist dann teuer und unhandlich, wenn diese Fragen erst nach dem Kauf auftauchen. Dann werden plötzlich USB-Gehäuse, Zusatzcontroller oder sogar ein zweiter Host nötig, nur weil der ursprüngliche Storage-Pfad nie sauber definiert wurde.

Viele Eigenbau-NAS scheitern nicht am ersten SMB-Share, sondern an der schleichenden Rollenvermehrung. Sobald Apps, VMs oder KI-Dienste dazukommen, wird aus einem Speicher-Host ein Mischsystem mit anderen Ausfall-, Update- und Backup-Grenzen.

TrueNAS dokumentiert diesen Punkt offen: Virtuelle Maschinen erhalten einen Teil des System-RAMs und ein neues zvol, und diese Ressourcen stehen dem Host oder anderen VMs während des Betriebs nicht zur Verfügung. Unraid listet VM and Docker Management sogar als eingebauten Teil seiner Plattform. Das ist nützlich, aber es verschiebt die Planungslogik deutlich weg vom reinen NAS.

Frage	Storage-only bleibt sinnvoll, wenn ...	Ein Mischsystem ist vertretbar, wenn ...
Primärziel	Dateifreigaben, Backup, Archiv und ruhige Storage-Dienste stehen im Mittelpunkt	Apps oder VMs sind selbst ein Kernziel und nicht nur ein Nebenversuch
RAM- und SSD-Budget	der Host bleibt knapp dimensioniert und soll vor allem Daten tragen	separate RAM- und SSD-Reserven für App- oder VM-Zustand sind bewusst eingeplant
Änderungsrhythmus	der Host soll möglichst langweilig, ruhig und vorhersagbar bleiben	häufige Stack-Änderungen, Experimente und Rollbacks gehören zum Betriebsmodell
Backup-Einheit	Daten, Shares und externer Restore-Pfad stehen im Fokus	du planst Storage-Zustand und App-Zustand als getrennte Sicherungseinheiten

Einordnung: Für kleine Plattformen wie N100-Systeme ist es oft sauberer, das NAS zuerst als Storage-Host fertigzustellen und App-Stacks später getrennt zu betreiben, zum Beispiel auf einer separaten Linux-VM oder einem zweiten Host. Genau dort setzt auch Proxmox vs. Docker an.

Viele DIY-NAS werden nicht beim Erstaufbau problematisch, sondern beim zweiten Ausbau. Sobald mehr Bays, ein anderer HBA, schnelleres Netzwerk oder deutlich mehr App-Last nötig werden, ist das häufig kein kleines Upgrade mehr, sondern ein Migrationsprojekt.

Änderung	Noch normales Upgrade	Ab wann du es als Migration behandeln solltest
Mehr Kapazität	gleiche Plattform, gleiche Bays, gleiche Verkabelung, gleicher Datenpfad	wenn zusätzliche Gehäuse, Controller oder externe Laufwerkslösungen nötig werden
Mehr Performance	kleine SSD-Ergänzung oder saubere Netzwerkerweiterung im bestehenden Design	wenn Apps, Datenbanken oder VMs plötzlich den Storage-Host dominieren
Plattformwechsel	praktisch nie	OMV zu TrueNAS, TrueNAS zu Unraid oder umgekehrt ist immer ein eigenes Projekt mit Test und Restore-Plan
Mehr Dienste	nur wenn deren Datenpfad, RAM-Bedarf und Backup-Scope schon eingeplant sind	wenn Dienste erst später einen SSD-Pfad, andere Ports oder eigene Wartungsfenster erzwingen

Die wichtigste Betriebsfrage lautet deshalb nicht nur "Passt das noch rein?", sondern "Bleibt das System noch dasselbe?" Wenn die Antwort nein ist, solltest du nicht von Upgrade sprechen, sondern von Migration mit Abnahme- und Rollback-Logik.

Der größte Planungsfehler beim DIY-NAS ist nicht ein einzelnes falsches Bauteil, sondern ein unvollständig freigegebener Einkauf. Praktisch brauchst du vor dem Kauf mindestens drei getrennte Sichten: Wie viel Netto-Kapazität und Redundanz ist fachlich nötig? Was kostet der Host im 24/7-Betrieb? Wie schnell kommst du im Notfall wieder an die Daten?

Prüffeld	Womit du es sauber prüfst	Warum diese Sicht separat bleibt	Typischer Fehlkauf ohne diese Prüfung
Netto-Kapazität und Redundanz	RAID-Rechner plus RAID-Vergleich	die Pool-Logik beantwortet, wie viel Speicher nach Mirror oder Parität wirklich übrig bleibt	zu wenige Bays oder das falsche Laufwerkslayout für das tatsächliche Nettoziel
Dauerlast und Jahreskosten	NAS-Rechner plus Stromkosten-Rechner	ein kleiner CPU-Anker sagt noch nichts über Gehäuse-, Laufwerks- und 24/7-Kosten des Gesamtsystems	ein vermeintlich sparsamer Eigenbau, der mit mehreren Bays oder Dauerbetrieb plötzlich wirtschaftlich kippt
Restore- und Migrationsfenster	Transfer-Rechner plus Backup-Strategie 3-2-1	ein funktionsfähiger Pool beantwortet noch nicht, wie schnell externe Sicherungen oder ein Plattformwechsel real zurückkommen	Off-Site existiert formal, ist aber im Schadenfall zu langsam oder organisatorisch unklar

Einordnung: Diese Matrix ist eine Betriebsinferenz aus den oben dokumentierten Plattform-, Storage- und Backup-Grenzen. Sie ist gerade deshalb nützlich, weil sie drei Fragen trennt, die in Bastelprojekten oft zu früh vermischt werden. Ein Einkauf ist erst dann fachlich konsistent, wenn Array, 24/7-Budget und externer Wiederanlauf zueinander passen.

1. Zielbild schriftlich festhalten: Datenklassen, Diensteliste, Wachstum, externes Backup-Ziel.
2. Plattform festlegen: TrueNAS, OMV oder Unraid nicht nach Stimmung, sondern nach Betriebsmodell auswählen.
3. System- und Datenpfad trennen: OS/Boot, Datenpool und App-Zustand nicht unbewusst vermischen.
4. Laufwerkslayout prüfen: Anzahl Bays, Verkabelung, Netzteilreserve, Luftpfad und kühle Laufwerkszonen.
5. Shares, Snapshots und Replikation nach dem Grundsystem: erst wenn Storage sauber steht, kommen Zusatzdienste darauf.
6. Externe Sicherung und Restore-Test einrichten: vor produktiver Nutzung, nicht irgendwann danach.

Diese Reihenfolge ist nicht spektakulär, aber professionell. Sie verhindert, dass ein NAS zwar bootet, aber weder planbar wächst noch sauber gesichert ist.

Ein DIY-NAS wird oft zu früh als "fertig" betrachtet, sobald die Shares stehen. In Wahrheit beginnt die kritische Phase erst dann, wenn Altbestände, externe Platten oder ein altes NAS in den neuen Datenpfad überführt werden. Genau dort treffen Transferfenster, Restore-Logik und Poolstruktur aufeinander.

Cutover-Schritt	Was vorher klar sein muss	Hilfreicher Prüfpfad
Erstbefüllung des neuen Pools	welche Daten wirklich primär werden und welche zunächst nur gespiegelt oder kopiert werden	Transfer-Rechner für das Zeitfenster und Backup-Strategie 3-2-1 für den Rückweg
Umzug laufender Freigaben	welche Clients, Shares und Pfade nach dem Cutover sofort wieder erreichbar sein müssen	Share- und Mount-Plan direkt im Betriebsblatt festhalten
Migration von App- oder Containerdaten	ob diese Daten überhaupt auf dem Storage-Host bleiben oder auf einen getrennten App-Pfad gehören	Proxmox vs. Docker für die Mischlastgrenze
Abschaltung des alten Systems	dass ein externer Restore bereits funktioniert und das neue System nicht die einzige Wahrheit ist	ein erster Datei- oder Service-Restore vor der endgültigen Umschaltung

Damit wird der Umzug vom Kopierjob zum kontrollierten Cutover. Genau das unterscheidet einen produktionsreifen Eigenbau von einem Speicherhost, der nur im Leerlauf sauber aussieht.

Ein DIY-NAS ist nicht produktionsreif, nur weil Shares erreichbar sind. Vor dem Livegang sollte mindestens ein kleines Abnahmeprotokoll existieren.

Prüffeld	Bestanden, wenn ...	Nicht bestanden, wenn ...
System- und Datenpfad	Bootmedium, Datenpool und App-/Metadatenpfad sind dokumentiert und getrennt	Systemdisk wird später doch als Dateispeicher oder Containerablage missbraucht
Pool- und Share-Logik	klar ist, welche Freigabe auf welchem Pool oder Dataset liegt	Shares nur "irgendwo" liegen und bei Umbauten schwer zuzuordnen sind
Gesundheitssicht	SMART, Pool-Status und Warnpfade sind prüfbar	du erst im Fehlerfall feststellst, dass Laufwerke oder Alarme nicht sauber sichtbar sind
Backup und Restore	mindestens ein externer Sicherungspfad und ein Datei-Restore nachweislich funktionieren	nur Snapshots existieren oder Restore nie getestet wurde
Change-Log	Plattform, Laufwerkslayout, Shares und Backup-Ziel sind schriftlich festgehalten	das NAS nur im Kopf des Erbauers dokumentiert ist

Gerade bei Eigenbauten ist dieses Mini-Runbook der Unterschied zwischen einem robusten Speichersystem und einem Bastelprojekt, das nur solange funktioniert, wie niemand etwas ändert.

Viele Eigenbauten verlieren Qualität nicht am ersten Boot, sondern in den ersten Wochen: zusätzliche Container, neue Freigaben, nicht dokumentierte Laufwerke, fehlende Alarmierung. Genau deshalb hilft ein bewusstes 30-Tage-Runbook.

Fenster	Worauf du schaust	Warum es früh passieren sollte
Woche 1	Pool-Status, SMART, Share-Pfade und erster Datei-Restore	damit Basisgesundheit und Wiederanlauf nicht bis zum ersten Problem offen bleiben
Woche 2	Dauerlast, Laufwerksverhalten und Hostkosten im Alltag	hier zeigt sich, ob der Eigenbau wirtschaftlich und thermisch zu knapp geplant wurde
Woche 3	Änderungswünsche wie Docker, VMs oder zusätzliche Dienste gegen die Mischlastgrenze prüfen	damit das NAS nicht schleichend vom Storage-Host zum Alles-Server wird
Woche 4	Backup-Rhythmus, Off-Site-Pfad und Monitoring in ein stabiles Betriebsblatt überführen	erst danach ist das System wirklich in einen wiederholbaren Betrieb überführt

Dieses Runbook ist absichtlich schlicht. Es sorgt aber dafür, dass Ausbauwünsche, Stromprofil und Restore-Nachweise in denselben ersten 30 Tagen sichtbar werden, statt Monate später als Überraschung aufzuschlagen.

Der wichtigste Realitätscheck kommt erst nach dem ersten erfolgreichen Share: Kannst du die Daten außerhalb dieses Hosts wiederherstellen? Das BSI empfiehlt für wichtige Daten regelmäßige Datensicherung und macht deutlich, dass nicht jede Datei gleich behandelt werden muss. Genau diese Logik gehört auch in ein DIY-NAS.

Schutzniveau	Wofür es gut ist	Wofür es nicht reicht
Snapshots / Versionierung	Fehlbedienung, versehentliche Änderungen, kurze Rücksprünge	Standortverlust oder Defekt des gesamten Hosts
lokale externe Sicherung	schnelle Wiederherstellung nach Primärdefekt	Brand, Diebstahl, gemeinsamer Strom- oder Schadenspfad
Off-Site- oder Offline-Backup	Standorttrennung und echter Notfallpfad	ersetzt nicht automatisch lokale Restore-Geschwindigkeit

Ein DIY-NAS ist deshalb erst dann fertig, wenn mindestens ein getrennter Backup-Pfad und ein echter Restore-Test dokumentiert sind. Ein funktionierender Pool ohne Wiederherstellungspfad ist kein fertiges Speichersystem.

Ein Eigenbau ist nicht automatisch die vernünftigste Wahl. Wenn dein Ziel nur ein kleiner Dateiserver mit wenigen Freigaben ist, kein Ausbau geplant ist und du weder Plattformpflege noch Backup-Runbook selbst betreiben willst, kann eine Fertiglösung oder ein schlichter externer Backup-Host sinnvoller sein.

Einordnung: Diese Empfehlung ist eine Inferenz aus den offiziellen Hardware- und Betriebsmodellen. Je mehr Freiheitsgrade du kaufst, desto mehr Verantwortung übernimmst du auch: Updates, Laufwerkspflege, Bootmedien, Lizenzmodell, Backup und Wiederherstellung. Wenn du diese Verantwortung nicht bewusst willst, ist "selber bauen" kein Qualitätsmerkmal.