4 Ihre Backup-Daten sind nur so gut wie Ihre Fähigkeit, sie von einem anderen Standort aus wiederherzustellen, wenn Ihr primäres Rechenzentrum nicht verfügbar ist. Brand, Hochwasser, Ransomware oder ein regionaler Ausfall können die Backup-Infrastruktur vor Ort unzugänglich machen. Die Replikation über mehrere Standorte ist für Enterprise-Backup und Disaster Recovery zu einer unverzichtbaren Anforderung geworden. Eine wirksame Umsetzung erfordert ein Verständnis der Architekturoptionen, der Strategien für das Bandbreitenmanagement, der Konsistenzgarantien und der betrieblichen Abläufe, die mehrere Backup-Kopien synchron und wiederherstellungsbereit halten. Anders als die Replikation auf Anwendungsebene, die perfekte Konsistenz wahren muss, hat die Backup-Replikation andere Anforderungen. Ihre Backup-Daten müssen letztlich konsistent sein – alle Kopien erreichen irgendwann denselben Stand –, aber nicht unbedingt in Echtzeit. Diese Lockerung ermöglicht Architekturansätze, die für Transaktionssysteme unmöglich wären. Sie schafft jedoch neue Herausforderungen: den Bandbreitenverbrauch über geografische Verbindungen steuern, mit Netzwerkpartitionen umgehen, bei denen Standorte getrennt werden, die Konsistenz der Wiederherstellungspunkte sichern, wenn Standorte in Verzug geraten sind, und den Failover auf sekundäre Backup-Standorte orchestrieren. Architekturmuster: Hub-and-Spoke vs. Mesh-Replikation Die grundlegende Entscheidung bei einer Backup-Architektur über mehrere Standorte betrifft die Topologie: wie die Standorte verbunden sind und Daten replizieren. Die beiden vorherrschenden Muster sind Hub-and-Spoke und vollständige Mesh-Replikation. In einer Hub-and-Spoke-Topologie empfängt ein primärer Standort (der Hub) alle Backup-Daten. Backup-Clients senden die Daten an den primären Standort, der sie dann an einen oder mehrere sekundäre Standorte (Spokes) repliziert. Der primäre Standort ist die maßgebliche Quelle, alle Daten laufen über ihn. Die betriebliche Einfachheit ist attraktiv. Es gibt einen einzigen Konfigurationspunkt. Die Bandbreite vom primären zu den sekundären Standorten lässt sich leicht steuern. Konflikte sind ausgeschlossen (nur der primäre Standort nimmt Schreibvorgänge an). Hub-and-Spoke schafft jedoch eine kritische Abhängigkeit: Fällt der primäre Standort aus, haben die sekundären Standorte veraltete Daten. Ist der primäre Standort zudem der einzige, der Backup-Schreibvorgänge annimmt, kann Ihr Unternehmen während seines Ausfalls keine neuen Daten sichern. Das Verständnis von Mustern der Multi-Site-Architektur (auf Englisch) hilft bei dieser Entscheidung. Bei der Mesh-Replikation sind mehrere Standorte gleichberechtigt verbunden. Jeder Standort kann Backup-Daten annehmen und repliziert sie an alle anderen. Empfängt Standort A Backup-Daten, repliziert er sie automatisch an Standort B und C. Empfängt Standort B gleichzeitig Backup-Daten, repliziert er sie an Standort A und C. Das bietet mehr Resilienz – jeder Standort kann zum Backup-Ziel werden, wenn andere ausfallen –, bringt aber Komplexität mit sich. Nehmen mehrere Standorte Schreibvorgänge an, können Konflikte entstehen: Was passiert, wenn Standort A und B während einer Trennung beide Aktualisierungen desselben Backup-Datensatzes erhalten? Netzwerkpartitionen müssen sorgfältig behandelt werden. Der Bandbreitenverbrauch vervielfacht sich: Daten werden womöglich von Standort A nach B und dann von B nach C repliziert. Die Wahl hängt von Ihren Wiederherstellungsanforderungen ab. Muss Ihr Unternehmen auch bei einem Ausfall des primären Standorts weiterhin Backup-Daten annehmen, ist eine Mesh-Replikation nötig. Ist Ihr primärer Standort hochverfügbar und geht es Ihnen vor allem um Disaster Recovery bei geografischen Katastrophen, ist Hub-and-Spoke einfacher. Viele große Unternehmen setzen auf hybride Ansätze: einen primären Hub, der Schreibvorgänge annimmt und an sekundäre Standorte repliziert, mit Failover-Verfahren, durch die ein sekundärer Standort bei einem Ausfall des primären vorübergehend zum Schreibziel wird. Bandbreitenmanagement und effiziente Replikation Die Replikation über mehrere Standorte verbraucht erhebliche Bandbreite. Bandbreite über große geografische Entfernungen ist teuer und begrenzt. Ein Großunternehmen, das täglich 500 GB sichert und an einen 1.000 Kilometer entfernten sekundären Standort repliziert, verbraucht täglich 500 GB Bandbreite zwischen den Standorten. Über einen Monat sind das 15 TB, die über die geografische Verbindung laufen. Deduplizierung ist das wichtigste Werkzeug für das Bandbreitenmanagement bei der Replikation. Empfängt Ihr primäres Backup mehrere Kopien desselben Datenbankblocks von verschiedenen Produktionssystemen, reduziert die Deduplizierung sie auf eine einzige gespeicherte Kopie. Die Replikation muss dann nur diese eine Kopie an die sekundären Standorte senden, nicht mehrere redundante. Bei stark redundanten Workloads kann die Deduplizierung die Bandbreite für die Replikation zwischen Standorten um 80–90 % senken. Delta-Replikation (nur Änderungen seit dem letzten Replikationszyklus werden repliziert) senkt die Bandbreite weiter. Statt jede Nacht das gesamte Backup mit 500 GB zu senden, überträgt die Delta-Replikation nur die Änderungen, typischerweise 10–20 % des gesamten Datenvolumens. Delta-Replikation erfordert eine Abstimmung zwischen den Standorten: Der primäre Standort muss nachverfolgen, welche Daten im letzten Zyklus gesendet wurden, Änderungen erkennen und nur diese übertragen. Auch eine Komprimierung während der Übertragung senkt den Bandbreitenverbrauch. An der Quelle vor der Übertragung komprimierte Daten können den Bandbreitenbedarf je nach Datentyp um 40–60 % senken. Komprimierung beansprucht jedoch CPU und erhöht die Latenz. Ist die Bandbreite der wichtigste Engpass und CPU-Leistung verfügbar, lohnt sich dieser Kompromiss. Eine intelligente Planung der Replikationsfenster kann die Nachfrage auf die begrenzte Bandbreite verteilen. Statt den ganzen Tag über kontinuierlich zu replizieren, können Sie die Replikation an sekundäre Standorte außerhalb der Spitzenzeiten planen. Das tauscht Aktualität bei der Wiederherstellung (sekundäre Standorte liegen vorübergehend zurück) gegen Bandbreiteneffizienz. Herausforderungen bei Konsistenz und Failover Die am meisten unterschätzte Komplexität bei der Replikation über mehrere Standorte ist die Sicherstellung der Konsistenz. Trennt eine Netzwerkpartition Ihren primären und sekundären Standort, arbeiten beide unabhängig weiter. Der primäre Standort erhält womöglich neue Backups, die noch nicht repliziert wurden. Der sekundäre Standort hat die Backups, die vor der Partition repliziert wurden. Erfolgt während der Partition ein Failover auf den sekundären Standort, sind dessen Backup-Daten nicht synchron mit denen des primären Standorts – die jüngsten Backups sind verloren. Eine klare Definition von RTO und RPO hilft bei der Wahl der Konsistenzstrategie. Unterschiedliche Replikationsstrategien bieten unterschiedliche Konsistenzgarantien. Synchrone Replikation – bei der der primäre Standort wartet, bis die sekundären Standorte das Schreiben der Daten bestätigen, bevor er das Backup als abgeschlossen meldet – stellt sicher, dass alle Standorte stets konsistente Daten haben. Sie erhöht jedoch die Latenz. Eine Netzwerkpartition stoppt die Backups vollständig (weil der primäre Standort keine Bestätigung von den sekundären erhält). Für produktive Backup-Systeme ist das oft inakzeptabel. Asynchrone Replikation meldet Backups am primären Standort sofort als abgeschlossen und sendet die Daten im Hintergrund an die sekundären Standorte. Das ermöglicht eine schnelle Annahme von Backups und Resilienz gegenüber Netzwerkpartitionen. Es schafft aber das Konsistenzproblem: Während einer Netzwerkpartition laufen primärer und sekundärer Standort auseinander. Viele Unternehmen setzen auf einen hybriden Ansatz: asynchrone Replikation für den laufenden Backup-Betrieb, kombiniert mit regelmäßigen Konsistenzprüfungen und Abgleichen. Ist die Netzwerkpartition behoben, gleichen die Standorte sich ab, und die sekundären Standorte erhalten alle während der Partition verpassten Backups. Failover-Tests und betriebliche Abläufe Der Wert der Replikation über mehrere Standorte verpufft, wenn Sie Ihre Failover-Verfahren nicht getestet haben. Kann Ihr Unternehmen tatsächlich von sekundären Standorten wiederherstellen, wenn der primäre Backup-Standort ausfällt? Viele Unternehmen haben sekundäre Backup-Standorte, die replizierte Daten empfangen, aber nie für eine Wiederherstellung getestet wurden. Regelmäßige Failover-Übungen sollten fester Bestandteil Ihres Backup-Betriebs sein. Wählen Sie vierteljährlich eine kritische Anwendung oder einen kritischen Datensatz aus und führen Sie eine vollständige Wiederherstellung vom sekundären Backup-Standort durch. Messen Sie die Dauer, prüfen Sie, ob alle Daten korrekt wiederhergestellt werden, und dokumentieren Sie Lücken oder Probleme. Solche Übungen decken Probleme auf, bevor eine echte Katastrophe eintritt. Failover-Verfahren müssen Entscheidungspunkte und Eskalationswege klar festlegen. Wer entscheidet, dass der primäre Backup-Standort tatsächlich ausgefallen und nicht nur langsam ist? Wie lange warten Sie auf die Wiederherstellung des primären Standorts, bevor Sie den Failover einleiten? Erfolgt der Failover zu früh, stellen Sie womöglich Daten wieder her, während der primäre Standort nur vorübergehend nicht verfügbar ist, und verlieren jüngste Backups, sobald er zurückkommt. Nach einem Failover muss Ihr Unternehmen die Wiederherstellung des primären Standorts planen. Wie synchronisiert sich der primäre Standort nach seiner Rückkehr mit dem sekundären Standort, der vorübergehend zum primären wurde? Failback-Verfahren sind oft komplexer als der Failover. Werden sie übersehen, haben Sie die Katastrophe zwar überstanden, können aber erst nach einer manuellen Neukonfiguration des Backup-Systems zum Normalbetrieb zurückkehren. Monitoring und Alarmierung für die Replikation über mehrere Standorte Die Replikation über mehrere Standorte schafft zahlreiche potenzielle Fehlerquellen: Netzwerkverbindungen können überlastet sein oder ausfallen, sekundären Standorten kann der Speicherplatz ausgehen, Replikationsprozesse können abstürzen oder stocken, und Zeitabweichungen zwischen Standorten können unerwartetes Verhalten verursachen. Zu den wichtigsten Kennzahlen gehören die Replikationsverzögerung (wie weit die sekundären Standorte hinter dem primären zurückliegen), die Fehlerrate der Replikation (wie viele Replikationsvorgänge fehlschlagen), der Bandbreitenverbrauch zwischen den Standorten, die Speicherkapazität an jedem Standort und der Konsistenzstatus. Lösen Sie einen Alarm aus, wenn die Replikationsverzögerung Ihr RTO-Fenster überschreitet. Liegt Ihr sekundärer Standort mehr als vier Stunden hinter dem primären und benötigen Sie ein RTO von vier Stunden, besteht ein Risiko. Alarmieren Sie, wenn sich die Netzwerkauslastung der Kapazität der Verbindung zwischen den Standorten nähert und wenn sekundäre Standorte ihre Speichergrenze erreichen. Betriebliche Runbooks sollten dokumentieren, wie auf häufige Replikationsfehler zu reagieren ist. Gerät die Replikation an einen sekundären Standort in Verzug, können Operatoren eine manuelle Neusynchronisierung anstoßen? Läuft ein sekundärer Standort voll, kann er auf einen tertiären Standort ausweichen, während der primäre Platz freigibt? Fazit: Replikation über mehrere Standorte als Voraussetzung für Resilienz Die Replikation über mehrere Standorte macht aus dem Backup, einem lokalen Schutzmechanismus, eine geografische Resilienzstrategie. Ihre Backup-Daten überstehen Katastrophen am primären Standort, Ransomware-Angriffe und regionale Desaster, weil sie kontinuierlich an geografisch entfernte Standorte repliziert wurden. Diese Resilienz erfordert jedoch eine durchdachte Architektur, Bandbreitenmanagement, Konsistenzverfahren und betriebliche Disziplin. Definieren Sie zunächst klar Ihre Wiederherstellungsanforderungen. Wird Ihr primärer Backup-Standort zerstört – wie lange kann Ihr Unternehmen ohne Wiederherstellung überleben? Dieser Zeitraum ist das RTO Ihrer Backup-Infrastruktur und bestimmt, ob Sie Hub-and-Spoke oder Mesh-Replikation benötigen. Dimensionieren Sie davon ausgehend die Bandbreite zwischen den Standorten. Setzen Sie Deduplizierung und Delta-Replikation ein, um die Kosten zu steuern. Führen Sie regelmäßige Failover-Tests ein, um sicherzustellen, dass Ihre sekundären Standorte tatsächlich wiederherstellungsbereit sind. Eine solide Enterprise-Backup-Strategie , die die Anforderungen an mehrere Standorte berücksichtigt, ist für die Resilienz unverzichtbar. Ihre nächste Investition in die Backup-Infrastruktur sollte die Replikation über mehrere Standorte als vorrangige Anforderung berücksichtigen, nicht als nachträglichen Gedanken. Weiterführende Artikel DRaaS: Disaster Recovery as a Service Hybrid-Cloud-Backup erklärt Business-Continuity-Plan Skalierbare Architektur für Backup-Ziele Was ist Hochverfügbarkeit (HA)? Ransomware-Schutz für Backups: So bauen Sie unveränderliche, wiederherstellbare Backups auf
