DR-Standort dimensionieren: wie viel Rechenleistung, Speicher, Netzwerk und Lizenzen ein Ausweichstandort braucht

Wie viel Kapazität ein DR-Standort braucht

Ein DR-Standort, ob eigenes Ausweichrechenzentrum oder DRaaS, braucht genug Rechenleistung für die Systeme, die während des Ausfalls laufen müssen, nicht für den gesamten Bestand, und genug Speicher für die Replikate, für die Wiederherstellungspunkte, die jeder Replikationsjob vorhält, und für die Daten, die geschrieben werden, solange Systeme dort laufen. Entwicklungs-, Test- und Archivsysteme warten meist, bis der Primärstandort wieder verfügbar ist; die Rechenleistung am Ausweichstandort kann daher die Hälfte der Produktion oder weniger betragen. Der Speicher schrumpft weniger, weil jede replizierte Platte dort vollständig liegt und wächst, während Sie am Ausweichstandort arbeiten.

Netzwerk, Lizenzen, dauerhaft laufende Dienste und Platz für isolierte Tests vervollständigen die Liste. NIST SP 800-34 Rev. 1 hält fest, dass „der Standort in der Lage sein muss, den Systembetrieb so zu unterstützen, wie er im Notfallplan festgelegt ist“; über die Größe entscheiden also der Plan und die Business Impact Analysis dahinter, nicht der Produktionscluster.

Was jeder Standorttyp bereithält, behandelt unser Vergleich von Hot Site, Warm Site und Cold Site. Dieser Leitfaden geht von einem Standort aus, an dem VMs als Replikate warten, in Ihrem eigenen zweiten Rechenzentrum oder bei einem DRaaS-Anbieter.

Eingangsdaten für die Kapazitätsplanung im Disaster Recovery

Sammeln Sie diese Eingangsdaten, bevor jemand eine Hostzahl ansetzt, und halten Sie den Zeitraum fest, in dem sie gemessen wurden.

Unsere Checkliste. Eingangsdaten aus der Business Impact Analysis nach NIST SP 800-34 Rev. 1, Abschnitt 3.2; Verhalten von Snapshots und Delta-Dateien nach Veeams Cloud Connect Guide (Build 13.1.1.18) und Broadcoms KB 318825.

Die Stufenliste ist die Eingangsgröße, die am meisten Kapazität einspart. Unser Leitfaden zur Business Impact Analysis für die IT zeigt, wie Prozessverantwortliche die maximal tolerierbare Ausfallzeit festlegen und wie daraus ein RTO je System wird. Ein System mit einem RTO von 3 Tagen, das sich aus einer Backup-Kopie wiederherstellen lässt, braucht am ersten Tag keine CPU am Ausweichstandort.

Rechenleistung: Hosts für die Stufen, die im Ausfall laufen

Dimensionieren Sie die CPU nach dem gemessenen Bedarf der VMs, die starten, statt nach ihren konfigurierten vCPU. vCenter speichert Leistungsdaten je VM, standardmäßig in 5-Minuten-Intervallen für den letzten Tag und in 2-Stunden-Intervallen für den letzten Monat; nehmen Sie den dauerhaften Bedarf also aus einem Monat, der ein Monatsende enthält, und kurze Spitzen aus feiner aufgelösten Daten. CPU lässt sich am Ausweichstandort stärker überbuchen als in der Produktion, weil einige Tage langsamerer Batch-Jobs während einer Katastrophe akzeptabel sind. Broadcom bezeichnet Arbeitsspeicher als überbucht, wenn „der kombinierte aktiv genutzte Arbeitsspeicher aller virtuellen Maschinen“ den Arbeitsspeicher des Hosts übersteigt; ESX holt dann Arbeitsspeicher über Ballooning, Memory Sharing, Komprimierung und Swapping zurück, und eine VM, deren Arbeitsspeicher komprimiert oder auf die Platte ausgelagert wird, läuft langsamer. Planen Sie für die oberste Stufe den konfigurierten RAM jeder startenden VM ein, ohne Überbuchung.

Der Wiederherstellungscluster braucht außerdem eine Reserve für einen Hostausfall. In Broadcoms Worten „verwendet vSphere HA Admission Control, um sicherzustellen, dass ausreichend Ressourcen für die Wiederherstellung virtueller Maschinen reserviert sind“, wenn ein Host ausfällt. Ohne diese Reserve stoppt ein einzelner Hostausfall während einer Katastrophe einen Teil der obersten Stufe ein zweites Mal. Planen Sie im Cluster, der die oberste Stufe betreibt, mindestens einen Host als Reserve ein.

Einige Dienste laufen am Ausweichstandort ständig, unabhängig von jedem Failover: Domänencontroller und DNS-Server des Verzeichnisdienstes, ein vCenter, der Backup- oder Replikationsserver dieses Standorts und ein Jump-Host für Administratoren. Sie belegen jeden Tag Kapazität und gehören als fester Posten in die Planung.

Speicher: Replikate, Wiederherstellungspunkte und Schreiblast im Failover

Ein Replikat hält jede Platte der VM. Mit Thin-provisionierten Replikatplatten liegt die Grundkapazität nahe an der belegten Kapazität der Quelle, mit Thick-Platten entspricht sie der provisionierten Größe. Hinzu kommen die Wiederherstellungspunkte. In Veeam Cloud Connect gilt für das Failover, dass es „das VM-Replikat auf den benötigten Snapshot in der Replikatkette zurücksetzt“; jeder Wiederherstellungspunkt ist also ein vSphere-Snapshot, dessen Delta-Datei die in seinem Intervall geänderten Blöcke hält. Der Platz für die Wiederherstellungspunkte eines Replikats entspricht daher ungefähr der Datenmenge, die sich in der von ihnen abgedeckten Zeitspanne ändert. Unser Vergleich von Veeam-Replikation und Backup-Copy-Jobs erklärt, wie weit diese Kette zurückreicht.

Ein Speicherposten, der leicht übersehen wird, entsteht durch das Failover selbst. Veeams Leitfaden zum Teil-Failover hält fest: „Alle Änderungen, die am VM-Replikat vorgenommen werden, während es im Zustand ‚Failover‘ läuft, werden in die Delta-Datei geschrieben“, und zwar in die des Wiederherstellungspunkts, auf den Sie zurückgesetzt haben. Jeder Schreibvorgang der Produktion während des Ausfalls landet in Delta-Dateien am Ausweichstandort, bis das Failover dauerhaft übernommen oder ein Failback ausgeführt wird. Broadcoms KB 318825 zu Snapshots hält fest: „Die Snapshot-Datei wächst weiter, je länger sie aufbewahrt wird“, und warnt, dass dem Speicherort dadurch der Platz ausgehen kann. Dimensionieren Sie dieses Wachstum als tägliche Änderungsrate der gestarteten Stufen multipliziert mit den Tagen, die Sie dort laufen wollen, als Obergrenze, da mehrfach überschriebene Blöcke nur einmal gehalten werden, und halten Sie auf den Datastores freien Platz darüber hinaus vor.

Wird Stufe 3 aus Backup-Kopien wiederhergestellt, die am Ausweichstandort liegen, brauchen das Repository und der Datastore, in den diese VMs wiederhergestellt werden, eigene Kapazität.

Netzwerkkapazität für Replikation und Benutzerzugriff

Die Replikationsleitung wird nach der Datenmenge dimensioniert, die der Replikationslauf mit dem größten Volumen nach der Komprimierung überträgt, geteilt durch das Intervall; unser Leitfaden zur Bandbreite der Replikation für Disaster Recovery behandelt diese Rechnung. Der zweite Netzwerkposten ist der Zugangsweg nach einem Failover. Benutzer, Partner und Schnittstellen erreichen den Ausweichstandort über das Internet oder ein VPN, das nicht am Primärstandort enden darf, und sie brauchen öffentliche Adressen, Firewall-Regeln und genug Internetkapazität für die Mitarbeiter, die mit den obersten Stufen arbeiten.

Zählen Sie auch die Netze, mit denen sich die Replikate verbinden. Ein Hardware-Plan von Veeam Cloud Connect umfasst eine „festgelegte Anzahl von Netzen, mit denen sich VM-Replikate des Tenants verbinden können“, und bei einem vollständigen Standort-Failover startet Veeam eine Network Extension Appliance, die als Gateway zwischen dem Replikatnetz und externen Netzen dient.

Lizenzen für Hosts und VMs am Ausweichstandort

Eigene Hosts am Ausweichstandort laufen unter denselben Lizenzbedingungen wie Produktionshosts, sofern ein Herstellerdokument nichts anderes festlegt. Broadcoms VMware Cloud Foundation Specific Program Documentation vom Juni 2026 hält fest: „Jeder Kern auf dem Server, auf dem die Software installiert ist, muss lizenziert sein“, mit mindestens 16 Kernlizenzen je Prozessor. Ein Wiederherstellungscluster mit weniger oder kleineren Hosts braucht daher weniger Kernlizenzen, aber nie weniger als 16 je Prozessor. Dasselbe Dokument erlaubt dem Kunden, Wiederherstellungs- und Testaktivitäten „insgesamt für bis zu 15 Tage pro Jahr“ im eingebauten Evaluierungsmodus der Software durchzuführen, und ergänzt, dass dies keine Rechte an mehr Kernen gewährt als den bezahlten. Wie das für Ihre Standby-Hosts gilt, ist eine Frage, die Sie Broadcom oder Ihrem Händler schriftlich stellen sollten.

Orchestrieren Sie das Failover mit Broadcoms Protection and Recovery (vor 9.1 VMware Live Site Recovery), legt dessen Dokumentation zu 9.1 die Lizenz nach der Zahl der geschützten VMs fest und hält fest: „Auf dem geschützten Standort und dem Wiederherstellungsstandort wird dieselbe Lizenz installiert.“ Veeams Lizenzrichtlinie (Version 19, Juni 2026) zählt einen Workload als geschützt, wenn in den letzten 31 Tagen mindestens ein Wiederherstellungspunkt für ihn erstellt wurde, und jede geschützte VM verbraucht eine Instanz. Für Socket-Lizenzen, die Veeam nicht mehr als neue unbefristete Lizenzen verkauft, heißt es dort: „Zielhosts (für Replikations- und Migrationsjobs) müssen nicht lizenziert werden.“ Gastbetriebssysteme und Anwendungen folgen für die Standby- und Failover-Nutzung den Bedingungen ihrer jeweiligen Hersteller.

Kapazität für isolierte Failover-Tests

Failover-Tests starten Replikate auf den Wiederherstellungshosts, in einem von der Produktion isolierten Netz. Broadcoms Dokumentation zu Protection and Recovery 9.1 beschreibt die Wiederherstellung in „ein abgeschottetes Testnetz“ und schreibt, dass Tests „keine dauerhaften Auswirkungen auf den geschützten Standort oder den Wiederherstellungsstandort haben“. Ein Test der gesamten obersten Stufe braucht dieselbe CPU und denselben RAM wie ein Failover dieser Stufe. Ist der Standort nur für das Failover selbst dimensioniert, testen Sie eine Stufe nach der anderen. Testläufe schreiben außerdem, solange sie dauern, in den Speicher der Replikate; planen Sie dafür einige Stunden der Änderungsrate der Stufe ein.

Unser Service Cloud Disaster Recovery führt planmäßige Failover-Tests in einer isolierten Umgebung durch, ohne Einfluss auf die Produktion und mit einem Bericht nach jedem Test. Nennen Sie uns die Stufe, die Sie zuerst testen würden, und wie viel Kapazität Ihr Ausweichstandort heute hat.

Rechenbeispiel: ein DR-Standort für 600 VMs in drei Stufen

Nehmen wir ein erfundenes Unternehmen mit 600 VMs auf 16 Produktionshosts mit je 64 Kernen und 1 TB RAM. Die BIA ordnet 90 VMs der Stufe 1 zu, repliziert alle 15 Minuten, und 210 VMs der Stufe 2, stündlich repliziert. Die 300 VMs der Stufe 3 haben nur Backup-Kopien und werden wiederhergestellt, wenn der Primärstandort wieder verfügbar ist.

Erfundenes Beispiel; die Zahlen, die Änderungsraten und die Rechnung im Text stammen von uns und sind keine Zielwerte unseres Service.

Die Zahl der Hosts ergibt sich aus dem RAM, denn 7,1 TB auf Hosts mit 1 TB, zu 90 Prozent belegt, brauchen 8 Hosts, und ein weiterer als HA-Reserve ergibt 9 Hosts mit 576 Kernen. Fällt ein Host aus, laufen 1.380 vCPU auf 512 Kernen, 2,7 vCPU je Kern gegenüber 2,3 in der Produktion, womit die Batch-Jobs der Stufe 2 einige Tage zurechtkommen.

Der Speicherplan hängt davon ab, wie lange das Unternehmen am Ausweichstandort läuft. BIA und Vertrag gehen von bis zu 10 Tagen am Ausweichstandort aus; 2,65 TB Schreibvorgänge pro Tag ergeben also rund 27 TB Delta-Dateien. Mit 110 TB Replikaten, rund 2 TB Deltas der Wiederherstellungspunkte und 1 TB für Testläufe hält der Standort rund 140 TB Daten, und mit 20 Prozent freiem Platz je Datastore braucht er rund 175 TB nutzbare Kapazität. Das Repository für die Backup-Kopien der Stufe 3 ist in dieser Zahl nicht enthalten. Der Ausweichstandort hat damit 9 Hosts gegenüber 16, während seine 140 TB Daten 180 TB belegtem Speicher in der Produktion gegenüberstehen.

Bei einem DRaaS-Anbieter mit Veeam Cloud Connect wird aus demselben Ergebnis ein Hardware-Plan mit einer CPU-Grenze und einer RAM-Grenze für alle replizierten VMs des Tenants, einem Speicherkontingent auf einem Datastore und einer Zahl von Netzen. Ob diese Kapazität allein für Sie vorgehalten wird, ist eine Vertragsfrage, die unsere DRaaS-Checkliste vor der Unterschrift behandelt.

Bei unserem Angebot Backup und DRaaS in der EU sind Kapazitätsverfügbarkeit, Support sowie Ziel-RPO und -RTO im SLA fixiert, und das technische Assessment umfasst die Dimensionierung des Ausweichstandorts. Schicken Sie uns Ihre VM-Zahlen je Stufe, mit konfiguriertem RAM, belegtem Speicher und Replikationszeitplänen.

Was wir tun

Unser Service Cloud Disaster Recovery betreibt Ihren Ausweichstandort in Baltnetas Tier-3-Rechenzentren in Litauen (ISO 27001, PCI DSS), geographisch von Ihrer Primärinfrastruktur getrennt, mit EU-Datenresidenz. Im DR-Strategie-Design definieren wir gemeinsam mit Ihnen die kritischen Systeme, Ziel-RPO und -RTO je Systemstufe und die Katastrophenszenarien, gegen die Sie sich absichern, und das kostenpflichtige technische Assessment umfasst die Dimensionierung des Standorts; der Preis des technischen Assessments steht vor Beginn fest. Unser Engineering-Partner Vixen.UNO richtet die VM-Replikation ab einem 15-Minuten-Intervall über Veeam Cloud Connect ein und führt planmäßige Failover-Tests in einer isolierten Umgebung durch, mit einem Bericht nach jedem Test. Die Standardziele des Services sind ein RPO ab 15 Minuten und ein RTO von 1 bis 2 Stunden für kritische Systeme; Ihre Ziele je Stufe werden im Assessment definiert und zusammen mit dem Support im SLA fixiert.

FAQ