Proxmox galt als Homelab-Lösung. Dann meldete jemand 10,000 VMs.

Proxmox VE wird in Produktivumgebungen längst weit über kleine Homelabs hinaus eingesetzt, wie Berichte von Administratoren über Cluster mit mehr als 100 bis hin zu über 10,000 virtuellen Maschinen belegen. Dies sind zwar Selbstauskünfte und keine unabhängig geprüften Gesamtzahlen, doch der entscheidende Härtetest im Betrieb bleibt derselbe: Bewähren sich Storage, Backups und Support auch bei unvorhergesehenen Ausfällen?

Die Erfahrungsberichte behandelten standortübergreifende Cluster, Ceph-Designs, Hardware-Monitoring und die Wahl der Backup-Software. Diese Zahlen verdeutlichen die Bandbreite realer Einsatzszenarien, während die strukturellen Unterschiede zwischen den Umgebungen zeigen, warum eine reine VM-Anzahl allein wenig über die tatsächliche Zuverlässigkeit aussagt.

Wie groß sind gemeldete Proxmox-Produktivumgebungen?

Administratoren berichteten von Installationen, die von einem Cluster mit fünf Nodes und über 100 VMs bis hin zu einer unbestätigten Infrastruktur mit mehr als 10,000 VMs reichten.

Ein Betreiber schilderte ein Setup mit rund 1,000 Produktions-VMs verteilt auf sechs Standorte. Auf Nachfrage präzisierte er die Architektur: Neun Cluster mit insgesamt 41 Hosts, ergänzt durch drei Standalone-Hosts, die primär für Proxmox Backup Server und wenige Hilfs-VMs reserviert sind. Der größte Einzelcluster umfasste acht Nodes, während Proxmox Datacenter Manager als zentrale Verwaltungsebene dient. Diese Differenzierung ist entscheidend. Tausend virtuelle Maschinen auf unabhängige Cluster aufzuteilen, stellt eine ganz andere ingenieurtechnische Herausforderung dar, als tausend Workloads in eine einzige riesige Failure Domain zu pressen. Der Bericht beschrieb einen verteilten Gesamtbestand, nicht einen monolithischen Ausfallbereich.

Danach folgte die spektakulärste Schilderung: Ein anderer Teilnehmer gab an, seine Infrastruktur erstrecke sich über drei Regionen mit jeweils drei Clustern aus 30 bis 40 Servern, die insgesamt mehr als 10,000 VMs hosten. Er beschrieb NVMe-Storage, massive Speicherausstattungen und mehrfach redundante 25 Gb Netzwerkverbindungen. Das ist eine beeindruckende Selbstdarstellung, jedoch kein unabhängig geprüfter Benchmark und keine allgemeine Vorlage zum blinden Nachbauen. Andere Berichte waren deutlich greifbarer: Ein europäischer Bildungsdienstleister betreut 400 VMs auf zwölf Dell PowerEdge-Servern mit Pure Storage über iSCSI, Cisco-Netzwerkkomponenten und Veeam-Backup. Ein weiterer Administrator nannte etwa 800 VMs verteilt auf zwei Rechenzentren. Das weitverbreitete Klischee vom ausgemusterten Homelab-PC geht an der Realität vieler Nutzer völlig vorbei.

Die kleineren Fallbeispiele sind oft noch instruktiver. Ein Unternehmen migrierte von einer VMware Essentials-Umgebung mit drei Hosts auf einen Proxmox-Cluster mit fünf Nodes und behielt dabei Server, Storage und Backup-Lösungen bei. Failover-Tests für ein geplantes ERP-System verliefen erfolgreich, auch wenn sich das Team noch mehr Redundanz auf Netzwerk- und Firewall-Ebene wünschte. Ein anderer Administrator betreibt seit rund zehn Jahren Hunderte Windows- und Linux-VMs auf Proxmox. Ein Universitätsadministrator skizzierte Systeme für Gehaltsabrechnung, ERP, OpenShift, Datenbanken, Authentifizierung, Netzwerkdienste und Content Management. Diese Dienste müssen schlichtweg funktionieren, wenn die Belegschaft am Montagmorgen die Arbeit aufnimmt.

Was macht Ceph in kleinen Proxmox-Clustern riskant?

Die Verfügbarkeit von Ceph steht und fällt mit Failure Domains, Replikationsrichtlinien und ausreichender Restkapazität nach dem Verlust eines Nodes.

Der eingangs erwähnte Fünf-Node-Cluster setzte auf Ceph, was in der Diskussion unmittelbar eine Grundsatzdebatte auslöste. Ein Administrator schilderte ein Ceph-Deployment mit 25 Nodes und lobte die intuitive Verwaltung über das Proxmox-Webinterface. Ein anderer berichtete von einem hyperkonvergenten Zehn-Node-Cluster, der seit fast fünf Jahren rund 230 interne und kundenbezogene VMs mit einer 100 Gb Verbindung zwischen den Nodes stabil bereitstellt. Ein weiterer Teilnehmer wechselte nach Jahren mit iSCSI zu Ceph und bereute diesen Schritt keineswegs. Diese Betreiber verfügten jedoch über die erforderliche Knotenzahl und Netzwerkbandbreite, um verteilten Speicher als bewusste architektonische Entscheidung umzusetzen.

Bevor Sie jedoch voreilige Schlüsse aus hohen VM-Zahlen ziehen, sollten Sie die Ceph-Cluster-Verfügbarkeits-Trade-offs analysieren, die gezielt beleuchten, was nach dem Verlust eines einzelnen Nodes passiert.

In kleinerem Maßstab teilten nicht alle diese Zuversicht. Ein Dienstleister-Administrator erklärte, dass seine hyperkonvergenten Ceph-Cluster mit drei Nodes für interne Managementdienste zwar funktionierten, sich bei einem Node-Ausfall jedoch beunruhigend verwundbar anfühlten. Für geschäftskritische Kunden-Workloads würde er persönlich keinesfalls unter fünf Nodes starten. Das ist eine individuelle Risikoabwägung und kein unumstößliches Gesetz. Dennoch garantiert das Erreichen einer formalen Mindestgröße keineswegs, dass das System genügend Reservekapazität, Fehlertoleranz oder Rebuild-Geschwindigkeit für die anfallende Last besitzt. Ein Teilnehmer schlug vor, ein Zwei-Node-Setup um ein QDevice zu ergänzen, was zu einer wichtigen Klarstellung führte: Ein QDevice sichert das Corosync-Quorum, erschafft aber keinen zusätzlichen Ceph-Speicherknoten und löst keine Risiken bei der Datenplatzierung von Ceph.

Mehrere Administratoren machten bewusst einen Bogen um Ceph. Ein Betreiber schilderte eine Drei-Node-Umgebung mit rund 100 Workloads, die auf ZFS-Pools, Replikation und HA basiert. Ein anderer nutzt LINSTOR für zwei kleine Cluster mit je drei Nodes. Andere setzten auf lokale ZFS-Arrays, externes Fibre-Channel-Storage, iSCSI oder NVMe over TCP. Ein besonders detailreicher Bericht beschrieb Enterprise-SSDs, schnelle Speichernetzwerke und zeitgesteuerte ZFS-Replikation zwischen Availability Domains. Die Vorliebe für asynchrone Replikation entsprang einem wohlüberlegten Kompromiss: Niedrigere Schreiblatenz im Tausch gegen einen Recovery Point, der wenige Minuten hinter der letzten Transaktion zurückbleiben kann. Im Produktivbetrieb zählt letztlich nur, was ausfallen kann, was überlebt und welchen Datenverlust die jeweilige Anwendung verkraftet.

Hinter all den Diskussionen über High-End-Hardware verbarg sich zudem eine erfrischend pragmatische Frage: Wie aufwendig ist der Tausch einer defekten Ceph-Festplatte im Alltag? Ein Teilnehmer antwortete trocken: OSD entfernen, Festplatte tauschen, Ersatzlaufwerk zuweisen und Ceph die Wiederherstellung überlassen. Dieser Ablauf beschreibt zwar die Theorie, spart aber die stressige Praxis aus. Ein Rebalancing bindet erhebliche IOPS und Bandbreite, und der Cluster benötigt ausreichend gesunde Replikate und freien Speicherplatz, um sich gefahrlos zu regenerieren. In kleinen Clustern schrumpft dieser Puffer schneller als gedacht. Ein Wiederherstellungsprozess, der bei vollzähligen, gesunden Hosts trivial wirkt, fühlt sich ganz anders an, wenn Anwendungen bereits unter spürbaren Leistungseinbußen leiden.

Reicht Proxmox Backup Server für die Enterprise-Wiederherstellung?

Proxmox Backup Server ist eine leistungsfähige Wiederherstellungsoption, doch echte Enterprise-Tauglichkeit erfordert regelmäßig getestete Restores und unabhängige Kopien.

Einige der überzeugtesten Produktivanwender nutzten keineswegs denselben Backup-Stack. Ein Betreiber beschrieb Enterprise-Hardware, umfassendes Monitoring, Sicherheits-Scans und eine 3-2-1-Backup-Topologie rund um Proxmox Backup Server. Ein anderer betreibt einen überschaubaren Fertigungscluster mit wenigen kritischen VMs und sichert per PBS inklusive externer Offsite-Kopie. Für diese Administratoren waren Backups kein nachträgliches Beiwerk, sondern das entscheidende Fundament für das Vertrauen in die Plattform. Die offizielle Proxmox Backup Server Dokumentation beschreibt Offsite-Synchronisation und Mehrfachkopien, während die Verifizierungsrichtlinien erklären, wie Sicherungsdaten automatisiert auf Integrität geprüft werden. Keine dieser Funktionen ersetzt jedoch das praktische Einstudieren einer realen Wiederherstellung.

Gleichen Sie Ihre Disaster-Recovery-Konzepte für diese Schicht mit einer praxistauglichen Proxmox-Backup-Strategie inklusive regelmäßiger Restore-Tests ab.

Die Diskussion gewann an Schärfe, als gefragt wurde, warum eine große Proxmox-Installation auf Veeam statt PBS setzte. Eine Antwort war schlicht vertraglicher Natur: Das Unternehmen besaß bereits langfristige Veeam-Lizenzen. Andere Argumente gingen tiefer. Ein Administrator bevorzugte Veeam für Kundensysteme, die keinerlei längere Ausfallzeiten tolerieren durften, da automatisierte Tests und Warm-Standby-Verfahren bestimmten Notfallanforderungen besser entsprächen als ein herkömmlicher PBS-Restore. Ein anderer schätzte PBS zwar, vermisste im direkten Vergleich jedoch Feinschliff, insbesondere bei Tape-Workflows. Dies sind legitime Erfahrungsberichte aus spezifischen Umgebungen, aber keine pauschalen Beweise für die Überlegenheit eines bestimmten Produkts. Funktionsumfang, Softwareversion, Lizenzierung und Wiederherstellungsarchitektur müssen stets individuell auf den Workload abgestimmt werden.

Ein Kommentator fügte eine weitere ironische Facette hinzu: Nach Jahren mit Veeam suchte er nun nach Alternativen, getrieben von steigenden Lizenzkosten und überflüssigen Funktionen. Dieser Frust spiegelt genau den Grund wider, warum viele Unternehmen Proxmox überhaupt erst evaluieren. Der Ausstieg aus einem teuren Virtualisierungs-Ökosystem kann immer noch eine kostspielige Backup-Rechnung hinterlassen, während der Wechsel zu einem schlankeren Tool oft mehr Eigenleistung des internen Teams verlangt. Eine erfolgreiche Wiederherstellung bemisst sich an der Wiederanlaufzeit, dem Datenverlust und der Tatsache, ob der Ablauf jemals zuvor real geprobt wurde.

Wann ist Proxmox bereit für Enterprise-Workloads?

Proxmox ist für einen bestimmten Workload genau dann produktionsreif, wenn das Betriebsteam Kapazitäten, Monitoring,サポートierte Upgradepfade und einen belastbaren Recovery-Plan lückenlos nachweisen kann.

Die vielleicht aufschlussreichste Rückmeldung stammte von einem Administrator, der auf HPE-Server, Enterprise-SSDs, schnelle Arista-Switches, Fortigate-Firewalls, dedizierte Backup-Infrastruktur und routinemäßige Sicherheitsüberprüfungen setzt. Seine Proxmox-Umgebung laufe deshalb so stabil, weil sie die Plattform wie echte Enterprise-Infrastruktur behandeln. Das klingt selbstverständlich, widerspricht jedoch der weitverbreiteten Versuchung, niedrigere Lizenzkosten als Freifahrtschein für Einsparungen an allen anderen Ecken zu missverstehen. Professionelle Hardware, sauber segmentierte Netzwerke, Monitoring, kontrolliertes Change-Management und verifizierte Wiederherstellungspläne bleiben unverzichtbar. Ein Hypervisor entbindet ein Team niemals von diesen Pflichten. Vielmehr muss eine Mannschaft, die ein vertrautes Ökosystem verlässt, erst beweisen, dass sie diese Aufgaben auch unter Druck beherrscht.

Die Diskussion zeigte auch einen weniger radikalen Pfad auf: Belassen Sie die empfindlichsten Systeme vorerst auf der Plattform, der Sie bereits vertrauen. Ein Teilnehmer berichtete von Kunden mit hybriden Umgebungen, die Telemetrie und Steuerungen für Gärtanks auf Hyper-V beließen, während Buchhaltung, Datenbanken und Mailingsysteme auf Proxmox migriert wurden. Das ist keine spektakuläre Gesamtmigration und eignet sich kaum für Hochglanz-Präsentationen, stellt aber eine absolut solide Produktivstrategie dar. Das Unternehmen sammelt reale Erfahrungen mit dem neuen Stack und weitet den Einsatz erst dann aus, wenn Fehlerbilder, Backup-Prozesse und operative Zuständigkeiten verinnerlicht sind. Für viele Teams ist schrittweiser Vertrauensaufbau wertvoller als ein makelloses Architekturdiagramm.

Die geschilderten Beispiele, von wenigen Dutzend Business-Systemen bis hin zu Behauptungen über 10,000 VMs, belegen eine differenziertere Realität als einen pauschalen Sieg von Proxmox über alle Alternativen. Administratoren setzen die Plattform längst für geschäftskritische Aufgaben ein. Ihre Erfolge verdienen Beachtung, doch das gilt gleichermaßen für die Warnungen vor zu kleinen Ceph-Clustern, Replikationslücken, lückenhafter Recovery-Automatisierung und riskanten Upgrades auf stark angepassten Hosts. Kein Online-Forum kann eine Plattform pauschal für die Uptime-Anforderungen eines konkreten Unternehmens zertifizieren. Was die Berichte jedoch leisten können, ist, die bequeme Frage "Taugt Proxmox nur fürs Homelab?" durch die weitaus wichtigere zu ersetzen: Wer übernimmt die Verantwortung dafür, dass die Produktion auch an dem Tag überlebt, an dem nichts nach Plan läuft?

Für den fragenden Betreiber waren ein Cluster mit fünf Nodes und über 100 VMs bereits ein substanzieller Anfang. Die Antworten lieferten Bestätigung, formulierten aber auch einen anspruchsvolleren Maßstab. Die größte Zahl im Raum war kein Gradmesser für Reife. Der Plan für den Ausfall eines Nodes, eines Speicherpools oder eines kompletten Standorts war es.

Ich würde Proxmox für den Produktivbetrieb genau dann freigeben, wenn das Team einen überwachten Ausfall- und Wiederherstellungsprozess sowie ein offiziell unterstütztes Wartungskonzept nachweisen kann, ganz gleich, ob die Umgebung 20 oder 10,000 VMs umfasst. Fehlen diese Voraussetzungen, fangen Sie kleiner an und validieren Sie die Abläufe, bevor Sie weitere Workloads hinzufügen.