Bandbreite der Replikation für Disaster Recovery: Mbit/s aus Änderungsrate und RPO berechnen

Replikationsbandbreite für Disaster Recovery berechnen

Die Bandbreite, die eine Replikationsverbindung braucht, ist die Datenmenge, die ein Replikationslauf nach der Komprimierung überträgt, geteilt durch die Länge des Intervalls. Nehmen Sie diese Menge aus dem stärksten Lauf, nicht aus dem Tagesdurchschnitt, und planen Sie Reserve für anderen Verkehr ein. Broadcoms Dokumentation zu vSphere Replication für VCF 9.1 (aktualisiert am 9. Oktober 2026) geht davon aus, dass „nur etwa 70 Prozent einer Verbindung für den Replikationsverkehr verfügbar sind“.

Als Formel mit ausgeschriebenen Einheiten lautet das Mbit/s = GB × 8000 ÷ s ÷ 0.7, wobei GB die im stärksten Lauf übertragene Datenmenge in dezimalen GB ist, s das Intervall in Sekunden und 0,7 der nutzbare Anteil der Verbindung nach Broadcom. Ein Lauf, der 10 GB innerhalb eines 15-Minuten-Intervalls (900 Sekunden) überträgt, braucht also 10 × 8.000 ÷ 900 ÷ 0,7, rund 127 Mbit/s.

Broadcoms Vorgehen „Calculate Bandwidth For vSphere Replication“ leitet die Änderungsrate innerhalb des RPO ab und verlangt dann, zu „berechnen, wie viel Verkehr diese Datenänderungsrate in jedem RPO-Zeitraum erzeugt“, und „den Verkehr an der Geschwindigkeit Ihrer Verbindung zu messen“. Nach unserer Lesart passt die Methode auch zur Veeam-Replikation, denn Veeams Best Practice Guide nennt die Änderungsrate und das RPO-Ziel unter den Faktoren, von denen die Replikationsbandbreite abhängt. Wie Sie den RPO für jede Systemstufe festlegen, beschreibt unser Leitfaden zu RPO und RTO und ihren Zielwerten.

Eingaben für die Berechnung und wie Sie sie messen

Broadcom TechDocs, VCF 9.1, Bandwidth Requirements und Calculate Bandwidth For vSphere Replication (aktualisiert am 9. Oktober 2026); Broadcom KB 317503; Veeam Backup & Replication Best Practice Guide, Seiten Replication jobs und WAN Acceleration.

Für Veeam hält der Best Practice Guide fest: „Die Schätzung der Replikationsbandbreite war schon immer eine Herausforderung, weil sie von mehreren Faktoren abhängt“. Als Test schlägt er einen Backup-Job vor, „der dieselben Einstellungen wie der Replikationsjob hat“, weil „der Backup-Job dieselbe Datenmenge überträgt wie der Replikationsjob“, und nennt Veeam ONE als Werkzeug, das „bei der Schätzung von Änderungsraten helfen kann“. Lassen Sie diesen Testjob im geplanten Intervall laufen, denn ein nächtliches Inkrement zeigt die in 24 Stunden geänderten Blöcke, nicht die eines 15-Minuten-Laufs.

Es zählen nur die geschützten VMs. Broadcoms KB 317503 nennt das Beispiel von 2 TB an VMs, von denen die Hälfte geschützt ist, also höchstens 1 TB zu replizieren. Der vSphere Replication Calculator von Broadcom unter vcf.broadcom.com, geschrieben für vSphere Replication 8.5, nimmt Anzahl der VMs, Plattengröße und Auslastung, Komprimierung, die tägliche Änderungsrate, den größten Änderungsschub und den RPO auf und berechnet daraus Bandbreite, RPO oder Anzahl der VMs.

Für die Spitzenänderungsrate auslegen, nicht für den Tagesdurchschnitt

Änderungsraten folgen dem Arbeitstag und dem Zeitplan der Batch-Jobs. Broadcoms Seite zur Bandbreite merkt an, dass die Änderungsrate „im Laufe des Tages schwanken kann, was den Verkehr verändert, den vSphere Replication zu verschiedenen Zeiten erzeugt“. Sein Vorgehen geht von der durchschnittlichen Änderungsrate innerhalb des RPO aus; für eine Verbindung, die den RPO auch zur stärksten Tageszeit halten muss, legen wir vom stärksten Lauf aus. Datenbankwartung, Monatsabschluss und Software-Rollouts können in einer Stunde weit mehr Blöcke schreiben als eine durchschnittliche Stunde.

Eine nach dem Tagesdurchschnitt bemessene Verbindung gerät in der Spitze in Rückstand: Der Lauf dauert länger als sein Intervall, der nächste Lauf beginnt verspätet, und das Replikat altert, bis die Last sinkt. Sammeln Sie Statistiken je Lauf über einen vollständigen Geschäftszyklus, Monatsabschluss eingeschlossen.

Die Tagessumme kann auch in die andere Richtung täuschen. Broadcoms KB 317503 erklärt, dass vSphere Replication einen geänderten Block einmal sendet, in dem Zustand, den er beim Erstellen des Übertragungspakets hat, und „nur registriert, dass sich der Block innerhalb des RPO-Zeitraums geändert hat, nicht wie oft er sich geändert hat“. Ein Speicherzähler, der jeden Schreibvorgang summiert, überzeichnet also, was die Replikation sendet, und der KB-Artikel nennt die durchschnittliche tägliche Änderungsrate „eher eine Obergrenze als eine realistische Schätzung“.

Replikationsintervall von 15 Minuten oder einer Stunde

Ein kürzeres Intervall senkt die benötigte Bandbreite nicht. Jeder Lauf sendet jeden Block, der sich seit dem vorigen Lauf geändert hat; ein Block, der den ganzen Tag neu geschrieben wird, wird also einmal je Lauf übertragen. Broadcoms KB 317503 hält fest: „Wenn Sie einen RPO von 1 Stunde festlegen, erfolgt die Replikation 24-mal pro Tag“; ein solcher Block kann also bis zu 24-mal am Tag übertragen werden und nach derselben Rechnung bei 15 Minuten bis zu 96-mal. Ein stündlicher Lauf fängt außerdem kurze Schübe auf, während ein 15-Minuten-Lauf seinen Schub innerhalb von 900 Sekunden übertragen muss.

Unsere Rechnung: GB × 8.000 ÷ Intervall in Sekunden ÷ 0,7, Daten je Lauf nach der Komprimierung in dezimalen GB (10⁹ Byte), Verbindung in Mbit/s (10⁶ Bit pro Sekunde); 0,7 ist der nutzbare Anteil, von dem Broadcoms Dokumentation zu vSphere Replication ausgeht.

Broadcoms Vorgehen ergibt für 100 GB auf einer Verbindung mit 100 Mbit/s rund 3 Stunden, im Einklang mit dieser Regel: Die Verbindung überträgt bei voller Leitungsrate 45 GB pro Stunde und bei 70 Prozent rund 31,5 GB.

Das Intervall legt auch fest, wie alt das Replikat werden kann. Nach unserer Rechnung bildet der Wiederherstellungspunkt eines Laufs den Zeitpunkt ab, zu dem der Lauf begann, und ist nutzbar, sobald die Übertragung abgeschlossen ist; kurz bevor ein Lauf abschließt, ist der neueste nutzbare Punkt also ein Intervall plus diese Übertragungszeit alt. Füllt der stärkste Lauf das gesamte 15-Minuten-Intervall, kann das Replikat in diesem Moment fast 30 Minuten alt sein. Soll der stärkste Lauf in der Hälfte des Intervalls fertig werden, verdoppelt sich die Bandbreite aus der Tabelle, und die RPO-Stufe entscheidet, ob das nötig ist.

Rechenbeispiel: 800 VMs an einen Ausweichstandort replizieren

Dieses Beispiel stammt von uns, und jede Eingabe ist eine Annahme. Ein Unternehmen mit 1.500 VMs repliziert die 800 VMs seiner kritischen und wichtigen Stufen mit 60 TB belegten Daten. Wir nehmen an, dass sich 3 Prozent dieser Daten pro Tag ändern (der Standardwert in Broadcoms Rechner, keine Messung), gezählt als das, was die Läufe vor der Komprimierung übertragen. Wir nehmen an, dass der stärkste 15-Minuten-Lauf das Dreifache des durchschnittlichen Laufs trägt und der stärkste stündliche Lauf das Doppelte der durchschnittlichen Stunde. Wir nehmen an, dass die Komprimierung die Daten halbiert; Ihre Jobstatistik zeigt Ihr eigenes Verhältnis.

Rechenbeispiel mit angenommenen Eingaben; Methode aus Broadcoms Calculate Bandwidth For vSphere Replication (TechDocs, VCF 9.1, aktualisiert am 9. Oktober 2026); Rechnung von uns: GB × 8.000 ÷ Sekunden, dann ÷ 0,7.

Beim 15-Minuten-Intervall entsprechen 28,1 GB rund 225.000 Mbit. Verteilt auf 900 Sekunden sind das 250 Mbit/s, und geteilt durch 0,7 braucht die Verbindung rund 357 Mbit/s. Eine Auslegung nach dem Tagesdurchschnitt ergäbe 9,4 GB je Lauf und rund 119 Mbit/s, ein Drittel davon. Die Spalte für das Stundenintervall übernimmt die Tagessumme des 15-Minuten-Intervalls und überzeichnet sie damit leicht, da innerhalb der Stunde neu geschriebene Blöcke nur einmal gesendet werden.

Unser Service Cloud Disaster Recovery repliziert virtuelle Maschinen mit Veeam ab einem 15-Minuten-Intervall an einen Ausweichstandort in Baltnetas Tier-3-Rechenzentren in Litauen. Schicken Sie uns die Zahl Ihrer VMs, die belegte Kapazität und die Änderungsrate je Lauf über das Formular unten.

Einheiten in der Rechnung: Bit, Byte, GB und GiB

Verbindungen werden in Bit pro Sekunde mit dezimalen Präfixen angegeben, 1 Mbit/s sind also 10⁶ Bit pro Sekunde. Ein Byte hat 8 Bit, ein dezimales GB (10⁹ Byte) sind also 8.000 Mbit. Eine Verbindung mit 1 Gbit/s überträgt deshalb höchstens 125 MB pro Sekunde oder 450 GB pro Stunde bei voller Leitungsrate.

Manche Berichte zählen in binären Einheiten. Die Seite des NIST zu binären Präfixen definiert „1 GiB = 2³⁰ B = 1 073 741 824 B“ gegenüber „1 GB = 10⁹ B = 1 000 000 000 B“; ein Gibibyte ist also rund 7,4 Prozent größer als ein dezimales GB. Im Rechenbeispiel hebt 28,1 GiB je Lauf statt 28,1 GB die Verbindung von rund 357 auf rund 383 Mbit/s; prüfen Sie also, welche Einheit Ihre Jobstatistik verwendet.

Seeding der ersten Kopie, WAN-Beschleunigung und Drosselung

Der erste Lauf kopiert die gesamte VM und ist die größte Übertragung des Projekts. Auf der Verbindung des Beispiels mit rund 357 Mbit/s, von denen 250 Mbit/s für die Replikation bleiben, dauern 60 TB belegte Daten nach unserer Rechnung vor der Komprimierung rund 22 Tage (4,8 × 10¹⁴ Bit ÷ 2,5 × 10⁸ Bit pro Sekunde, rund 1,9 Millionen Sekunden). Halbiert die Komprimierung die Menge wie oben angenommen, bleiben rund 11 Tage, und der nächste Lauf überträgt dann die Blöcke, die sich während der ersten Kopie geändert haben.

Veeams Best Practice Guide führt Replica Seeding, Replica Mapping, WAN-Beschleunigung und Replica from Backup für die Replikation an einen externen Standort als Mechanismen auf, die „die Menge des Replikationsverkehrs reduzieren“. Wie Seeding und Mapping den ersten Lauf mit Daten starten, die bereits am DR-Standort liegen, beschreibt unser Vergleich Veeam-Replikation vs. Backup Copy. Der Leitfaden merkt an, dass „WAN-Beschleuniger Replikationsjobs helfen können, in die erlaubten Zeitfenster zu passen, wenn die Bandbreite nicht ausreicht“. Seine Design-Seite empfiehlt den Low-Bandwidth-Modus „für Verbindungen mit weniger als 100 Mbit/s Durchsatz“ und oberhalb von 100 Mbit/s den Direct-Modus mit hoher Komprimierung. Der High-Bandwidth-Modus bleibt für Verbindungen mit hoher Bandbreite und einer Latenz über 100 ms sowie für Workloads mit einer täglichen Änderungsrate über 10 Prozent. Der Leitfaden nennt keine feste Einsparung; messen Sie sie also mit einem Testjob.

Für die Replikation an einen entfernten DR-Standort ergänzt der Leitfaden, dass „Sie den Netzwerkverkehr auch über Regeln zur Drosselung des Datenverkehrs steuern können“. Die gedrosselte Rate muss über dem Durchsatz des stärksten Laufs bleiben, sonst gerät das Replikat in Rückstand.

Zum technischen Assessment in unserem Service Cloud Disaster Recovery gehört ein Review der Infrastruktur, der DR-Strategie und des Standort-Sizings. Nennen Sie uns, wie viele Daten die erste Kopie übertragen würde und welche Leitung Ihre Standorte heute verbindet.

Verschlüsselung, Latenz und anderer Verkehr auf der Verbindung

Unser Ausweichstandort empfängt die Replikation über Veeam Cloud Connect über einen verschlüsselten TLS/SSL-Kanal, und Veeams Best Practice Guide empfiehlt Verschlüsselung bei der Übertragung, sobald Verkehr zwischen Veeam-Komponenten nicht vertrauenswürdige Netze durchquert. Keines der Herstellerdokumente, die wir gelesen haben, nennt eine Zahl dafür, wie viel Volumen Verschlüsselung oder Protokoll-Header hinzufügen; lassen Sie den Testjob also mit aktivierter Verschlüsselung laufen und behalten Sie die Annahme von 70 Prozent bei, bis Ihre eigenen Werte sie ersetzen.

Broadcoms 70 Prozent sind der Anteil der Verbindung, den die Replikation nach Broadcoms Erwartung erreicht. Teilen sich Backup-Copy-Jobs, Nutzerverkehr oder Verwaltungsverkehr die Verbindung zu denselben Stunden, ziehen Sie deren Durchsatz ab, bevor Sie den Anteil anwenden. Broadcoms KB 317503 ergänzt, dass bei netzwerkbasiertem Speicher „jedes replizierte Datenstück mehrmals über das Netzwerk läuft“, was vor allem bei der Replikation innerhalb einer einzelnen vCenter-Server-Instanz in einem gemeinsam genutzten Netz ins Gewicht fällt. Entfernung und Latenz, die den Replikationsdurchsatz senken können, behandelt unser Artikel zur Entfernung zum Ausweichrechenzentrum.

NIST SP 800-34 Rev. 1 führt in seiner Tabelle 3-2 „WAN/VLAN-Replikation“ unter den Backup-Optionen für Systeme mit mittlerer Schutzstufe (moderate impact) auf. Die Lizenzierung von vSphere Replication behandelt unser Leitfaden zu VMware Live Site Recovery nach Broadcom, Rechenleistung und Speicher des Ausweichstandorts der Artikel zur Dimensionierung eines DR-Standorts.

Was wir tun

Im Rahmen unseres Service Cloud Disaster Recovery entwickelt unser Engineering-Partner Vixen.UNO mit Ihnen die DR-Strategie: kritische Systeme, Ziel-RPO und -RTO je Systemstufe und die Katastrophenszenarien, gegen die Sie sich absichern. Virtuelle Maschinen werden mit Veeam ab einem 15-Minuten-Intervall via Veeam Cloud Connect über einen verschlüsselten TLS/SSL-Kanal an einen Ausweichstandort in Baltnetas Tier-3-Rechenzentren in Litauen (ISO 27001, PCI DSS) repliziert. Sie verwalten die Replikation aus Ihrer bestehenden Veeam-Konsole, oder wir verwalten sie komplett auf unserer Seite. Planmäßige Failover-Tests laufen in einer isolierten Umgebung, mit einem Bericht nach jedem Test darüber, was hochgekommen ist, wie schnell und was zu beheben ist. Standort, Replikation, Tests und Support laufen über einen EU-Vertrag und eine Rechnung von Eurokommerz.

FAQ