Zuverlässigkeit in Azure Backup

Azure Backup ist ein integrierter Azure-Dienst, der Cloud- und lokale Workloads sicher schützt. Azure Backup kann seinen Schutz nahtlos auf mehrere Workloads skalieren und bietet native Integration in Azure-Workloads, einschließlich virtueller Computer (VMs), SAP HANA in Azure VM, SQL in Azure VMs, Azure Files, Azure Blob, Azure Data Lake, Datenträger, Elastic SAN Volumes, AKS und mehr. Sie müssen keine Automatisierung oder Infrastruktur verwalten. Es ist nicht erforderlich, Skripts zu schreiben oder Speicher bereitzustellen.

Wenn Sie Azure verwenden, ist Zuverlässigkeit eine gemeinsame Verantwortung. Microsoft bietet eine Reihe von Funktionen zur Unterstützung von Resilienz und Wiederherstellung. Sie sind dafür verantwortlich, zu verstehen, wie diese Funktionen in allen von Ihnen verwendeten Diensten funktionieren, und die Funktionen auswählen, die Sie benötigen, um Ihre Geschäftsziele und Uptime-Ziele zu erfüllen.

In diesem Artikel wird beschrieben, wie Azure Backup widerstandsfähig für eine Vielzahl potenzieller Ausfälle und Probleme sein kann, einschließlich vorübergehender Fehler, Ausfall der Verfügbarkeitszone und Regionsausfälle. Außerdem werden einige wichtige Informationen zum Azure Backup Service Level Agreement (SLA) hervorgehoben.

Empfehlungen für die Produktionsimplementierung für Zuverlässigkeit

Für die Sicherung Ihrer Produktionsworkloads empfehlen wir, Ihren Tresor wie folgt zu konfigurieren:

Die restlichen Abschnitte dieses Artikels enthalten weitere Details zu diesen Konfigurationen.

Eine Liste weiterer Empfehlungen für Azure Backup, einschließlich zuverlässigkeitsorientierter Empfehlungen, finden Sie unter Backup Cloud und lokale Workloads in der Cloud.

Übersicht über die Zuverlässigkeitsarchitektur

In diesem Abschnitt werden einige der wichtigen Aspekte der Funktionsweise des Diensts beschrieben, die aus Zuverlässigkeitsperspektive am relevantesten sind. Im Abschnitt wird die logische Architektur vorgestellt, die einige der Ressourcen und Features enthält, die Sie bereitstellen und verwenden. Außerdem wird die physische Architektur erläutert, die Details zur Funktionsweise des Diensts unter den Deckeln bereitstellt.

Logische Architektur

Azure Backup kann eine Vielzahl von Datenquellen sichern und wiederherstellen. Sie konfigurieren Sicherungen je nach Datenquelle, mit der Sie arbeiten, unterschiedlich. Zu den allgemeinen Datenquellen gehören:

• Virtuelle Azure-Computer (VMs)
• Verschiedene Datenbanken
• Azure Blob-Konten
• AKS-Cluster
• Lokale Server über den Microsoft Azure Recovery Services (MARS)-Agent

Azure Backup speichert Ihre gesicherten Daten in Tresoren. Ein Tresor ist eine Onlinespeicherentität in Azure, die zum Speichern von Daten wie Sicherungskopien, Wiederherstellungspunkten und Sicherungsrichtlinien verwendet wird. Es gibt zwei Arten von Tresoren: Recovery Services Vaults und Backup Vaults. Je nachdem, was Sie schützen müssen, können Sie einen oder beide Tresortypen verwenden. Eine Liste der Datenquellen, die jeder Tresortyp unterstützt, finden Sie unter Welche Tresortypen werden für die Sicherung und Wiederherstellung unterstützt?.

Aufträge stellen die Aktivität des Sicherns oder Wiederherstellens Ihrer Daten dar. Sicherungsaufträge umfassen geplante oder On-Demand-Vorgänge, die Ihre Daten aus der Quelle in den Tresor kopieren. Wiederherstellungsaufträge umfassen Vorgänge, mit denen Ihre Daten vom Sicherungsspeicher an einen Zielspeicherort wiederhergestellt werden. Jeder Auftrag verfügt über einen eindeutigen Bezeichner und eine Statusnachverfolgung, sodass Sie den Fortschritt überwachen und Probleme beheben können, die bei Sicherungs- und Wiederherstellungsvorgängen auftreten. Außerdem erstellen Sie Sicherungsrichtlinien , die Aufträgen zugeordnet sind. Richtlinien geben die Konfiguration wie den Sicherungszeitplan und die Dauer der Aufbewahrung von Daten an.

Tresore speichern Ihre Sicherungsrichtlinien und -konfigurationen, und sie speichern auch Metadaten zu Aufträgen, was die Nachverfolgung und Problembehandlung ermöglicht.

Physische Architektur

Die zentrale Azure Backup-Dienstinfrastruktur wird von Microsoft verwaltet. Diese Infrastruktur ist für die Verwaltung und den Betrieb des Diensts verantwortlich, einschließlich Auslösen und Überwachen von Aufträgen.

Der Azure Backup-Dienst speichert Sicherungen im Tresor. Tresore bauen auf Azure Storage auf. Tresore replizieren Ihre Sicherungsdaten automatisch, und die Haltbarkeit und Resilienz der Sicherung hängen von der Speicherredundanz des Tresors ab:

• Lokal redundanter Speicher (LRS) repliziert die Daten in Ihrem Tresor in eine oder mehrere Azure-Verfügbarkeitszonen, die sich in der primären Region Ihrer Wahl befinden. Obwohl es keine Option gibt, Ihre bevorzugte Verfügbarkeitszone auszuwählen, kann Azure LRS-Konten über Zonen hinweg verschieben oder erweitern, um den Lastenausgleich zu verbessern. Es gibt keine Garantie dafür, dass Ihre Daten über Zonen verteilt werden. Weitere Informationen zu Verfügbarkeitszonen finden Sie unter Was sind Verfügbarkeitszonen?.

• Zonenredundanter Speicher (ZRS) und georedundanter Speicher (GRS) bieten zusätzlichen Schutz. In diesem Artikel werden diese Optionen ausführlich beschrieben.

Resilienz für vorübergehende Fehler

Vorübergehende Fehler sind kurze, zeitweilige Fehler in Komponenten. Sie treten häufig in einer verteilten Umgebung wie der Cloud auf und sind ein normaler Bestandteil von Vorgängen. Vorübergehende Fehler korrigieren sich nach kurzer Zeit. Es ist wichtig, dass Ihre Anwendungen vorübergehende Fehler behandeln können, in der Regel durch Wiederholen betroffener Anforderungen.

Alle in der Cloud gehosteten Anwendungen sollten die Anleitung zur vorübergehenden Fehlerbehandlung von Azure befolgen, wenn sie mit cloudgehosteten APIs, Datenbanken und anderen Komponenten kommunizieren. Weitere Informationen finden Sie unter Empfehlungen zur Behandlung vorübergehender Fehler.

Wenn Sie Azure Backup verwenden, sind sowohl Sicherungs- als auch Wiederherstellungsworkflows widerstandsfähig für zeitweilige Fehler. Der Dienst wird automatisch erneut ausgeführt, wenn vorübergehende Netzwerkfehler oder vorübergehende Dienstunterbrechungen auftreten. Sie konfigurieren keine Wiederholungslogik. Wenn wiederholte Fehler auftreten, lesen Sie die Dokumentation zur Problembehandlung.

Ausfallsicherheit bei Ausfällen von Verfügbarkeitszonen

Verfügbarkeitszonen sind physisch getrennte Gruppen von Rechenzentren innerhalb einer Azure-Region. Wenn eine Zone ausfällt, erfolgt ein Failover der Dienste zu einer der verbleibenden Zonen.

Azure Backup verwaltet separat die Verfügbarkeitszonenkonfiguration des Diensts und für Ihre Daten.

• Service: Der Azure Backup-Dienst selbst ist automatisch zonensicher in unterstützten Regionen, ohne dass eine Aktion von Ihnen erforderlich ist. Diese integrierte Zonenresilienz gilt jedoch nicht für Ihre gesicherten Daten.

• Redundanz des Sicherungsspeichers: Wählen Sie die gewünschte Redundanzstufe für Ihre Sicherungsdaten aus, indem Sie Ihren Recovery Services-Tresor oder Sicherungstresor konfigurieren. Wenn Sie zonenredundanten Speicher (ZRS) auswählen, werden Kopien Ihrer Sicherungsdaten automatisch in mehreren Verfügbarkeitszonen in der von Ihnen verwendeten Azure-Region gespeichert.

  Wenn Sie ZRS nicht verwenden, werden Ihre Sicherungsdaten als nicht zonenal betrachtet und können in einer beliebigen Zone gespeichert werden. Wenn eine Zone in der Region ein Problem hat, sind nichtzonale Sicherungsdaten möglicherweise nicht verfügbar.

Anforderungen

• Regionsunterstützung: Der Dienst ist in allen Regionen mit Verfügbarkeitszonen automatisch zonensicher. ZRS-Tresore werden in denselben Regionen unterstützt.

• Nur neue Tresore: Konfigurieren Sie ZRS auf Ihrem Tresor vor der ersten Sicherung.

Kosten

Wenn Sie zonenredundanten Speicher (ZRS) für Ihre Sicherungen aktivieren, werden Sie aufgrund des zusätzlichen Replikations- und Speicheraufwands mit einer anderen Rate als lokal redundantem Speicher (LRS) belastet. Weitere Informationen finden Sie unter Azure Backup – Preise.

Konfigurieren der Unterstützung von Verfügbarkeitszonen

• Erstellen Sie einen neuen Tresor, der ZRS verwendet: Wenn Sie einen Tresor erstellen, sollten Sie auch die Speicherredundanz konfigurieren. Die schritte, die Sie ausführen, unterscheiden sich je nach Tresortyp. Weitere Informationen findest du unter:

  • Sicherungstresore erstellen und löschen
  • Erstellen und Konfigurieren eines Wiederherstellungsdienste-Tresors

• Konfigurieren Sie ZRS für vorhandene Tresore: Konfigurieren Sie die Speicherredundanz für Sicherungstresore beim Erstellen des Tresors. Nachdem ein Sicherungstresor erstellt wurde, ist die Einstellung gesperrt und kann nicht mehr geändert werden.

  Für Recovery Services-Tresore muss Speicherredundanz konfiguriert werden, bevor Workloads geschützt werden. Sobald eine Arbeitsauslastung geschützt ist, ist die Einstellung gesperrt und kann nicht mehr geändert werden.

  Sie können einen neuen Tresor erstellen, der für die Verwendung von ZRS konfiguriert ist, und Ihre Workloads dem neuen Tresor neu zuweisen. Dieser Ansatz erfordert jedoch Ausfallzeiten, und Sie sind dafür verantwortlich, vorhandene Wiederherstellungspunkte und andere Daten manuell zu löschen, da die Aufbewahrungsrichtlinien des alten Tresors nicht mehr gelten. Weitere Informationen zum Löschen eines Tresors finden Sie unter Löschen eines Sicherungstresors oder Löschen eines Wiederherstellungsdienste-Tresors.

Verhalten, wenn alle Zonen fehlerfrei sind

Wenn Tresore zonenredundanten Speicher verwenden und alle Verfügbarkeitszonen betriebsbereit sind, erwarten Sie Folgendes:

• Zonenübergreifender Vorgang: Sicherungsaufträge werden auf Infrastruktur ausgeführt, die über Zonen hinweg repliziert wird. Azure verwaltet Aufträge aus der Infrastruktur in einer beliebigen Zone.

• Zonenübergreifende Datenreplikation: ZRS repliziert gesicherte Daten über Zonen hinweg. Replikation erfolgt synchron, was bedeutet, dass mehrere Zonen jeden Schreibvorgang bestätigen, bevor er abgeschlossen ist.

Verhalten bei einem Zoneausfall

Wenn Tresore so konfiguriert sind, dass zonenredundanter Speicher verwendet wird und ein Ausfall der Verfügbarkeitszone auftritt, sollten Sie Folgendes beachten:

• Erkennung und Reaktion: Für den Azure Backup-Dienst selbst ist Microsoft dafür verantwortlich, einen Fehler in einer Verfügbarkeitszone zu erkennen und darauf zu reagieren. Sie müssen keine Maßnahmen ergreifen, um ein Zonenfailover zu initiieren.

  Von Bedeutung

  Bei Daten oder Ressourcen, die aufgrund des Zonenausfalls nicht verfügbar sind, sind Sie dafür verantwortlich, den Ausfall zu erkennen und Wiederherstellungsaktionen auszuführen, einschließlich der Wiederherstellung von Sicherungen in einer fehlerfreien Zone.

• Benachrichtigung: Microsoft benachrichtigt Sie nicht automatisch, wenn eine Zone deaktiviert ist. Sie können jedoch Azure Resource Health verwenden, um den Status einer einzelnen Ressource zu überwachen, und Sie können Ressourcenintegritätswarnungen einrichten, um Sie über Probleme zu informieren. Sie können auch Azure Service Health verwenden, um die allgemeine Integrität des Diensts zu verstehen, einschließlich jeglicher Zonenfehler, und Sie können Dienststatuswarnungen einrichten, um Sie über Probleme zu informieren.

• Aktive Anforderungen: Das Verhalten aller aktiven Aufträge hängt davon ab, welche Zone fehlgeschlagen ist.

  • Bei Datenquellen in der Zone der fehlgeschlagenen Verfügbarkeit sind die Datenquellen aufgrund des Zonenfehlers wahrscheinlich nicht verfügbar. Alle aktiven Aufträge können anhalten oder fehlschlagen.
  • Bei Datenquellen in fehlerfreien Verfügbarkeitszonen, in denen aktive Aufträge ausgeführt werden, kann eine geringe Anzahl von Ausfallzeiten, in der Regel einige Sekunden, auftreten, während die Plattform zur Verwendung fehlerfreier Verfügbarkeitszonen für den Azure Backup-Dienst wechselt.

• Erwarteter Datenverlust: Die Menge an Datenverlust, die Sie erwarten können, wird auch als Ziel des Wiederherstellungspunkts (Recovery Point Objective, RPO) bezeichnet. Das RPO für Ihre Sicherungsdaten hängt von mehreren Faktoren ab, einschließlich Ihres Sicherungszeitplans. Im Allgemeinen wird für einen Zonenausfall kein Verlust gesicherter Daten erwartet, da alle Daten synchron über Zonen repliziert werden.

• Erwartete Ausfallzeiten: Die Menge der Ausfallzeiten, die Sie erwarten können, wird auch als Wiederherstellungszeitziel (RTO) bezeichnet. Das RTO unterscheidet sich für jedes der folgenden Szenarien:

  • Bei Datenquellen in der ausgefallenen Verfügbarkeitszone sind die Datenquellen möglicherweise erst dann verfügbar, wenn die Zone wiederhergestellt wird. Sicherungsaufträge können möglicherweise nicht ausgeführt werden, bis die Datenquelle erneut verfügbar ist. Das RTO ist nicht definiert.
  • Bei Datenquellen in fehlerfreien Verfügbarkeitszonen kann eine geringe Anzahl von Ausfallzeiten, in der Regel einige Sekunden, auftreten, während die Plattform zur Verwendung fehlerfreier Verfügbarkeitszonen für den Azure Backup-Dienst wechselt.

• Umverteilung: Alle nachfolgenden Auftragsausführungen verwenden automatisch Infrastruktur in fehlerfreien Zonen, solange die Datenquellen verfügbar sind.

  Sie sind dafür verantwortlich, Ihre Sicherung in einer gesunden Zone wiederherzustellen und alle Lastenausgleicher, Clients und andere Systeme neu zu konfigurieren, um den Datenverkehr in eine gesunde Infrastruktur in der neuen Zone umzuleiten.

Zonenwiederherstellung

Wenn die Verfügbarkeitszone wiederhergestellt wird, stellt Azure Backup Vorgänge in der Verfügbarkeitszone automatisch wieder her und leitet den Datenverkehr normal zwischen den Zonen um. Aufträge werden weiterhin ausgeführt, und die Daten sind weiterhin verfügbar.

Test auf Zonenfehler

Die Azure Backup-Plattform verwaltet Datenverkehrsrouting, Datenreplikation, Failover und Failback. Dieses Feature ist vollständig verwaltet. Deshalb müssen Sie die Prozesse für ausgefallene Verfügbarkeitszonen weder einleiten noch überprüfen.

Widerstandsfähigkeit bei regionalen Ausfällen

Azure Backup unterstützt Georedundanz und Failover über georedundanten Speicher (GRS) und regionsübergreifende Wiederherstellung.

Georedundanter Speicher und regionsübergreifende Wiederherstellung

Um regionale Redundanz für Ihre Sicherungsdaten zu erzielen, ermöglicht Azure Backup Ihnen, Ihre Sicherungen mithilfe von georedundanten Speicher (GRS) in eine azure-gekoppelte Region zu replizieren. GRS schützt Ihre Sicherungen vor regionalen Ausfällen.

Die Region, in der Sie Ihren Tresor bereitstellen, wird als primäre Region bezeichnet. Ihre Datenquellen müssen sich in der primären Region befinden. Sie können keine Sicherungen in einem Tresor in einer anderen Region konfigurieren.

Die gekoppelte Region wird auch als sekundäre Region bezeichnet.

Wenn Sie GRS nicht konfigurieren, können Sie in der Region des Tresors möglicherweise trotzdem auf den Tresor zugreifen und Sicherungselemente anzeigen. Ohne regionale Redundanz bleiben die zugrunde liegenden Sicherungsdaten jedoch für Wiederherstellungsvorgänge nicht verfügbar.

Regionsübergreifende Wiederherstellung

Wenn Sie GRS auf einem Tresor konfigurieren, stellt Microsoft Sicherungen in der gekoppelten Region zur Verfügung, nachdem sie einen Ausfall in der primären Region deklariert haben. Wenn Ihre Datenquelle die Aktivierung der regionsübergreifenden Wiederherstellung unterstützt, können Sie aus wiederhergestellten Wiederherstellungspunkten der sekundären Region auch dann wiederherstellen, wenn kein Ausfall in der primären Region auftritt. Mit der regionsübergreifenden Wiederherstellung können Sie auch Übungen durchführen, um Ihre Resilienz gegenüber regionalen Ausfällen zu überprüfen. Durch Aktivieren der regionsübergreifenden Wiederherstellung wird Ihr Sicherungsspeicher von GRS auf georedundanten Speicher mit Lesezugriff (RA-GRS) aufgerüstet.

Anforderungen

• Regionsunterstützung: GRS für Azure Backup funktioniert nur in gekoppelten Azure-Regionen.

• Nur neue Tresore: GRS muss auf Ihrem Tresor konfiguriert werden, bevor die erste Sicherung stattfindet.

Überlegungen

• Regionsübergreifende Wiederherstellung: Nachdem Sie die Regon-Wiederherstellung aktiviert haben, kann es bis zu 48 Stunden dauern, bis die Sicherungselemente in der sekundären Region verfügbar sind.

Kosten

GRS-Tresore verursachen zusätzliche Kosten für die regionsübergreifende Replikation und die Speicherung in der sekundären Region. Die Datenübertragung zwischen Azure-Regionen wird basierend auf standardmäßigen Bandbreitenraten zwischen Regionen berechnet. Die regionsübergreifende Wiederherstellung wird mit einem anderen Gebührensatz berechnet, da Microsoft Ihren Tresorspeicher von GRS auf RA-GRS umstellt. Weitere Informationen finden Sie unter Azure Backup – Preise.

Konfigurieren der Unterstützung für mehrere Regionen

• Erstellen Sie einen neuen Tresor, der GRS und CRR verwendet: Wenn Sie einen Tresor erstellen, sollten Sie auch die Speicherredundanz konfigurieren. Nach der Auswahl von GRS können Sie optional CRR im Tresor aktivieren. Die schritte, die Sie ausführen, unterscheiden sich je nach Tresortyp. Weitere Informationen findest du unter:

  • Sicherungstresore erstellen und löschen
  • Erstellen und Konfigurieren eines Wiederherstellungsdienste-Tresors

• Konfigurieren von GRS und CRR für vorhandene Tresore: Bei Sicherungstresorn muss speicherredundanz konfiguriert werden, wenn Sie den Tresor erstellen.

  Für Recovery Services-Tresore muss Speicherredundanz konfiguriert werden, bevor Workloads geschützt werden. Sobald eine Arbeitsauslastung geschützt ist, ist die Einstellung gesperrt und kann nicht mehr geändert werden.

  Sie können CRR für vorhandene GRS-Tresore aktivieren. Sie können CRR nicht deaktivieren, sobald sie aktiviert ist.

Verhalten, wenn alle Regionen funktionsfähig sind

In diesem Abschnitt wird beschrieben, was Sie erwarten müssen, wenn Tresore für die Verwendung georedundanter Speicher konfiguriert sind und alle Regionen betriebsbereit sind.

• Überregionaler Betrieb: Sicherungen werden immer in der primären Region abgeschlossen, welche die Region ist, in der der Tresor und die Datenquelle bereitgestellt werden.

• Regionsübergreifende Datenreplikation: Wenn der Tresor für die Verwendung von GRS konfiguriert ist, werden Sicherungen zunächst mithilfe von lokal redundanten Speicher (LRS) in die primäre Region übernommen. Nach erfolgreichem Abschluss im primären Bereich werden die Daten asynchron in den sekundären Bereich repliziert, in dem sie mithilfe von LRS gespeichert werden. Es kann bis zu 12 Stunden dauern, bis die Sicherungsdaten aus der primären Region in die sekundäre Region repliziert werden.

Verhalten während eines Regionenausfalls

In diesem Abschnitt wird beschrieben, was Sie erwarten müssen, wenn Tresore für die Verwendung georedundanter Speicher konfiguriert sind und ein Ausfall in der primären Region auftritt.

• Erkennung und Reaktion: Für Datenquellen, die die regionsübergreifende Wiederherstellung unterstützen und bei denen die regionsübergreifende Wiederherstellung im Tresor aktiviert ist, können Sie jederzeit eine eigene regionsübergreifende Wiederherstellung in die gekoppelte Region initiieren, einschließlich während eines regionalen Ausfalls oder einer Katastrophe. Sie sind dafür verantwortlich, den Ausfall zu erkennen und alle Wiederherstellungsaktionen auszuführen, einschließlich der Wiederherstellung von Sicherungen in einer fehlerfreien Region.

  Für alle anderen Szenarien stehen die Daten, die in die sekundäre Region repliziert werden, nur dann zur Wiederherstellung in der sekundären Region zur Verfügung, wenn Azure eine Katastrophe in der primären Region deklariert. Microsoft ist dafür verantwortlich, eine solche Katastrophe zu deklarieren. Die Zeitspanne, die zum Deklarieren einer Katastrophe benötigt wird, hängt vom Schweregrad des Vorfalls und der Zeit ab, die zum Bewerten der Situation erforderlich ist. Es würde wahrscheinlich erst nach einer längeren Zeitspanne durchgeführt werden.

• Benachrichtigung: Microsoft benachrichtigt Sie nicht automatisch, wenn eine Region abfällt. Aber:

  • Sie können Azure Resource Health verwenden, um den Status einer einzelnen Ressource zu überwachen, und Sie können Ressourcenintegritätswarnungen einrichten, um Sie über Probleme zu informieren.

  • Sie können Azure Service Health verwenden, um die allgemeine Integrität des Diensts zu verstehen, einschließlich aller Regionsfehler, und Sie können Dienststatuswarnungen einrichten, um Sie über Probleme zu informieren.

• Erwarteter Datenverlust: Das RPO für Ihre Sicherungsdaten hängt von mehreren Faktoren ab, einschließlich Ihres Sicherungszeitplans. Im Allgemeinen sollten Sie für einen Regionsausfall bis zu 36 Stunden Datenverlust erwarten, da das RPO in der primären Region 24 Stunden beträgt und es bis zu 12 Stunden dauern kann, bis die Sicherungsdaten aus der primären in die sekundäre Region repliziert werden.

• Erwartete Ausfallzeiten: Das RTO unterscheidet sich für jedes der folgenden Szenarien:

  • Datenquellen und andere Ressourcen in der fehlerhaften Region sind möglicherweise erst verfügbar, wenn die Region wiederhergestellt wird, sodass die RTO nicht definiert ist.
  • Azure Backup kann möglicherweise keine Sicherungs- oder Wiederherstellungsvorgänge in der fehlerhaften Region ausführen, bis die Region wiederhergestellt wird, sodass die RTO nicht definiert ist.
  • Wenn Sie die regionsübergreifende Wiederherstellung verwenden, ist das RTO zum Initiieren der Wiederherstellung von Sicherungen, die bereits in die gekoppelte Region repliziert wurden, null. Wenn Sie keine regionsübergreifende Wiederherstellung verwenden, hängt das RTO davon ab, wie lange es dauert, bis Microsoft eine Katastrophe in der fehlgeschlagenen Region deklariert.

  Es können keine Sicherungsaufträge ausgeführt werden, während der primäre Bereich offline ist. Sie können Daten im Tresor wiederherstellen, aber keine neuen Daten hinzufügen.

• Umverteilung: Es können keine Sicherungsaufträge ausgeführt werden, während der primäre Bereich offline ist. Sie können Daten im Tresor wiederherstellen, aber keine neuen Daten hinzufügen.

  Sie sind dafür verantwortlich, Ihre Sicherung in der Infrastruktur in der gekoppelten Region wiederherzustellen und Lastenausgleich, Clients und andere Systeme so neu zu konfigurieren, dass der Datenverkehr zu einer funktionierenden Infrastruktur in der gekoppelten Region umgeleitet wird.

Region-Wiederherstellung

Wenn die primäre Region wiederhergestellt wird, stellt Azure Backup Vorgänge in der Region automatisch wieder her. Die Verfügbarkeit von Stellen und Daten bleibt bestehen.

Testen auf Regionsfehler

Sie können die regionsübergreifende Wiederherstellung verwenden, um einen Wiederherstellungsvorgang für den gekoppelten Bereich auszuführen. Sie können diesen Ansatz verwenden, um Ihre Wiederherstellungs- und andere Wiederherstellungsprozesse zu überprüfen.

Resilienz beim Verlust von Sicherungsdaten

Azure Backup bietet zwei wichtige Wiederherstellungsfeatures, um das versehentliche oder böswillige Löschen Ihrer Sicherungsdaten zu verhindern:

• Soft Delete ermöglicht es Ihnen, gelöschte Objekte und Tresore während eines konfigurierbaren Aufbewahrungszeitraums wiederherzustellen. Dieser Zeitraum beträgt standardmäßig 14 Tage, sie können jedoch konfiguriert werden. Stellen Sie sich Soft Delete wie einen Papierkorb für Ihre Datensicherungen und Vaults vor. Weitere Informationen finden Sie unter "Standardmäßig sicher mit vorläufigem Löschen für Azure Backup".

• Unveränderliche Tresore können Ihnen dabei helfen, Ihre Sicherungsdaten zu schützen, indem alle Vorgänge blockiert werden, die zu Verlust von Wiederherstellungspunkten führen könnten. Sie können die Einstellung des unveränderlichen Tresors sperren, um sie unumkehrbar zu machen. Sie können auch WORM (Write Once, Read Many) Speicher für Backups verwenden, um zu verhindern, dass böswillige Akteure die Unveränderbarkeit deaktivieren und Backups löschen. Weitere Informationen finden Sie unter Unveränderlicher Tresor für Azure Backup.

Service-Level-Vereinbarung

Der Service level agreement (SLA) für Azure-Dienste beschreibt die erwartete Verfügbarkeit jedes Diensts und die Bedingungen, die Ihre Lösung erfüllen muss, um diese Verfügbarkeitserwartungen zu erreichen. Weitere Informationen finden Sie unter SLAs für Onlinedienste.

Die Azure Backup SLA deckt die Verfügbarkeit des Diensts für Sicherungs- und Wiederherstellungsvorgänge ab. Um von der SLA abgedeckt zu werden, müssen Sie fehlgeschlagene Sicherungs- oder Wiederherstellungsaufträge nicht weniger häufig als einmal alle dreißig Minuten wiederholen.