Veeam Sizing für 500 bis 2.000 VMs: Proxys, Repositories, Transportmodi und das Backup-Fenster

Veeam Sizing für 500 bis 2.000 VMs: was die Zahlen bestimmt

Das Veeam Sizing für eine große VMware-Umgebung geht von zwei Eingangsgrößen aus: der Menge an Quelldaten, die die Jobs lesen, und der Länge des Backup-Fensters. Daten geteilt durch Fenster ergibt den Durchsatz, den die Backup-Proxys halten müssen, und Veeams Best-Practice-Leitfaden rechnet diesen Durchsatz in Proxy-Kerne um, dann die Proxy-Kerne in Kerne und Arbeitsspeicher des Repositorys. Die tägliche Änderungsrate bestimmt die Last der Inkremente, während die Vollsicherungen, die jede VM vom Produktionsspeicher lesen, meist die Spitze setzen.

Die Zahlen stammen aus Veeams Best-Practice-Leitfaden (bp.veeam.com) und dem Help Center für Veeam Backup & Replication 13 (13.1 seit dem 29. Juli 2026, laut KB2680), gelesen am 10. Oktober 2026.

Veeam Best Practice Guide für Veeam Backup & Replication (bp.veeam.com, © 2025): Seiten zu vSphere Proxy Design, Repository Design, Initial Sizing Recommendations und Backup Job Storage; Veeam Data Platform 13 Recommended Maximums. Gelesen am 10. Oktober 2026.

Veeam-Proxy-Dimensionierung: Kerne, Tasks und Arbeitsspeicher

Der Leitfaden nennt den Durchsatz je Kern für einen VMware-Backup-Proxy: 180 MB/s für Vollsicherungen und 80 MB/s für Inkremente bei einem virtuellen Proxy, der auf Blockspeicher schreibt, und 250 MB/s für beides bei einem physischen Proxy. Auf Objektspeicher betragen die Werte 110 und 80 MB/s für einen virtuellen und 150 MB/s für einen physischen Proxy.

Ein Task verarbeitet jeweils eine VM-Platte. Der Leitfaden empfiehlt zwei Proxy-Tasks je physischem Kern oder vCPU und bis zu 2 GB RAM je Kern. Veeams Hinweise zu Backup-Jobs vermerken, dass ein Proxy mit acht CPU-Kernen standardmäßig bis zu acht gleichzeitige Tasks ausführt; zwei Tasks je Kern bedeuten also, das Limit gleichzeitiger Tasks jedes Proxys über diesen Standardwert zu setzen. Der Leitfaden verlangt mindestens zwei Proxy-Server je Standort, und Replikationsjobs brauchen Proxy-Ressourcen an Quelle und Ziel, wie unser Vergleich von Veeam-Replikation, Backup Copy und Cloud Connect erklärt.

Version 13 kann den Backup-Datenstrom mit Inline-Entropieanalyse prüfen, die ein Malware-Erkennungsereignis auslöst, wenn verschlüsselte Daten die Empfindlichkeitsgrenzen überschreiten. In Veeams Testtabelle für Proxys schrieb ein virtueller Hot-Add-Proxy mit 8 vCPU und 16 GB RAM aktive Vollsicherungen mit 1.440 MB/s auf direkt angeschlossenen Blockspeicher und mit aktivierter Analyse mit 800 MB/s, während Inkremente bei 640 MB/s blieben. Das sind bei eingeschalteter Prüfung etwa 100 MB/s je vCPU für Vollsicherungen, der Wert, den unser Beispiel verwendet, und Veeam ergänzt, dass der Durchsatz in der Produktion abweichen kann.

Veeam-Transportmodi: Direct Storage Access, Hot-Add und Network Mode

Das Veeam Help Center führt drei Transportmodi „beginnend mit dem effizientesten“ auf: Direct Storage Access (Direct SAN, Direct NFS oder Storage-Integration), Virtual Appliance (Hot-Add) und Network Mode. Veeam empfiehlt Hot-Add, wenn der Proxy als VM läuft; der Network Mode funktioniert mit jeder Konfiguration, hat aber in Veeams Worten eine „geringe Datenübertragungsgeschwindigkeit“.

Veeam Help Center, Benutzerhandbuch zu Veeam Backup & Replication 13 (Transport Modes, Direct Storage Access, Virtual Appliance Mode, Network Mode); Veeam-BP-Leitfaden, Seite vSphere Proxy Build; Veeam KB1681 (geändert am 3. August 2026); Broadcom, Best Practices for NBD Transport (24. Januar 2025).

Veeams KB1681 beschreibt VMs auf NFS-3.0-Datastores, die beim Entfernen des Snapshots hängen bleiben, wenn ein Hot-Add-Proxy auf einem anderen Host ihre Platten verarbeitet; laut dem KB-Artikel wurde dies „in VMware ESXi 8.0 Update 2b behoben“. Er verweist außerdem auf Broadcoms KB428200, ein verwandtes Hängenbleiben auf NFSv3-Datastores mit Changed Block Tracking, das auch in späteren Builds bestehen bleibt, und nennt Direct NFS Access „die empfohlene Lösung“.

Broadcom empfiehlt, je ESXi-Host höchstens 50 Platten parallel zu sichern, und seit vSphere 7.0 unterstützen Hosts ein eigenes NBD-Netz, den Dienst vSphere Backup NFC eines VMkernel-Adapters.

Veeam-Repository-Größe und Scale-out Backup Repositories

Für Repository-Server empfiehlt Veeams Leitfaden nach Möglichkeit physische Maschinen und für virtuelle Anti-Affinitätsregeln, die sie auf verschiedenen Hosts halten. Seine Annahmen zur Kapazität sind eine Datenreduktion von „in der Regel 2:1 oder mehr“ und eine typische tägliche Änderungsrate von 2 bis 5 Prozent, bei Datenbankservern im ungünstigsten Fall bis zu 30 bis 50 Prozent und etwa 10 Prozent als Planungswert, wo Datenbanken einen großen Anteil haben. Er sieht Platz für einmalige Vollsicherungen vor und für die Transformation von Backup-Ketten mindestens eine Vollsicherung mal 1,25; diese Reserve steht neben dem Hinweis, dass solche Kettentypen nicht empfohlen werden, wohl aber Forward Incremental mit synthetischen Vollsicherungen. Veeams Build-Leitfaden rät, Volumes auf 500 TB zu begrenzen und sie nicht „über 80 Prozent“ zu füllen.

XFS mit Block Cloning hält synthetische Vollsicherungen und GFS-Punkte klein, und eine synthetische Vollsicherung entsteht im Repository „ohne Auswirkung auf den Quellspeicher oder die Produktionsnetze“, während eine aktive Vollsicherung erneut die Produktion liest. Den Aufbau eines solchen Repositorys mit Immutability behandelt unser Leitfaden zum Veeam Hardened Repository.

Ein Scale-out Backup Repository ist in Veeams Worten „ein Repository-System mit Unterstützung horizontaler Skalierung für die mehrstufige Speicherung von Daten“. Ein oder mehrere Repositories bilden seinen Performance Tier, und Objektspeicher erweitert es als Capacity Tier und Archive Tier. Der Leitfaden nennt die Platzierungsrichtlinie Data Locality „die empfohlene Einstellung für die meisten Bereitstellungen“ und 10-Gb-Netze das empfohlene Minimum.

Der Capacity Tier kopiert Backups, sobald sie erstellt sind, oder verschiebt inaktive Ketten, sobald sie aus dem operativen Wiederherstellungsfenster fallen; die Offload-Sitzung, die sie verschiebt, läuft alle 4 Stunden. Wiederherstellungen aus dem Archive Tier dauern länger als aus dem Capacity Tier. Wie lange jeder Tier Daten behält, behandelt unser Leitfaden zu Backup-Aufbewahrung und GFS, und ob die Kopie auf Objektspeicher als externe Kopie zählt, unser Artikel zur 3-2-1-1-0-Backup-Regel.

Job-Layout nach Systemstufe und das Backup-Fenster

Der Leitfaden nennt als empfohlene maximale Jobgröße 16 TB Quelldaten bei 1-MB-Blöcken auf ein lokales Ziel und 64 TB bei 4-MB-Blöcken; eine geänderte Blockgröße wirkt erst nach einer aktiven Vollsicherung. Veeams Recommended Maximums für Version 13, die Veeam „keine harten Grenzen“ nennt, liegen bei 5.000 VMs je Job und 20.000 VMs je Backup-Server.

1. Teilen Sie die VMs nach RPO in Systemstufen ein und halten Sie Datenbankserver wegen ihrer Änderungsrate getrennt.
2. Teilen Sie die Jobs innerhalb jeder Stufe so auf, dass keiner die empfohlene Quellgröße für seine Blockgröße überschreitet.
3. Fassen Sie VMs zusammen, die Aufbewahrung und Repository teilen, sodass jeder Job einen Zeitplan und ein Ziel hat.
4. Starten Sie Jobs, wie der Leitfaden rät, im Abstand von einer Minute, statt sie zu verketten, und lassen Sie den Lastausgleich die Tasks über Proxys und Repositories verteilen.
5. Sichern Sie vCenter zusätzlich mit seinem dateibasierten Backup, wie es unser Leitfaden zu Backup und Wiederherstellung von vCenter beschreibt.

Rechenbeispiel: Veeam Sizing für etwa 800 VMs

Dieses Beispiel stammt von uns, mit den Formeln des Leitfadens. Es nimmt 800 VMs mit 120 TB Quelldaten an, virtuelle Hot-Add-Proxys, die auf Blockspeicher schreiben, eine tägliche Änderungsrate von 3 Prozent, nächtliche Inkremente in einem Fenster von 8 Stunden, wöchentliche synthetische Vollsicherungen auf XFS, 14 tägliche Wiederherstellungspunkte und ein Fenster von 24 Stunden für die erste Vollsicherung und jede aktive Vollsicherung.

Für die Vollsicherung entsprechen 120 TB 125.829.120 MB; über 86.400 Sekunden sind das etwa 1.456 MB/s, und bei 180 MB/s je Kern brauchen die Proxys 9 Kerne, mit Inline-Entropieanalyse bei etwa 100 MB/s 15 Kerne. Das nächtliche Inkrement von 3 Prozent umfasst etwa 3,6 TB oder 131 MB/s über 28.800 Sekunden, wofür bei 80 MB/s 2 Kerne nötig sind. Sind 20 TB der 120 TB Datenbankserver, die sich je Nacht zu 30 Prozent ändern, wächst das Inkrement auf etwa 9 TB und braucht 5 Kerne.

Vier virtuelle Proxys mit 4 vCPU und 8 GB RAM, die Konfiguration aus Veeams Testtabelle, ergeben 16 Kerne und 32 Tasks. Fällt ein Proxy aus, schaffen 12 Kerne die Vollsicherung noch in etwa 16 Stunden, mit Inline-Prüfung in etwa 29 Stunden. Sechzehn Proxy-Kerne verlangen 6 Repository-Kerne und 24 GB RAM. Der Backup-Server für 800 Workloads fällt in die Zeile des Leitfadens für 500 bis 1.000: 24 vCPU und 32 GB RAM.

Bei einer Reduktion von 2:1 belegt die Vollsicherung etwa 60 TB auf der Platte und jedes nächtliche Inkrement etwa 1,8 TB. Mit wöchentlichen synthetischen Vollsicherungen auf XFS halten 14 tägliche Wiederherstellungspunkte Inkremente von bis zu etwa 20 Tagen, die Kette umfasst also rund 60 + 20 × 1,8 = 96 TB. Eine aktive Vollsicherung nutzt Fast Clone nicht; Platz für eine weitere Vollsicherung, wie ihn der Leitfaden für einmalige Vollsicherungen verlangt, bringt den Bedarf deshalb auf etwa 156 TB oder etwa 195 TB Volume bei höchstens 80 Prozent Füllung, vor GFS-Punkten und einem etwaigen Immutability-Zeitraum. Mit dem oben genannten Datenbankanteil wächst die Kette auf etwa 150 TB. Die Reserve des Leitfadens von 1,25 für die Kettentransformation (hier 75 TB) bleibt außen vor, weil das Beispiel den empfohlenen Modus nutzt. Bei 120 TB und höchstens 16 TB je Job sind mindestens 8 Jobs nötig. Der Leitfaden rechnet auf der Strecke vom Proxy zum Repository mit etwa der Hälfte der Quelldaten, eine über das 24-Stunden-Fenster verteilte Vollsicherung sendet also etwa 730 MB/s oder 5,8 Gbit/s, und 10-GbE-Verbindungen tragen das. Bei 2.000 VMs mit gleichem Profil wachsen Kerne und Kapazität proportional, und der Backup-Server rückt in die nächste Zeile.

Das technische Assessment in unserer Leistung Cyber-Resilienz prüft Backups zusammen mit Infrastruktur und Zugriffen und endet mit einer Risikokarte und einem priorisierten Maßnahmenplan. Schicken Sie uns die Zahl Ihrer VMs, die Quelldaten und das Backup-Fenster über das Formular unten.

Backup-Infrastruktur außerhalb des Verzeichnisdienstes der Produktion

Veeams Security Best Practice Guide hält fest: „Ein Datensicherungssystem sollte sich in keiner Weise auf die Umgebung stützen, die es schützen soll.“ Für die sicherste Bereitstellung empfiehlt er, die Veeam-Komponenten in eine Arbeitsgruppe für das Management aufzunehmen oder in eine Verwaltungsdomäne in einer separaten Gesamtstruktur des Verzeichnisdienstes, mit Zwei-Faktor-Authentifizierung auf den Administratorkonten. Ein Backup-Server, der Mitglied der Produktionsdomäne ist, hängt für die Anmeldung an der Konsole und für DNS von den Domänencontrollern der Produktion ab, sodass eine Wiederherstellung stocken kann, wenn diese ausgefallen sind.

Netzwerksegmentierung, Multi-Faktor-Authentifizierung und Privileged Access Management gehören zu unserer Leistung Cyber-Resilienz. Nennen Sie uns, welchem Verzeichnisdienst Ihre Backup-Server und Proxys angehören und wer über ihre Administratorkonten verfügt.

Backup-Fenster und Zustand der Jobs überwachen

Beobachten Sie die Laufzeit jedes Jobs im Verhältnis zu seinem Fenster, denn das Entfernen von Snapshots „verringert die gesamten IOPS, die die VM liefern kann, erheblich“ (KB1681), und Anwender bemerken das während der Geschäftszeiten. Die Job-Statistiken in Version 13 zeigen Engpässe im Datenübertragungsprozess und damit, ob Sie Proxy-Kerne, Repository-Platten oder Bandbreite ergänzen sollten. Leiten Sie Malware-Erkennungsereignisse der Inline-Prüfung an das Sicherheitsteam weiter und planen Sie Testwiederherstellungen für jede Systemstufe, deren Dauer Sie mit dem RTO vergleichen.

Was wir tun

Im Rahmen unseres Cyber-Resilienz-Service liefert das Team unseres Engineering-Partners Vixen.UNO Backup auf Veeam-Basis mit regelmäßigen Testwiederherstellungen zur Prüfung der Backup-Integrität, unter einem Vertrag mit Eurokommerz. Das technische Assessment von Security und Backup umfasst auch Umgebungen, die wir nicht gebaut haben, und sein Preis steht vor Beginn fest. Für einen zweiten Standort repliziert unser Service Cloud Disaster Recovery virtuelle Maschinen ab einem 15-Minuten-Intervall über Veeam Cloud Connect in Baltnetas Tier-3-Rechenzentren in Litauen.

FAQ