Zuverlässigkeit in Azure Backup

Azure Backup ist ein integrierter Azure-Dienst, der Cloud- und lokale Workloads sicher schützt. Backup kann seinen Schutz über mehrere Workloads hinweg skalieren und bietet native Integration mit Azure Workloads, einschließlich virtueller Computer (VMs), SAP HANA in Azure VMs, SQL in Azure VMs, Azure Files, Azure Blob Storage, Azure Data Lake Storage, Azure verwaltete Datenträger, Azure Elastic SAN Volumes und Azure Kubernetes Service (AKS). Sie müssen keine Automatisierung oder Infrastruktur verwalten, Skripts schreiben oder Speicher bereitstellen.

Wenn Sie Azure verwenden, ist zustellbarkeit 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 die Sicherung 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 Service-Level-Agreement (SLA) für die Sicherung hervorgehoben.

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

Um Ihre Produktionsworkloads zu sichern, empfiehlt es sich, Ihren Vault auf folgende Weise einzurichten:

In den folgenden Abschnitten dieses Artikels finden Sie weitere Details zu diesen Konfigurationen.

Eine Liste weiterer Empfehlungen für die Sicherung, 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

Die Sicherung kann eine Vielzahl von Datenquellen sichern und wiederherstellen. Sie konfigurieren Sicherungen je nach Datenquelle, mit der Sie arbeiten, unterschiedlich. Die folgenden Datenquellen sind häufig:

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

Sicherung speichert Ihre gesicherten Daten in Tresoren. Tresore sind Onlinespeicherentitäten in Azure, die Daten enthalten, z. B. Sicherungskopien, Wiederherstellungspunkte und Sicherungsrichtlinien. Recovery Services Vaults und Backup Vaults sind zwei Arten von Tresoren. Sie können einen oder beide Typen verwenden, je nachdem, was Sie schützen müssen. Eine Liste der Datenquellen, die jeder Tresortyp unterstützt, finden Sie in den häufig gestellten Fragen zu den für die Sicherung und Wiederherstellung unterstützten Tresoren.

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 der Sicherungszeitplan und die Dauer der Aufbewahrung von Daten an.

Tresore speichern Ihre Sicherungsrichtlinien und -konfigurationen zusammen mit Metadaten zu Aufträgen, mit denen Sie Aufträge und Problembehandlungen nachverfolgen können.

Physische Architektur

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

Backups werden im Tresor gespeichert. Tresore basieren auf Azure Storage. Tresore replizieren Ihre Sicherungsdaten automatisch, und die Haltbarkeit und Resilienz der Sicherung hängen von der Speicherredundanz des Tresors ab.

• Locally redundant storage (LRS) repliziert Daten in Ihrem Tresor in eine oder mehrere Azure Verfügbarkeitszonen, die sich in der primären Region Ihrer Wahl befinden. Sie können Ihre bevorzugte Verfügbarkeitszone nicht auswählen, aber Azure können LRS-Konten über Zonen hinweg verschieben oder erweitern, um den Lastenausgleich zu verbessern. Ihre Daten werden nicht garantiert über Zonen verteilt. Weitere Informationen finden Sie unter Übersicht über Verfügbarkeitszonen.

• ZRS und 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 den Azure richtlinien für die vorübergehende Fehlerbehandlung befolgen, wenn sie mit allen in der Cloud gehosteten APIs, Datenbanken und anderen Komponenten kommunizieren. Weitere Informationen finden Sie unter Empfehlungen zur Behandlung vorübergehender Fehler.

Wenn Sie die Sicherung 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 Fehlerbehebung bei Backup-Tresor-Verwaltungsvorgängen.

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.

Die Sicherung verwaltet die Konfiguration der Verfügbarkeitszonen des Dienstes und Ihrer Daten getrennt.

• Service: Der Sicherungsdienst ist automatisch zonensicher in unterstützten Regionen. Diese integrierte Zonenresilienz gilt jedoch nicht für Ihre gesicherten Daten.

• Redundanz des Sicherungsspeichers: Wählen Sie die redundanzstufe aus, die Sie für Ihre Sicherungsdaten benötigen, indem Sie Den Recovery Services-Tresor oder den Sicherungstresor konfigurieren. Wenn Sie ZRS auswählen, werden Kopien Ihrer Sicherungsdaten automatisch in mehreren Verfügbarkeitszonen in der von Ihnen verwendeten region Azure gespeichert.

  Wenn Sie ZRS nicht verwenden, werden Ihre Sicherungsdaten als nichtzonal 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 automatisch zonensicher in allen Regionen mit Verfügbarkeitszonen. ZRS-Tresore werden in denselben Regionen unterstützt.

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

Kosten

Wenn Sie ZRS für Ihre Sicherungen aktivieren, werden Sie aufgrund des zusätzlichen Replikations- und Speicheraufwands zu einer anderen Rate als LRS belastet. Weitere Informationen finden Sie unter Backup-Preise.

Konfigurieren der Unterstützung von Verfügbarkeitszonen

• Erstellen Sie einen neuen Tresor, der ZRS verwendet: Konfigurieren Sie Speicherredundanz beim Erstellen eines Tresors. Je nach Tresortyp führen Sie unterschiedliche Schritte aus. Weitere Informationen finden Sie in den folgenden Artikeln:

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

• Konfigurieren Sie ZRS für vorhandene Tresore: Konfigurieren Sie die Speicherredundanz für Sicherungstresore beim Erstellen des Tresors. Nachdem Sie einen Sicherungstresor erstellt haben, ist die Einstellung gesperrt, und Sie können ihn nicht mehr ändern.

  Für Recovery Services-Tresore müssen Sie Speicherredundanz konfigurieren, bevor Sie Workloads schützen. Nachdem Sie eine Workload geschützt haben, ist die Einstellung gesperrt, und Sie können sie nicht mehr ändern.

  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. Weitere Informationen finden Sie unter Ändern von Standardeinstellungen. Sie sind auch für das manuelle Löschen vorhandener Wiederherstellungspunkte und anderer Daten verantwortlich, da die Aufbewahrungsrichtlinien des alten Tresors nicht mehr gelten. Weitere Informationen finden Sie unter Löschen eines Sicherungstresors oder Löschen eines Wiederherstellungsdienst-Tresors.

Verhalten, wenn alle Zonen fehlerfrei sind

In diesem Abschnitt wird beschrieben, worauf Sie achten sollten, wenn Sie Tresore für ZRS konfigurieren und alle Zonen betriebsbereit sind.

• 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 wird.

Verhalten bei einem Zoneausfall

In diesem Abschnitt wird erläutert, was Sie erwarten müssen, wenn Sie Vaults für ZRS konfigurieren und es zu einem Ausfall in einer der Zonen kommt.

• Erkennung und Reaktion: Für den Sicherungsdienst selbst ist Microsoft dafür verantwortlich, Ausfälle in Verfügbarkeitszonen 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.

• Notification: Microsoft benachrichtigt Sie nicht automatisch, wenn eine Zone abfällt. Sie können jedoch Azure Resource Health verwenden, um den Status einer einzelnen Ressource zu überwachen, und Sie können Resource Health Alerts einrichten, um Sie über Probleme zu informieren. Sie können auch Azure Service Health verwenden, um den Gesamtstatus des Diensts zu verstehen, einschließlich aller Zonenfehler, und Sie können Service Health Alerts einrichten, um Sie über Probleme zu informieren.

• Aktive Anforderungen: Das Verhalten aktiver Aufträge hängt davon ab, welche Zone fehlschlägt.

  • Bei Datenquellen in der Zone der fehlgeschlagenen Verfügbarkeit macht der Zonenfehler die Datenquellen nicht verfügbar. Aktive Jobs können pausieren oder fehlschlagen.

  • Bei Datenquellen in fehlerfreien Verfügbarkeitszonen, in denen aktive Aufträge ausgeführt werden, kann eine geringe Anzahl von Ausfallzeiten auftreten, in der Regel einige Sekunden, während die Plattform zu fehlerfreien Verfügbarkeitszonen für den Sicherungsdienst wechselt.

• Erwarteter Datenverlust: Die erwartete Menge an Datenverlust 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 erwartete Ausfallzeit wird auch als Wiederherstellungszeitziel (RTO) bezeichnet. Das RTO unterscheidet sich für jedes der folgenden Szenarien:

  • Datenquellen in einer ausgefallenen Verfügbarkeitszone sind möglicherweise erst wieder 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 auftreten, in der Regel einige Sekunden, während die Plattform zu fehlerfreien Verfügbarkeitszonen für den Sicherungsdienst wechselt.

• Umverteilung: Nachfolgende Jobläufe verwenden automatisch Infrastruktur in funktionsfähigen Zonen, solange die Datenquellen verfügbar sind.

  Sie sind dafür verantwortlich, Ihre Sicherung in der Infrastruktur in einer gesunden Zone wiederherzustellen und Load Balancer, Clients und andere Systeme neu zu konfigurieren, um den Datenverkehr in die intakte Infrastruktur der neuen Zone umzuleiten.

Zonenwiederherstellung

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

Test auf Zonenfehler

Die Sicherungsplattform 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

Backup unterstützt Georedundanz und Failover über GRS und CRR.

Georedundanter Speicher und regionsübergreifende Wiederherstellung

Um regionale Redundanz für Ihre Sicherungsdaten zu erzielen, verwenden Sie Backup, um Ihre Sicherungen in eine Azure gekoppelte Region zu replizieren mithilfe von GRS. GRS schützt Ihre Sicherungen vor regionalen Ausfällen.

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

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

Wenn Sie GRS nicht konfigurieren und ein Ausfall in der Region des Tresors auftritt, können Sie möglicherweise 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 nach dem Auftreten eines Ausfalls in der primären Region zur Verfügung. Wenn Ihre Datenquelle CRR unterstützt, können Sie aus Wiederherstellungspunkten der sekundären Region wiederherstellen, selbst wenn in der primären Region kein Ausfall vorliegt. Mit CRR können Sie auch Übungen durchführen, um die Resilienz gegenüber regionalen Ausfällen zu bewerten. Wenn Sie CRR aktivieren, aktualisiert Microsoft Ihren Sicherungsspeicher von GRS auf einen georedundanten Speicher mit Lesezugriff (RA-GRS).

Anforderungen

• Regionale Unterstützung: GRS für Backup funktioniert nur innerhalb gepaarter Azure-Regionen.

• Nur neue Tresore: Sie müssen GRS auf Ihrem Tresor konfigurieren, bevor die erste Sicherung stattfindet.

Überlegungen

• CRR: Nachdem Sie CRR aktiviert haben, können Sicherungselemente bis zu 48 Stunden in der sekundären Region verfügbar sein.

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 interregionalen Bandbreitenraten berechnet. CRR wird zu einem anderen Preis berechnet, da Microsoft Ihren Tresorspeicher von GRS auf RA-GRS aktualisiert. Weitere Informationen finden Sie unter 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 Speicherredundanz konfigurieren. Nachdem Sie GRS ausgewählt haben, können Sie optional CRR im Tresor aktivieren. Die schritte, die Sie ausführen, hängen vom Tresortyp ab. Weitere Informationen finden Sie in den folgenden Artikeln:

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

• Konfigurieren von GRS und CRR für vorhandene Tresore: Bei Sicherungstresorn müssen Sie speicherredundanz konfigurieren, wenn Sie den Tresor erstellen.

  Für Recovery Services-Tresore müssen Sie Speicherredundanz konfigurieren, bevor Sie Workloads schützen. Nachdem eine Workload geschützt wurde, ist die Einstellung gesperrt, und Sie können sie nicht mehr ändern.

  Sie können CRR für vorhandene GRS-Tresore aktivieren. Nachdem Sie CRR aktiviert haben, können Sie ihn nicht deaktivieren.

Verhalten, wenn alle Regionen funktionsfähig sind

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

• Regionsübergreifender Betrieb: Sicherungen werden immer in der primären Region abgeschlossen, also der Region, in der Tresor und Datenquelle bereitgestellt sind.

• Regionsübergreifende Datenreplikation: Wenn Sie den Tresor für die Verwendung von GRS konfigurieren, werden Sicherungen zunächst mithilfe von LRS für die primäre Region zugesichert. Nach erfolgreichem Abschluss im primären Bereich werden Die Daten asynchron in die sekundäre Region repliziert. Die sekundäre Region verwendet LRS zum Speichern von Daten. Die Sicherungsdaten können bis zu 12 Stunden dauern, bis sie von der primären Region in die sekundäre Region repliziert werden.

Verhalten während eines Regionenausfalls

In diesem Abschnitt wird beschrieben, was zu erwarten ist, wenn Sie Tresore zum Einsatz von GRS konfigurieren und ein Ausfall in der primären Region auftritt.

• Erkennung und Reaktion: Für Datenquellen, die CRR unterstützen und wo CRR im Tresor aktiviert ist, können Sie jederzeit einen eigenen CRR mit der gekoppelten Region initiieren, einschließlich während eines Regionsausfalls oder eines Notfalls. Sie sind dafür verantwortlich, den Ausfall zu erkennen und Wiederherstellungsaktionen auszuführen, einschließlich des Wiederherstellens von Sicherungen in einer fehlerfreien Region.

  In allen anderen Szenarien stehen die in der sekundären Region replizierten Daten nur dann zur Wiederherstellung in der sekundären Region zur Verfügung, wenn Azure eine Katastrophe in der primären Region deklariert. Microsoft ist für die Deklarierung einer Katastrophe verantwortlich. 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. Microsoft deklariert in der Regel nur nach längerer Zeit eine Katastrophe.

• Notification: Microsoft benachrichtigt Sie nicht automatisch, wenn ein Bereich abfällt. Aber:

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

  • Sie können Azure Service Health verwenden, um den Gesamtstatus des Diensts zu verstehen, einschließlich aller Regionsfehler, und Sie können Service Health-Warnungen 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 erwarten Sie für einen Regionsausfall bis zu 36 Stunden Datenverlust, 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 fehlgeschlagenen Region sind möglicherweise erst verfügbar, wenn die Region wiederhergestellt wird, sodass die RTO nicht definiert ist.

  • Die Sicherung 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 CRR verwenden, ist der RTO für die Initiierung der Wiederherstellung von Backups, die bereits in die gekoppelte Region repliziert wurden, null. Wenn Sie CRR nicht verwenden, hängt die RTO davon ab, wie lange es dauert, bis Microsoft eine Katastrophe in der fehlgeschlagenen Region deklarieren.

• 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 für die Wiederherstellung Ihrer Sicherung in der Infrastruktur in der gekoppelten Region und für die Neukonfiguration von Lastenausgleichsmodulen, Clients und anderen Systemen verantwortlich, um Datenverkehr in eine gesunde Infrastruktur in der gekoppelten Region umzuleiten.

Region-Wiederherstellung

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

Test auf Regionsfehler

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

Resilienz beim Verlust von Sicherungsdaten

Sicherung bietet zwei wichtige Wiederherstellungsfeatures, um versehentliche oder böswillige Löschung Ihrer Sicherungsdaten zu verhindern:

• Mit vorläufigem Löschen können Sie gelöschte Objekte und Tresore während eines konfigurierbaren Aufbewahrungszeitraums wiederherstellen. Dieser Zeitraum beträgt standardmäßig 14 Tage, Sie können ihn jedoch bearbeiten. Stellen Sie sich weiches Löschen wie einen Papierkorb für Ihre Sicherungen und Tresore vor. Weitere Informationen finden Sie unter "Standardmäßig sicher mit vorläufigem Löschen für sicherung".

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

Service-Level-Vereinbarung

Der ServiceLevel-Vertrag (SLA) für Azure-Dienste beschreibt die erwartete Verfügbarkeit der einzelnen Dienste und die Bedingungen, die Ihre Lösung erfüllen muss, um diese Verfügbarkeitserwartungen zu erreichen. Weitere Informationen finden Sie unter SLAs für Online-Dienste.

Die SLA für die Sicherung deckt die Verfügbarkeit des Diensts für Sicherungs- und Wiederherstellungsvorgänge ab. Um von der SLA abgedeckt zu werden, müssen Sie mindestens einmal alle 30 Minuten fehlerhafte Sicherungs- oder Wiederherstellungsaufträge wiederholen.

Verwandte Inhalte

• Reliability in Azure
• Reliability in Azure Virtual Machines
• Reliability in Azure Disk Storage
• Reliability in Azure Site Recovery