Proxmox braucht keinen TrueNAS-Killer. Es braucht eine Storage-Story, die Sinn ergibt.

Die Idee, die offensichtlich klingt, bis man sie anfasst

Jede populäre Plattform erreicht irgendwann denselben unangenehmen Moment: Die Nutzer fragen nicht mehr, was sie kann, sondern warum der Rest ihres Stacks überhaupt noch existieren muss. Proxmox betreibt bereits die Hosts. Es versteht bereits VMs, Container, ZFS-Pools, Clustering, Backups, Berechtigungen und genug Storage-Integration, um ein Homelab wie eine kleine private Cloud wirken zu lassen. Der Pitch schreibt sich also fast von selbst: Warum nicht auch ein eigenes Proxmox-Storage-Produkt bauen? Nennen wir es ProxStorage. Machen wir es einfach. Machen wir es Debian-basiert. Machen wir es rein ZFS. Weg mit dem App-Store-Gerümpel, der Plugin-Wucherung, der Identitätskrise. NFS und iSCSI exportieren. Proxmox die Snapshots sauber verwalten lassen. Den Nutzern ein Ökosystem geben statt einer weiteren Appliance mit einem weiteren Dashboard und einem weiteren Satz Annahmen.

Diese Idee traf einen Nerv, weil sie etwas Echtes anspricht. Viele Leute mögen TrueNAS für das, was es am besten kann, aber sie sind es leid, zuzusehen, wie Storage-Plattformen in Richtung „Alles-Box" abdriften. Apps, Plugins, UI-Wandel, Produktsegmentierung, kommerzielle Verunsicherung, glänzende Nebenprojekte – all das lässt manche Nutzer sich wieder eine langweilige Storage-Appliance wünschen. Keinen Kubernetes-Spielplatz. Keinen Mediaserver-Launcher. Keine Lifestyle-Marke für Festplatten. Einfach nur ein seriöses, ZFS-gestütztes Storage-Ziel für Virtualisierung. Etwas, das sagt: Hier sind Ihre Pools, Datasets, Snapshots, NFS-Exports, iSCSI-Targets, Replikationsjobs und Berechtigungen. Schlafen Sie gut.

Der Reiz ist offensichtlich. Eine Storage-Appliance, gebaut von denselben Leuten, die Proxmox VE bauen, könnte sich nativer anfühlen, als es TrueNAS, OpenMediaVault, XigmaNAS oder eine selbstgebastelte Debian-Kiste je könnten. Stellen Sie sich Storage-Snapshots vor, die in der Proxmox-UI wie Backups auftauchen. Stellen Sie sich VM-bewusste Snapshot-Koordination ohne Klebeband vor. Stellen Sie sich eine saubere Oberfläche vor, gebaut darum, PVE-Cluster zu bedienen, statt jedes erdenkliche NAS-Hobby. Stellen Sie sich weniger Übersetzungsschichten zwischen „Ich brauche zuverlässigen VM-Storage" und „hier ist das Ding, das diesen Job erledigt" vor.

Das ist der Traum. Das Problem ist, dass Storage-Träume die unangenehme Angewohnheit haben, sich in Support-Albträume zu verwandeln.

TrueNAS ist nicht nur ein Fileshare mit hübscher Oberfläche

Ein Großteil der anfänglichen Verwirrung entstand, weil Leute den Vorschlag behandelten, als ginge es um simples File-Sharing. Jemand fragte, warum man überhaupt TrueNAS brauche, wenn man einfach eine winzige NAS-VM in Proxmox laufen lassen könnte. Ein anderer wies darauf hin, dass Proxmox bereits ZFS-Pools und sogar einen UI-Bereich dafür habe. Das stimmt, aber es verfehlt den Kern der Idee. Der Vorschlag lautete nicht wirklich „Lass mich einen Ordner freigeben." Er lautete „Gib Proxmox ein dediziertes Storage-Backend, das mit der SAN-Rolle konkurriert, die TrueNAS oft übernimmt."

Diese Unterscheidung zählt. TrueNAS stammt aus einer Welt, in der Bare-Metal-Storage der eigentliche Punkt war. Performance, Replikation, skalierbare Pools, Block-Storage und sauberes Management waren das Produkt, keine Nebenaufgabe. Ein Kommentator beschrieb den Betrieb einer Bare-Metal-TrueNAS-Box mit rund 300 TB Storage, von denen ein Teil iSCSI-Block-Storage bereitstellte, der früher VMware und heute Proxmox versorgt. Das ist nicht dasselbe wie eine Mikro-NAS-VM, die eine Familienfoto-Freigabe bedient. Das ist Infrastruktur. Es ist ein Storage-Subsystem.

Die faire Version der ProxStorage-Idee lautet also nicht „Proxmox sollte TrueNAS klonen, weil ich keine Plugins mag." Sie lautet „Proxmox könnte sein Ökosystem mit einem konvergenten Storage-Produkt abrunden, nicht nur mit hyperkonvergentem Ceph." Das ist viel interessanter. Ceph ist bereits Teil der Proxmox-Geschichte, aber Ceph ist keine beiläufige Single-Box-Storage-Appliance. Es will mehrere Nodes. Es will Planung. Es will Netzwerk, Disks, Monitore, OSDs, Failure Domains und eine gewisse emotionale Reife. Ein NAS- oder SAN-Produkt kann gerade deshalb nützlich sein, weil es keine drei oder mehr physischen Maschinen braucht, um sinnvoll zu sein.

Dieser Punkt kam auch direkt zur Sprache: Ein NAS sollte nicht 3 oder mehr Geräte brauchen, um zu funktionieren. Jemand anderes widersprach, dass ein sicheres, skalierbares NAS in einem kleinen Unternehmen absolut seinen Platz habe, selbst wenn ein winziges Homelab mit weniger auskommt. Beide Seiten haben recht. Eine einzelne Storage-Appliance ist nicht dasselbe wie ein verteilter Storage-Cluster, und so zu tun, als würden beide dasselbe Problem lösen, ist der Grund, warum Leute am Ende wütend auf Ceph sind, weil es kein Synology ist, oder wütend auf ein NAS, weil es kein Scale-out-Storage-Fabric ist.

Die stärkste Unterstützung für den Vorschlag kam von Leuten, die diesen Mittelweg verstanden. Ein dediziertes, Proxmox-verwaltetes ZFS- und vielleicht Ceph-bewusstes Storage-Ziel, speziell für PVE gebaut, könnte nützlich sein. Nicht weil TrueNAS schlecht ist. Nicht weil bestehende Tools nicht funktionieren. Sondern weil das Proxmox-Ökosystem eine Lücke zwischen „lokalem ZFS auf jedem Host" und „vollständigem Ceph-Cluster" hat. In dieser Lücke lebt ein Großteil des echten Storage in kleinen Unternehmen und Labs.

Die „Nutzt doch einfach, was schon da ist"-Fraktion liegt nicht falsch

Die andere Seite des Arguments ist brutal praktisch: Warum sollte Proxmox ein ganzes Storage-Produkt bauen, wenn die Bausteine schon existieren? Sie können ZFS direkt auf einem PVE-Node aufbauen. Sie können Datasets über einen LXC-Container mit Samba exportieren. Sie können XigmaNAS oder ein anderes NAS-Betriebssystem in eine VM packen. Sie können NFS und iSCSI von Hand auf Debian aufsetzen. Sie können TrueNAS bare metal betreiben. Sie können OpenMediaVault nutzen. Sie können ein kommerzielles SAN nutzen. Das Ökosystem ist nicht leer. Es ist unordentlich, aber nicht leer.

Ein Kommentator schlug XigmaNAS vor und beschrieb es als langjährigen FreeNAS-Fork, der vieles von dem bietet, was gefragt wird. Ein anderer schlug vor, LXC „Zamba" zu nutzen und ein ZFS-Dataset zu exportieren. Jemand anderes merkte an, dass man auf Proxmox ein ZFS-Dataset anlegen und Storage so in eine VM durchreichen kann, dass der Pool auf PVE bleibt. Das sind keine Fantasie-Vorschläge. Es ist genau so, wie viele Leute dieses Problem heute lösen: ZFS dort behalten, wo Proxmox es sehen kann, und dann einen leichtgewichtigen Dienst oder eine VM nutzen, um es freizugeben.

Das Problem ist, dass „das kann man schon machen" nicht dasselbe ist wie „es gibt ein kohärentes Produkt dafür." Ein handgebauter ZFS-Export-Stack mag für die Person, die ihn gebaut hat, wunderbar funktionieren. Für den nächsten Admin ist er vielleicht ein verwirrender Haufen Annahmen. TrueNAS existiert, weil Storage-Management nicht nur aus Befehlen besteht. Es ist Lifecycle, Berechtigungen, Alerts, Replikation, Snapshots, Freigaben, Monitoring, Upgrades und Recovery. Eine Proxmox-native Storage-Appliance müsste all das leisten, ohne zu dem aufgeblähten Ding zu werden, das sie angeblich ersetzen sollte.

Das ist der schwierige Teil. Jeder will „einfach." Niemand ist sich einig, wo einfach endet. Fügen Sie nur NFS und iSCSI hinzu, und sofort fragt jemand nach SMB. Fügen Sie SMB hinzu, und jemand fragt nach Object Storage. Fügen Sie Object Storage hinzu, und schon driften Sie in genau die Feature-Wucherung ab, die alle vermeiden wollten. Fügen Sie Apps hinzu, und der Pitch stirbt komplett. Fügen Sie keine Apps hinzu, und ein Teil des NAS-Markts zuckt mit den Schultern und bleibt, wo er ist. Produktfokus klingt einfach, bis jedes fehlende Feature für irgendjemanden ein Dealbreaker ist.

Es gab auch einen vernünftigen verfahrenstechnischen Einwand: Feature-Wünsche gehören in Bugzilla, nicht nur in beiläufige Diskussionen. Das ist keine romantische Antwort, aber die erwachsene. Wenn das Ziel ist, Entwickler anzuziehen, braucht ein echter Feature-Wunsch Scope, Use Cases, Non-Goals, Integrationspunkte und einen Grund, warum es dem Unternehmen hinter Proxmox helfen würde. „Bitte baut ein Storage-Betriebssystem" ist keine kleine Bitte. Es ist eine Produktlinie.

Die TrueNAS-Verunsicherung dreht sich eigentlich um Vertrauen

Die Kritik an TrueNAS hatte eine emotionale Kante. Es war nicht nur „Ich bevorzuge eine andere Oberfläche." Es war „Das Ding fühlt sich aufgebläht an, die UI ändert sich ständig, und was, wenn es noch kommerzieller wird?" Diese Angst ist in Open-Source-nahen Communities verbreitet. Leute bauen ihr Zuhause, ihre Labs und ihre Unternehmen auf einem Tool auf und beobachten dann, wie sich das Unternehmen dahinter weiterentwickelt. Plötzlich gibt es neue Produkte, neues Branding, neue Prioritäten, und die Nutzer fragen sich, ob sie noch die Zielgruppe sind.

Ein Teil dieser Verunsicherung mag unfair sein. TrueNAS erfüllt weiterhin eine wichtige Rolle und hat eine lange Erfolgsbilanz. Es ist nicht falsch, wenn ein Storage-Produkt eine polierte UI, kommerzielle Angebote oder größere Ambitionen hat. Unternehmen brauchen Geld. Entwickler brauchen Gehälter. Hardware-Hersteller brauchen Kunden. Dass ein Projekt am Leben bleibt, bedeutet meist, dass jemand für den Sauerstoff bezahlt.

Aber das Unbehagen ist trotzdem real. Nutzer, die eine Storage-Appliance für Proxmox wollen, wollen nicht unbedingt eine Allzweck-NAS-Plattform mit eigener Persönlichkeit. Sie wollen etwas Ruhigeres. Ein Storage-Ziel mit weniger Meinungen außerhalb seiner Spur. Etwas, das sich nicht so anfühlt, als könnte es zu einem weiteren Ökosystem werden, das man erst entschlüsseln muss. In diesem Sinne geht es bei der ProxStorage-Idee weniger darum, TrueNAS zu hassen, als vielmehr darum, Storage zu wollen, das sich wie Teil desselben operativen Gehirns wie Proxmox anfühlt.

Deshalb ist die Snapshot-Idee wichtig. „Die VM sieht native ProxStorage-Snapshots" mag vage klingen, aber der Wunsch dahinter ist scharf umrissen: Nutzer wollen storage-bewusste Virtualisierung ohne klobige Grenzen. Sie wollen, dass Hypervisor, Storage-Ziel und Backup-System sich gegenseitig verstehen. Proxmox Backup Server zeigt bereits, wie wertvoll dieses Ökosystem-Denken sein kann. Es speichert nicht nur Dateien. Es passt zu der Art, wie PVE über Backups denkt. Eine Proxmox-Storage-Appliance könnte theoretisch dasselbe für Shared Storage leisten.

Trotzdem gilt Vertrauen in beide Richtungen. Nutzer vertrauen Proxmox vielleicht, aber Proxmox müsste sich Vertrauen in einer neuen Kategorie erst verdienen. Storage-Appliances werden hart beurteilt, weil Datenverlust unverzeihlich ist. Eine raue Kante in einer VM-UI ist nervig. Eine raue Kante im Storage-Replikationsverhalten oder bei iSCSI kann ein unternehmensbeendendes Ereignis werden. Ein „Sorgenfrei-Storage"-Produkt klingt wunderbar. Es klingt aber auch wie ein Erpresserbrief aus der zukünftigen Support-Warteschlange.

Das fehlende Produkt ist real, aber die Falle auch

Die überzeugendste Version von ProxStorage wäre schmal geschnitten. Debian-basiert. ZFS zuerst. Kein App Store. Kein Docker-Theater. Starkes NFS und iSCSI. Klarer SMB-Support, aber nur, wenn das Produkt bereit ist, ihn richtig zu betreuen. Proxmox-native Authentifizierung. Snapshot- und Replikations-Workflows, die zu PVE passen. Gutes Monitoring. Großartige Alerts. Erstklassige Dokumentation. Ein sauberer Upgrade-Pfad. Vielleicht optionale Ceph-Integration für größere Designs, aber keine erzwungene Ceph-zuerst-Geschichte. Im Grunde: eine Storage-Appliance für Leute, die einen SAN/NAS-Begleiter für Proxmox wollen, kein Lifestyle-NAS.

Das könnte kraftvoll sein. Es würde kleinen Betrieben und Labs eine sauberere Alternative zu „TrueNAS bare metal installieren und verkabeln" oder „einen Haufen individueller Debian-Storage-Arbeit machen und hoffen, dass alle dokumentieren" geben. Es würde MSPs und internen IT-Teams eine konsistentere Support-Story geben. Es würde Nutzern helfen, die Shared Storage wollen, aber nicht die Komplexität von Ceph oder die Weitläufigkeit einer allgemeinen NAS-Appliance. Es würde das Ökosystem auf eine Weise erweitern, die sich natürlich anfühlt.

Aber es würde auch um Entwickler-Aufmerksamkeit konkurrieren, gegen alles, was Proxmox bereits pflegen muss: PVE, PBS, Mail Gateway, SDN, Clustering, HA, Ceph-Integration, ZFS-Integration, Backup-Verbesserungen, UI-Arbeit, Kernel-Probleme, Hardware-Support, Dokumentation und Enterprise-Support. Ein Storage-Produkt ist nicht „wenig Arbeit", nur weil Debian und ZFS schon existieren. Der Wert liegt nicht in den Paketen. Der Wert liegt in der Integration, den Tests, den Leitplanken und dem Support. Das ist der teure Teil.

Und die Community würde sich sofort spalten. Manche würden sagen: „Endlich ein sauberes Proxmox-SAN." Andere würden sagen: „Warum TrueNAS duplizieren?" Manche wollten Ceph fest eingebaut. Manche würden SMB fordern. Manche wollten Object Storage. Manche wollten eine Single-Node-Appliance. Manche wollten HA-Storage. Manche würden darauf bestehen, dass ein NAS einfach sein muss. Manche würden darauf bestehen, dass einfach unverantwortlich ist. Das Produkt würde in tausend Erwartungen hineingeboren.

Das heißt nicht, dass es das Produkt nicht geben sollte. Es heißt, dass der Vorschlag Disziplin braucht. Die gewinnende Idee ist nicht „TrueNAS ersetzen." Das ist zu breit, zu emotional und wahrscheinlich unnötig. Die bessere Idee ist „eine Proxmox-Storage-Appliance bauen, die sich darauf konzentriert, das beste Shared-Storage-Backend für PVE zu sein." Das ist ein saubereres Ziel. Es muss nicht die gesamte NAS-Welt gewinnen. Es muss nur die Proxmox-Storage-Lücke besser lösen als der aktuelle Flickenteppich.

Die besten Ideen fangen meist als Beschwerden an

Was diese Diskussion interessant macht, ist, dass der ursprüngliche Pitch unordentlich war, der Instinkt dahinter aber stark. Die Leute wollen tatsächlich Storage, das sich nativ zu ihrer Virtualisierungsplattform anfühlt. Sie wollen tatsächlich weniger Bloat. Sie wollen tatsächlich eine Alternative zwischen lokalem ZFS und vollem Ceph. Sie wollen tatsächlich Snapshots, Replikation, NFS, iSCSI und PVE-Integration, ohne ein separates Universum jonglieren zu müssen. Und ja, manche Leute sind es leid, zuzusehen, wie Storage-Plattformen zu App-Plattformen mit angeschlossenen Festplatten werden.

Auch die Kritiker hatten einen Punkt. Proxmox hat bereits ZFS. Bestehende NAS-Tools existieren bereits. TrueNAS ist nicht nur Bloat. XigmaNAS, OMV, handgebautes Debian und einfache Container-Exports decken bereits viele Use Cases ab. Ein neues Produkt würde Support-Last, Scope Creep und tausend Wege bringen, Leute zu enttäuschen. „Sorgenfreies Storage" ist die Art von Phrase, die großartig klingt, bis der erste Nutzer einen Pool verliert, weil er sich durch eine Warnung geklickt hat, die er nicht verstanden hat.

Es gibt hier eigentlich drei Lager. Das erste will eine Proxmox-native Storage-Appliance, weil sich das Ökosystem ohne sie unvollständig anfühlt. Das zweite sagt, die bestehenden Tools reichten aus, und Proxmox solle keine Energie darauf verschwenden, Storage-Management neu zu erfinden. Das dritte sieht das größere Bild: Es mag Raum für ein konvergentes Storage-Produkt geben, aber nur, wenn es fokussiert darauf bleibt, Proxmox-Cluster zu bedienen, statt jedem erdenklichen NAS-Feature hinterherzujagen.

Dieses dritte Lager kommt der Wahrheit wahrscheinlich am nächsten. Proxmox muss TrueNAS nicht töten. Es muss es nicht klonen. Es muss nicht zu einem weiteren aufgeblähten NAS mit App-Katalog und Identitätskrise werden. Aber ein sauberer, fokussierter Storage-Begleiter, aufgebaut um ZFS, Shared Block-/File-Exports, Snapshots und PVE-bewusste Workflows? Das ist keine alberne Idee. Das ist die Art von fehlendem Puzzlestück, nach dem Nutzer zu fragen beginnen, wenn eine Plattform wichtig genug wird, um das ganze Lab oder Unternehmen darum herum zu organisieren.

Die eigentliche Frage ist, ob Proxmox diese Verantwortung übernehmen will. Denn Storage zu bauen ist einfach, auf dieselbe Weise, wie eine Brücke zu bauen einfach ist: Die Form ist offensichtlich, die Materialien existieren, und alle sind sich einig, wo das andere Ufer liegt. Der schwierige Teil besteht darin, dass die Leute ihr auch vertrauen, wenn sie darüberfahren.