Sichern von Dateien und Anwendungen in Azure Stack Hub

Stellen Sie sich eine Situation vor, in der Azure Stack Hub virtuelle Computer hostet, die Benutzerworkloads ausführen. Es ist erforderlich, die Dateien und Anwendungen der Workloads zu sichern und wiederherzustellen. In diesem Artikel zur Referenzarchitektur wird ein Ansatz beschrieben, der eine optimierte Lösung für Sicherungs- und Wiederherstellungsaktivitäten bereitstellt.

Aufbau

Laden Sie eine Visio-Datei dieser Architektur herunter.

Workflow

Die Cloudkomponenten umfassen die folgenden Dienste:

• Ein Azure-Abonnement, das alle in dieser Lösung enthaltenen Cloudressourcen hostet
• Ein Microsoft Entra-Mandant, der dem Azure-Abonnement zugeordnet ist. Er ermöglicht die Authentifizierung von Microsoft Entra-Sicherheitsprinzipalen, um den Zugriff auf Azure-Ressourcen zu autorisieren.
• Einen Azure Recovery Services-Tresor in der Azure-Region, die dem lokalen Rechenzentrum am nächsten ist, in dem die Azure Stack Hub-Bereitstellung gehostet wird.

Je nach den in diesem Artikel vorgestellten Kriterien könnten Cloudkomponenten auch die folgenden Dienste umfassen:

• Eine Azure ExpressRoute-Leitung, die das lokale Rechenzentrum und die Azure-Region verbindet, die den Azure Recovery Services-Tresor hostet. Die Leitung ist für Microsoft-Peering konfiguriert, um größere Sicherungsgrößen zu ermöglichen.

• Den Azure Import/Export-Dienst, um Offlinesicherungen von MABS zu Azure zu ermöglichen.

  Hinweis

  Seit August 2020 befindet sich die MABS-Offlinesicherung zu Azure, für die Azure Data Box verwendet wird, in der Vorschauphase.

Abhängig von der Nutzung des Azure Import/Export-Diensts für MABS-Offlinesicherung zu Azure könnte die Lösung auch über ein Azure Storage-Konto in derselben Azure-Region wie der Recovery Services-Tresor verfügen.

Die lokalen Cloudkomponenten umfassen die folgenden Dienste:

• Ein integriertes Azure Stack Hub-System im verbundenen Bereitstellungsmodell, in dem das aktuelle Update (2002 ab August 2020) ausgeführt wird und das sich im lokalen Rechenzentrum des Kunden befindet

• Ein unter Windows Server 2016 oder Windows Server 2019 ausgeführter virtueller Computer, der auf dem integrierten Azure Stack Hub-System gehostet wird und MABS v3 Update Release (UR) 1 ausführt

• Azure Stack Hub-VMs mit dem MABS-Schutz-Agent, der Sicherungen auf der und Wiederherstellungen von der MABS Azure Stack Hub-VM verwaltet. Der MABS-Schutz-Agent verfolgt Änderungen an geschützten Workloads und überträgt die Änderungen in den MABS-Datenspeicher. Der Schutz-Agent identifiziert auch Daten auf seinem lokalen Computer, die geschützt werden können, und spielt eine Rolle beim Wiederherstellungsprozess.

• Ein Microsoft Azure Recovery Services-Agent (MARS), der auf dem Server installiert ist, auf dem MABS ausgeführt wird. Der Agent integriert MABS und den Azure Recovery Services-Tresor.

  Hinweis

  Ein MARS-Agent wird auch als Azure Backup-Agent bezeichnet.

Komponenten

• Azure Stack Hub
• Microsoft Entra ID
• Azure-Speicherkonto
• Azure ExpressRoute

Alternativen

Die in diesem Artikel beschriebene empfohlene Lösung ist nicht die einzige Möglichkeit zum Bereitstellen von Sicherungs- und Wiederherstellungsfunktionen für Benutzerworkloads, die unter Azure Stack Hub ausgeführt werden. Kunden haben weitere Optionen, zu denen die folgenden gehören:

• Lokale Sicherung und Wiederherstellung mithilfe des im Windows Server-Betriebssystem enthaltenen Features Windows Server-Sicherung. Benutzer können anschließend lokale Sicherungen in einen längerfristigen Speicher kopieren. Dieser Ansatz unterstützt anwendungskonsistente Sicherungen, indem er sich auf Windows VSS-Anbieter stützt, erhöht jedoch die Nutzung des lokalen Speicherplatzes und den Aufwand für die Wartung der Sicherungen.
• Sicherung und Wiederherstellung mithilfe von Azure Backup mit dem lokal installierten MARS-Agent Dieser Ansatz minimiert die Nutzung von lokalem Speicherplatz und automatisiert das Hochladen von Sicherungen in cloudbasierten Speicher. Er unterstützt jedoch keine anwendungskonsistenten Sicherungen.
• Sicherung und Wiederherstellung mithilfe einer Sicherungslösung, die im selben Rechenzentrum, aber außerhalb von Azure Stack Hub installiert ist. Dieser Ansatz erleichtert Szenarien, die ein Bereitstellungsmodell ohne Verbindung mit Azure Stack Hub umfasst.
• Sicherung und Wiederherstellung auf Azure Stack Hub-Ebene unter Verwendung von Datenträgermomentaufnahmen. Dieser Ansatz erfordert, dass die zu sichernde VM angehalten wird, was bei unternehmenskritischen Workloads in der Regel keine praktikable Option darstellt, aber in einigen Szenarien akzeptabel sein kann.

Szenariodetails

Sicherung und Wiederherstellung sind wesentliche Bestandteile jeder umfassenden Strategie für Business Continuity & Disaster Recovery. Das Entwerfen und Implementieren eines konsistenten und zuverlässigen Sicherungskonzepts in einer Hybridumgebung ist eine Herausforderung, kann aber durch die Integration in Microsoft Azure-Dienste erheblich vereinfacht werden. Dies gilt nicht nur für die Workloads, die in der traditionellen lokalen Infrastruktur ausgeführt werden, sondern auch für diejenigen, die bei öffentlichen und privaten Drittanbietern von Clouds gehostet werden. Die Vorteile der Integration mit Azure-Diensten werden jedoch deutlich, wenn die Hybridumgebungen Azure Stack-Portfolioangebote umfassen, einschließlich Azure Stack Hub.

Obwohl eine der Hauptstärken von Azure Stack Hub die Unterstützung des PaaS-Modells (Platform-as-a-Service) ist, hilft es Kunden auch bei der Modernisierung ihrer bestehenden IaaS-Workloads (Infrastructure-as-a-Service). Solche Workloads können Dateifreigaben, Microsoft SQL Server-Datenbanken, Microsoft SharePoint-Farmen und Microsoft Exchange Server-Cluster umfassen. Die Migration zu virtuellen Computern, die auf hyperkonvergenten, hochgradig resilienten Clustern ausgeführt werden und deren Verwaltungs- und Programmiermodelle mit Microsoft Azure konsistent sind, führt zu einem minimalen Verwaltungs- und Wartungsaufwand.

Für die Implementierung von Sicherungen von Dateien und Anwendungen, die auf Azure Stack Hub-VMs ausgeführt werden, empfiehlt Microsoft einen Hybridansatz, der sich auf eine Kombination aus Cloud- und lokalen Komponenten stützt, um eine skalierbare, leistungsstarke, resiliente, sichere, einfach zu verwaltende und kosteneffiziente Sicherungslösung bereitzustellen. Die zentrale Komponente dieser Lösung ist Microsoft Azure Backup Server (MABS) v3, der Teil des Azure Backup-Angebots ist. MABS nutzt die Infrastruktur von Azure Stack Hub für Compute-, Netzwerk- und kurzfristige Speicherressourcen und den Azure-basierten Speicher als langfristigen Sicherungsspeicher. Durch diesen Ansatz wird die Notwendigkeit der Wartung physischer Sicherungsmedien wie Bänder auf ein Minimum reduziert bzw. eliminiert.

Kernfunktionalität

Die vorgeschlagene Lösung unterstützt die folgenden Funktionen auf Azure Stack Hub-VMs mit Windows Server 2019, 2016, 2012 R2, 2012, 2008 R2 SP1 (64-Bit mit Windows Management Framework 4.0), 2008 SP2 (64-Bit mit Windows Management Framework 4.0) und Windows 10 (64-Bit):

• Sicherung und Wiederherstellung von Volumes, Freigaben, Ordnern, Dateien und Systemstatus im NTFS- (New Technology File System) und ReFS-Format (Resilient File System).

• Sicherung und Wiederherstellung von Instanzen und deren Datenbanken von SQL Server 2019, 2017, 2016 (mit erforderlichen Service Packs [SPs]) und 2014 (mit erforderlichen SPs).

• Sicherung und Wiederherstellung von Exchange Server 2019- und Exchange Server 2016-Servern und -Datenbanken, einschließlich eigenständiger Server und Datenbanken in einer Datenbankverfügbarkeitsgruppe (DAG).

• Wiederherstellung einzelner Postfächer und Postfachdatenbanken in einer DAG.

• Sicherung und Wiederherstellung von SharePoint 2019- und SharePoint 2016-Farmen (mit den neuesten Service Packs) und Front-End-Webserverinhalten.

• Wiederherstellung von SharePoint 2019- und SharePoint 2016-Datenbanken, -Webanwendungen, -Dateien, -Listenelementen und -Suchkomponenten.

  Hinweis

  Wenn Sie Windows 10-Clientbetriebssysteme für Azure Stack Hub bereitstellen möchten, müssen Sie über eine benutzerspezifische Windows-Lizenzierung verfügen oder diese über einen QMTH (Qualified Multitenant Hoster) gekauft haben.

MABS implementiert das D2D2C-Sicherungsschema (Disk-to-Disk-to-Cloud), wobei die primäre Sicherung lokal auf dem Server gespeichert wird, auf dem die MABS-Installation gehostet wird. Lokale Sicherungen werden anschließend in einen Azure Site Recovery-Tresor kopiert. Der lokale Datenträger dient zur kurzfristigen Speicherung, während der Tresor als Langzeitspeicher fungiert.

Der Sicherungsprozess besteht aus den folgenden vier Stufen:

1. Sie installieren den MABS-Schutz-Agent auf einem zu schützenden Computer und fügen ihn zu einer Schutzgruppe hinzu.
2. Sie richten den Schutz für den Computer oder seine App ein, einschließlich der Sicherung auf lokalen MABS-Datenträgern für die kurzfristige Speicherung und der Sicherung in Azure für die langfristige Speicherung. Im Rahmen des Setups geben Sie den Sicherungszeitplan für beide Arten von Sicherungen an.
3. Die geschützte Workload wird gemäß dem von Ihnen angegebenen Zeitplan auf den lokalen MABS-Datenträgern gesichert.
4. Die lokale Sicherung, die auf MABS-Datenträgern gespeichert ist, wird durch den MARS-Agent, der auf dem MABS-Server ausgeführt wird, im Azure Recovery Services-Tresor gesichert.

Voraussetzungen

Eine Implementierung der empfohlenen Lösung hängt von der Erfüllung der folgenden Voraussetzungen ab:

• Zugriff auf ein Azure-Abonnement mit ausreichenden Berechtigungen für die Bereitstellung eines Azure Recovery Services-Tresors in der Azure-Region, die am nächsten zu einem lokalen Rechenzentrum liegt, in dem die Azure Stack Hub-Bereitstellung gehostet wird.

• Eine AD DS-Domäne (Active Directory Domain Services), auf die von einer Azure Stack Hub-VM zugegriffen werden kann, die eine MABS-Instanz hosten wird.

• Eine von Azure Stack Hub gehostete VM, die eine MABS-Instanz ausführt, die die unter Installieren von Azure Backup Server in Azure Stack aufgeführten Voraussetzungen erfüllt und eine ausgehende Konnektivität zu URLs aufweist, die in DPM/MABS-Netzwerkunterstützung aufgeführt sind.

  Hinweis

  Zusätzliche Überlegungen zu Speicherplatz und Leistung für MABS werden später in diesem Artikel ausführlicher beschrieben.

  Hinweis

  Zur Überprüfung, ob der virtuelle Computer (VM), der MABS hostet, Konnektivität mit dem Azure Backup-Dienst aufweist, können Sie das Cmdlet Get-DPMCloudConnection (im PowerShell-Modul des Azure Backup-Servers enthalten) verwenden.

  Hinweis

  MABS erfordert auch eine lokale Instanz von SQL Server. Ausführliche Informationen zu den SQL Server-Anforderungen finden Sie unter Installieren und Durchführen eines Upgrades für Azure Backup Server.

Datentypen

Aus der Sicht von MABS sind zwei Datentypen zu berücksichtigen:

• Dateidaten sind Daten, die sich typischerweise auf Dateiservern befinden (z. B. Microsoft Office-Dateien, Text- oder Mediendateien) und die als Flatfiles geschützt werden müssen.
• Anwendungsdaten sind Daten, die auf Anwendungsservern (z. B. Exchange-Speichergruppen, SQL Server-Datenbanken oder SharePoint-Farmen) vorhanden sind und für die MABS die entsprechenden Anwendungsanforderungen kennen muss.

Sicherungstypen

Unabhängig davon, ob es sich um den Schutz von Datei- oder Anwendungsdaten handelt, beginnt der Schutz mit der Erstellung eines Replikats der Datenquelle im lokalen Speicher einer MABS-Instanz. Das Replikat wird entsprechend den festgelegten Einstellungen in regelmäßigen Abständen synchronisiert oder aktualisiert. Die von MABS verwendete Methode zur Synchronisierung des Replikats richtet sich nach dem zu schützenden Datentyp. Wenn ein Replikat als inkonsistent erkannt wird, wird von MABS eine Konsistenzprüfung vorgenommen, wobei das Replikat blockweise mit der Datenquelle verglichen wird.

Bei einem Dateivolume oder einer Dateifreigabe auf einem Server verwendet der MABS-Schutz-Agent nach der ersten vollständigen Sicherung einen Volumefilter und ein Änderungsjournal, um festzustellen, welche Dateien sich geändert haben. Anschließend führt er einen Prüfsummenabgleich für diese Dateien durch, um nur die geänderten Blöcke zu synchronisieren. Während der Synchronisierung werden diese Änderungen an MABS übertragen und dann auf das Replikat angewandt, wobei das Replikat mit der Datenquelle synchronisiert wird.

Wenn ein Replikat mit dessen Datenquelle inkonsistent wird, gibt MABS eine Warnung mit der Angabe der betreffenden Computer und Datenquellen aus. Um das Problem zu beheben, können Sie das Replikat reparieren, indem Sie das Replikat einer Synchronisierung mit Konsistenzprüfung unterziehen. Während einer Konsistenzprüfung führt MABS eine nach Blöcken gestaffelte Prüfung aus, das Replikat repariert und dessen Konsistenz mit der Datenquelle wiederhergestellt. Sie können für Schutzgruppen tägliche Konsistenzprüfungen planen oder eine Konsistenzprüfung manuell anstoßen.

In regelmäßigen Abständen, die Sie konfigurieren können, erstellt MABS einen Wiederherstellungspunkt für die geschützte Datenquelle. Ein Wiederherstellungspunkt ist eine Version der Daten, die wiederhergestellt werden kann.

Bei Anwendungsdaten werden Änderungen an Volumeblöcken, die Anwendungsdateien zugeordnet sind und nach dem Erstellen des Replikats durch MABS vorgenommen wurden, vom Volumefilter nachverfolgt. Wie die Änderungen an den MABS-Server übertragen werden, richtet sich nach der Anwendung und der Synchronisierungsart. Der Vorgang mit der Bezeichnung Synchronisierung in der MABS-Administratorkonsole erfolgt analog zu einer inkrementellen Sicherung. Dabei wird unter Kombination mit dem Replikat eine transaktionskonsistente und akkurate Spiegelung der Anwendungsdaten erstellt.

Während der Synchronisierungsart Schnelle vollständige Sicherung in der MABS-Administratorkonsole wird eine vollständige Momentaufnahme vom Volumeschattenkopie-Dienst (VSS) erstellt, doch nur die geänderten Blöcke werden an den MABS-Server übertragen.

Bei jeder schnellen vollständigen Sicherung wird ein Wiederherstellungspunkt für Anwendungsdaten erstellt. Wenn die Anwendung inkrementelle Sicherungen unterstützt, wird bei jeder Synchronisierung ebenfalls ein Wiederherstellungspunkt erstellt. Der Synchronisierungsprozess ist anwendungsabhängig:

• Für Exchange-Daten wird von der Synchronisierung eine inkrementelle VSS-Momentaufnahme mithilfe von Exchange VSS Writer übertragen. Wiederherstellungspunkte werden für jede Synchronisierung und jede schnelle vollständige Sicherung erstellt.
• Von SQL Server-Datenbanken, die mithilfe des Protokollversands im Nur-Lese-Modus oder mithilfe des einfachen Wiederherstellungsmodells gesichert werden, wird keine inkrementelle Sicherung unterstützt. Wiederherstellungspunkte werden nur für jede schnelle vollständige Sicherung erstellt. Für alle anderen SQL Server-Datenbanken wird von der Synchronisierung eine Sicherung des Transaktionsprotokolls übertragen und für jede inkrementelle Synchronisierung und jede schnelle vollständige Sicherung werden Wiederherstellungspunkte erstellt. Das Transaktionsprotokoll ist ein serieller Datensatz aller Transaktionen, die seit der letzten Sicherung des Transaktionsprotokolls an der Datenbank ausgeführt wurden.
• SharePoint-Server unterstützen keine inkrementelle Sicherung. Wiederherstellungspunkte werden nur für jede schnelle vollständige Sicherung erstellt.

Inkrementelle Synchronisierungen erfordern weniger Zeit als die Durchführung einer schnellen vollständigen Sicherung. Jedoch nimmt die Zeit zur Datenwiederherstellung mit zunehmender Anzahl der Synchronisierungen zu. Das liegt daran, dass von MABS die letzte vollständige Sicherung und dann alle inkrementellen Synchronisierungen bis zu dem für die Wiederherstellung festgelegten Zeitpunkt wiederhergestellt und angewendet werden müssen.

Zur Ermöglichung einer schnellen Wiederherstellung werden in MABS regelmäßig schnelle vollständige Sicherungen ausgeführt, die das Replikat aktualisiert und die geänderten Blöcke einbezieht. Während der schnellen vollständigen Sicherung nimmt MABS eine Momentaufnahme des Replikats auf, bevor das Replikat mithilfe der geänderten Blöcke aktualisiert wird. Zur Durchführung häufigerer RPOs und zur Reduzierung des Datenverlustfensters führt MABS auch inkrementelle Synchronisierungen in der Zeit zwischen zwei schnellen vollständigen Sicherungen durch.

Analog zum Dateidatenschutz wird bei Inkonsistenz zwischen Replikat und Datenquelle von MABS eine Warnung mit Angabe des betreffenden Servers und der betreffenden Datenquelle ausgegeben. Um die Inkonsistenz zu beheben, können Sie das Replikat reparieren, indem Sie das Replikat einer Synchronisierung mit Konsistenzprüfung unterziehen. Während einer Konsistenzprüfung führt MABS eine nach Blöcken gestaffelte Prüfung des Replikats aus und repariert es und stellt dessen Konsistenz mit den Datenquellen wieder her. Sie können für Schutzgruppen tägliche Konsistenzprüfungen planen oder eine Konsistenzprüfung manuell anstoßen.

Schutzrichtlinien

Ein Computer oder seine Workload wird geschützt, wenn Sie die MABS-Schutz-Agent-Software auf dem Computer installieren und die Daten des Computers oder seiner Workload zu einer Schutzgruppe hinzufügen. Schutzgruppen werden verwendet, um den Schutz von Datenquellen auf Computern zu konfigurieren und zu verwalten. Eine Schutzgruppe ist eine Sammlung von Datenquellen, die dieselbe Konfiguration für den Schutz aufweisen. Die Schutzkonfiguration besteht aus den Einstellungen, die sich auf eine Schutzgruppe beziehen, z. B. der Schutzgruppenname, die Schutzrichtlinie, Speicherzuordnungen und die Replikaterstellungsmethode.

MABS speichert für jedes Mitglied einer Schutzgruppe ein separates Replikat im Speicherpool. Ein Mitglied einer Schutzgruppe kann Datenquellen wie die folgenden enthalten:

• Volume, Freigabe oder Ordner auf einem Dateiserver oder Servercluster
• Speichergruppe eines Exchange-Servers oder Serverclusters
• Datenbank einer Instanz von SQL Server oder Servercluster

Sie konfigurieren für jede Schutzgruppe eine Schutzrichtlinie, die auf den Wiederherstellungszielen für diese Schutzgruppe basiert. Wiederherstellungsziele stellen Datenschutzanforderungen dar, die den RTOs und RPOs Ihrer Organisation entsprechen. Innerhalb von MABS werden sie auf der Grundlage einer Kombination der folgenden Parameter definiert:

• Kurzfristige Beibehaltungsdauer Dadurch wird festgelegt, wie lange Sie gesicherte Daten im lokalen MABS-Speicher aufbewahren möchten.

• Synchronisierungs- und Wiederherstellungspunktfrequenzen Dies entspricht direkt der Datenverlusttoleranz, die wiederum die RPOs Ihrer Organisation widerspiegelt. Sie bestimmt auch, wie oft MABS seine lokalen Replikate mit geschützten Datenquellen synchronisieren soll, indem es deren Datenänderungen erfasst. Die Synchronisierungsfrequenz kann auf ein beliebiges Intervall zwischen 15 Minuten und 24 Stunden festgelegt werden. Sie können auch festlegen, dass die Synchronisierung direkt vor dem Erstellen eines Wiederherstellungspunkts erfolgt, statt nach einem bestimmten Zeitplan.

• Kurzfristiger Zeitplan für Wiederherstellungspunkte Damit wird festgelegt, wie viele Wiederherstellungspunkte im lokalen Speicher für die Schutzgruppe erstellt werden sollen. Für den Schutz von Dateien wählen Sie die Tage und Zeiten aus, zu denen Wiederherstellungspunkte erstellt werden sollen. Für den Schutz von Anwendungsdaten, die inkrementelle Sicherungen unterstützen, wird anhand der Synchronisierungsfrequenz der Zeitplan für Wiederherstellungspunkte festgelegt.

• Zeitplan für schnelle vollständige Sicherung Für Datenschutz von Anwendungen, die keine inkrementellen Sicherungen und schnelle vollständige Sicherungen unterstützen, ist dies der Zeitplan für die Wiederherstellungspunkte.

• Zeitplan für Onlinesicherung Dies bestimmt die Häufigkeit der Erstellung einer Kopie der lokalen Sicherungen im Azure Recovery Services-Tresor, der der lokalen MABS-Instanz zugeordnet ist. Sie können die Sicherung auf täglicher, wöchentlicher, monatlicher oder jährlicher Basis planen, mit einer maximal zulässigen Häufigkeit von zwei Sicherungen pro Tag. MABS erstellt automatisch einen Wiederherstellungspunkt für Onlinesicherungen unter Verwendung des neuesten lokalen Replikats, ohne neue Daten aus der geschützten Datenquelle zu übertragen.

  Hinweis

  Ein Recovery Services-Tresor unterstützt bis zu 9.999 Wiederherstellungspunkte.

• Onlineaufbewahrungsrichtlinie Diese gibt den Zeitraum an, in dem tägliche, wöchentliche, monatliche und jährliche Sicherungen im Azure Site Recovery-Tresor, der der lokalen MABS-Instanz zugeordnet ist, aufbewahrt werden.

  Hinweis

  Erstellen Sie einen neuen Wiederherstellungspunkt auf dem lokalen Datenträger, bevor Sie einen Onlinewiederherstellungspunkt erstellen, um den aktuellen Inhalt der Datenquelle online zu schützen.

  Hinweis

  Standardmäßig ist Azure Recovery Services-Tresor georedundant, d. h. jede in seinen Speicher kopierte Sicherung wird automatisch in eine Azure-Region repliziert, die Teil eines vordefinierten Regionspaars ist. Sie können die Replikationseinstellungen in „lokal redundant“ ändern, wenn dies für Ihre Anforderungen an die Resilienz ausreicht und wenn Sie die Speicherkosten minimieren möchten. Sie sollten jedoch in Betracht ziehen, die Standardeinstellung beizubehalten. Diese Option kann allerdings nicht geändert werden, wenn der Tresor geschützte Elemente enthält.

  Hinweis

  Eine Auflistung der Azure-Regionspaare finden Sie unter Business Continuity & Disaster Recovery (BCDR): Azure-Regionspaare.

Testen von Wiederherstellungen

Zusätzlich zu einer optimal konzipierten und implementierten Sicherungsstrategie ist es ebenso wichtig, den Wiederherstellungsvorgang für jede Art von geschütztem Workload zu definieren, zu dokumentieren und zu testen. Während MABS integrierte Konsistenzprüfungen erstellt, die automatisch die Integrität der Datensicherungen überprüfen, sollte das Testen von Wiederherstellungen Teil der routinemäßigen Betriebsvorgänge sein. Bei den Tests wird eine Wiederherstellung überprüft, indem der Zustand der wiederhergestellten Workloads untersucht wird. Die Testergebnisse sollten den Workloadbesitzern zur Verfügung stehen.

Im Allgemeinen stellt das Testen von Wiederherstellungen in der Regel eine Herausforderung dar, da es eine Umgebung erfordert, die der Umgebung, in der geschützte Workloads gehostet werden, sehr ähnlich ist. Azure Stack Hub mit seinen integrierten DevOps- und Infrastructure-as-Code-Funktionen vereinfacht die Bewältigung dieser Herausforderung erheblich.

Rollen und Zuständigkeiten

Die Planung und Implementierung der Sicherung und Wiederherstellung von Azure Stack Hub-basierten Workloads erfordert in der Regel die Interaktion zwischen zahlreichen Projektbeteiligten:

• Azure Stack Hub-Operatoren Azure Stack Hub-Operatoren verwalten die Azure Stack Hub-Infrastruktur, wobei sie sicherstellen, dass ausreichend Compute-, Speicher- und Netzwerkressourcen verfügbar sind, um eine umfassende Lösung für Sicherung und Wiederherstellung implementieren zu können, und diese Ressourcen für Mandanten verfügbar machen. Sie arbeiten außerdem mit Anwendungs- und Datenbesitzern zusammen, um mit ihnen die optimale Vorgehensweise zu ermitteln, wie deren Workloads auf Azure Stack Hub bereitgestellt werden können.
• Azure-Administratoren Azure-Administratoren verwalten die Azure-Ressourcen, die zum Implementieren von Hybridsicherungslösungen erforderlich sind.
• Microsoft Entra-Administrator*innen. Microsoft Entra-Administrator*innen verwalten Microsoft Entra-Ressourcen, einschließlich Benutzer- und Gruppenobjekten, die für das Bereitstellen, Konfigurieren und Verwalten von Azure-Ressourcen verwendet werden.
• IT-Mitarbeiter des Azure Stack Hub-Mandanten Diese Projektbeteiligten entwerfen, implementieren und verwalten MABS, einschließlich MABS-Sicherungen und -Wiederherstellungen.
• Azure Stack Hub-Benutzer Diese Benutzer stellen RPO- und RTO-Anforderungen bereit und übermitteln Anforderungen zum Sichern und Wiederherstellen von Daten und Anwendungen.

Überlegungen

Diese Überlegungen beruhen auf den Säulen des Azure Well-Architected Frameworks, d. h. einer Reihe von Grundsätzen, mit denen die Qualität von Workloads verbessert werden kann. Weitere Informationen finden Sie unter Microsoft Azure Well-Architected Framework.

Zuverlässigkeit

Zuverlässigkeit stellt sicher, dass Ihre Anwendung Ihre Verpflichtungen gegenüber den Kunden erfüllen kann. Weitere Informationen finden Sie in der Überblick über die Säule „Zuverlässigkeit“.

Azure Stack Hub ermöglicht durch die in seiner Infrastruktur begründete Resilienz eine erhöhte Workloadverfügbarkeit. Sie können die Verfügbarkeit weiter erhöhen, indem Sie Lösungen entwickeln und implementieren, die den Umfang des Workloadschutzes erweitern. Dies ist der hinzugefügte Wert, den MABS bereitstellt. Im Kontext der Ausführung von MABS unter Azure Stack Hub gibt es zwei Aspekte der Verfügbarkeit, die näher untersucht werden müssen:

• Verfügbarkeit von MABS und seinen Datenspeichern
• Verfügbarkeit der Funktion für die Zeitpunktwiederherstellung von MABS-geschützten Workloads

Sie müssen diese beiden Aspekte berücksichtigen, wenn Sie eine Sicherungsstrategie entwickeln, die auf RPOs (Recovery Point Objectives) und RTOs (Recovery Time Objectives) aufsetzt. RTO und RPO stellen die Kontinuitätsanforderungen dar, die durch Geschäftsfunktionen innerhalb einer Organisation vorgegeben sind. RPO bestimmt einen Zeitraum, der den maximal zulässigen Datenverlust aufgrund eines Vorfalls darstellt, der dazu führt, dass die Daten eine Zeitlang nicht verfügbar sind. RTO bestimmt die maximal zulässige Zeitdauer, die bis zur Wiederherstellung des Zugriffs auf Geschäftsfunktionen nach einem Vorfall verstreichen darf, der dazu führt, dass die Funktionen nicht verfügbar sind.

Die Verfügbarkeit von MABS und seinen Datenspeichern hängt von der Verfügbarkeit des virtuellen Computers ab, der die MABS-Installation und ihren lokalen und cloudbasierten Speicher hostet. Virtuelle Azure Stack Hub-Computer sind entwurfsbedingt hoch verfügbar. Im Falle eines MABS-Fehlers haben Sie die Möglichkeit, Azure Backup-geschützte Elemente von jedem anderen virtuellen Azure Stack Hub-Computer, der MABS hostet, wiederherzustellen. Beachten Sie jedoch, dass für einen Server, der MABS hostet, um Sicherungen wiederherzustellen, die mithilfe von MABS durchgeführt wurden, das auf einem anderen Server ausgeführt wird, beide Server im selben Azure Site Recovery-Tresor registriert sein müssen.

Die Funktion zur Zeitpunktwiederherstellung von MABS-geschützten Workloads hängt in hohem Maße von der Art der Daten, ihren Sicherungen und ihren Schutzrichtlinien ab. Um diese Abhängigkeiten zu verstehen, ist es notwendig, diese Konzepte genauer zu untersuchen.

Sicherheit

Sicherheit bietet Schutz vor vorsätzlichen Angriffen und dem Missbrauch Ihrer wertvollen Daten und Systeme. Weitere Informationen finden Sie unter Übersicht über die Säule „Sicherheit“.

Die Verwaltung von Benutzerdaten und Anwendungen in Hybridszenarien rechtfertigt zusätzliche Überlegungen hinsichtlich der Sicherheit. Diese Überlegungen können in die folgenden Kategorien unterteilt werden:

• Verschlüsseln der Sicherung
• Schutz des Azure Recovery Services-Tresors

MABS und Azure Backup erzwingen die Verschlüsselung von ruhenden Sicherungen und von Sicherungen während der Übertragung:

• Verschlüsselung ruhender Daten. Während der Installation von MABS stellt der Benutzer eine Passphrase bereit. Diese Passphrase wird dann verwendet, um alle Sicherungen zu verschlüsseln, bevor sie in einen Azure Recovery Services-Tresor hochgeladen werden. Die Entschlüsselung findet erst nach dem Herunterladen von Sicherungen aus diesem Tresor statt. Die Passphrase steht nur dem Benutzer, der sie erstellt hat, und dem lokal installierten MARS-Agent zur Verfügung. Es ist entscheidend, sicherzustellen, dass die Passphrase an einem sicheren Ort gespeichert wird, da sie als Autorisierungsmechanismus dient, wenn cloudbasierte Wiederherstellungen auf einem anderen MABS-Server als dem, auf dem die Sicherungen durchgeführt wurden, ausgeführt werden.
• Verschlüsseln während der Übertragung MABS v3 beruht auf dem TLS-Protokoll (Transport Layer Security), Version 1.2, um seine Verbindungen mit Azure zu schützen.

Der Azure Recovery Services Tresor bietet Mechanismen zur weiteren Sicherung von Onlinesicherungen, einschließlich:

• Rollenbasierte Zugriffssteuerung in Azure (Azure Role-Based Access Control, Azure RBAC). Die Azure RBAC ermöglicht die Delegierung und Trennung von Zuständigkeiten gemäß dem Prinzip der geringste Rechte. Es gibt drei Azure Backup-bezogene, integrierte Rollen, die den Zugriff auf Verwaltungsvorgänge für Sicherungen einschränken:
  • Mitwirkender für Sicherungen Bietet Zugriff zum Erstellen und Verwalten von Sicherungen, mit Ausnahme des Löschens des Recovery Services-Tresors und des Delegierens des Zugriffs an andere.
  • Sicherungsoperator Bietet einen Zugriff, der dem des Mitwirkenden an der Sicherung entspricht, mit Ausnahme des Entfernens von Sicherungen und dem Verwalten von Sicherungsrichtlinien.
  • Sicherungsleser Bietet Zugriff zur Überwachung von Sicherungsverwaltungsvorgängen.
• Azure-Ressourcensperren Sie können Schreibschutz- und Löschsperren für einen Azure Site Recovery-Tresor erstellen und zuweisen, um das Risiko zu mindern, dass der Tresor versehentlich geändert oder gelöscht wird.
• Vorläufiges Löschen. Das vorläufige Löschen hilft dabei, Tresor- und Sicherungsdaten vor versehentlichen oder böswilligen Löschvorgängen zu schützen. Beim vorläufigen Löschen werden, wenn ein Benutzer ein Sicherungselement löscht, die entsprechenden Daten 14 Tage lang aufbewahrt, sodass sie während dieses Zeitraums ohne Datenverlust wiederhergestellt werden können. Für die 14 Tage der Aufbewahrung von Sicherungsdaten mit dem Status „Vorläufiges Löschen“ fallen keine Kosten an. Vorläufiges Löschen ist standardmäßig aktiviert.
• Schutz von sicherheitsrelevanten Vorgängen. Der Azure Recovery Services-Tresor implementiert automatisch eine zusätzliche Ebene der Authentifizierung, wenn ein sicherheitsrelevanter Vorgang wie die Änderung einer Passphrase versucht wird. Diese zusätzliche Überprüfung hilft sicherzustellen, dass nur autorisierte Benutzer diese Vorgänge durchführen.
• Überwachung verdächtiger Aktivitäten und Ausgabe von Warnungen Azure Backup bietet integrierte Überwachung von und Warnungen zu sicherheitsrelevanten Ereignissen, die Azure Backup-Vorgänge betreffen. Sicherungsberichte erleichtern die Nachverfolgung der Nutzung, die Überwachung von Sicherungen und Wiederherstellungen sowie die Identifizierung wichtiger Sicherungstrends.

Kostenoptimierung

Bei der Kostenoptimierung geht es um die Suche nach Möglichkeiten, unnötige Ausgaben zu reduzieren und die Betriebseffizienz zu verbessern. Weitere Informationen finden Sie unter Übersicht über die Säule „Kostenoptimierung“.

Denken Sie bei der Betrachtung der Kosten der in diesem Artikel beschriebenen Sicherungslösung daran, sowohl lokale als auch cloudbasierte Komponenten zu berücksichtigen. Die Preise für lokale Komponenten werden durch das Azure Stack Hub-Preismodell bestimmt. Wie bei Azure gibt es für Azure Stack Hub eine Vereinbarung zur nutzungsbasierten Abrechnung, die über Enterprise Agreements und das Cloud Solution Provider-Programm verfügbar ist. Diese Vereinbarung umfasst einen monatlichen Preis pro Windows Server-VM. Wenn Sie vorhandene Windows Server-Lizenzen nutzen können, können Sie die Kosten erheblich auf den Preis einer Basis-VM verringern. Obwohl MABS auf SQL Server als Datenspeicher beruht, fallen für den Betrieb dieser SQL Server-Instanz keine Lizenzkosten an, wenn sie ausschließlich für MABS verwendet wird.

Für die Nutzung der folgenden Ressourcen fallen Azure-bezogene Gebühren an:

• Azure Backup. Die Preise für Azure Backup werden weitgehend durch die Anzahl der geschützten Workloads und die Größe der Datensicherungen (vor Komprimierung und Verschlüsselung) bestimmt. Die Kosten werden auch durch die Wahl zwischen lokal redundanter Speicherung (LRS) und georedundanter Speicherung (GRS) für die Replikation der Tresorinhalte von Azure Recovery Services beeinflusst. Weitere Details finden Sie unter Preise für Azure Backup.
• Azure ExpressRoute Die Preise für Azure ExpressRoute basieren auf einem von zwei Modellen:
  • Datenflatrate: Dies ist eine monatliche Gebühr, die alle Übertragungen von eingehenden und ausgehenden Daten umfasst.
  • Datentaktung: Dies ist eine monatliche Gebühr, bei der alle Übertragungen eingehender Daten kostenlos sind und Übertragungen ausgehender Daten pro Gigabyte (GB) abgerechnet werden.
• Azure Import/Export Die Kosten für Azure Import/Export umfassen eine Pauschalgebühr pro Gerät für das Gerätehandling.
• Azure Storage Bei Verwendung von Azure Import/Export gelten die standardmäßigen Azure Storage-Preise und -Transaktionsgebühren.

Ohne ExpressRoute müssen Sie für Sicherungen und Wiederherstellungen möglicherweise mit einer erhöhten Bandbreitennutzung Ihrer Internetverbindungen rechnen. Die Kosten hängen von zahlreichen Faktoren ab, einschließlich des geografischen Gebiets, der aktuellen Bandbreitennutzung und dem Internetdienstanbieter.

Optimaler Betrieb

Die Säule „Optimaler Betrieb“ deckt die Betriebsprozesse ab, die für die Bereitstellung einer Anwendung und deren Ausführung in der Produktion sorgen. Weitere Informationen finden Sie unter Übersicht über die Säule „Optimaler Betrieb“.

Verwaltbarkeit

Zu den Hauptfaktoren, die Ihre Sicherungs- und Wiederherstellungsstrategie beeinflussen, zählen die Konfiguration von Schutzgruppen sowie die Kriterien, auf deren Grundlage Sie entscheiden, welche geschützten Workloads zu denselben geschützten Gruppen gehören sollten. Wie bereits zuvor in diesem Artikel beschrieben, ist eine Schutzgruppe eine Sammlung von Datenquellen wie Volumes, Freigaben oder Anwendungsdatenspeichern, die gemeinsame Einstellungen für Sicherung und Wiederherstellung aufweisen. Wenn Sie eine Schutzgruppe definieren, müssen Sie Folgendes angeben:

• Datenquellen, z. B. Server und Workloads, die Sie schützen möchten
• Sicherungsspeicher, einschließlich kurz- und langfristiger Schutzeinstellungen.
• Wiederherstellungspunkte, d. h. Zeitpunkte, von denen gesicherte Daten wiederhergestellt werden können.
• Zugeordneter Speicherplatz, d. h. die Menge an Speicherplatz im Speicherpool, der für Sicherungen bereitgestellt wird
• Erstreplikation, d. h. die Methode, die für die erstmalige Sicherung von Datenquellen verwendet wird. Die Methode kann eine Onlineübertragung (über ein Netzwerk) oder eine Offlineübertragung (z. B. über den Azure Import/Export-Dienst) sein.
• Die Konsistenzprüfungsmethode, d. h. die Methode zum Überprüfen der Integrität von Datensicherungen.

Die folgenden Methoden werden häufig verwendet, um zu entscheiden, welche geschützten Workloads zu denselben geschützten Gruppen gehören sollten:

• Nach Computer Diese Methode fasst alle Datenquellen für einen Computer in derselben Schutzgruppe zusammen.
• Nach Workload Mit dieser Methode werden Dateien und die einzelnen Anwendungsdatentypen in verschiedene Schutzgruppen unterteilt. Die Wiederherstellung eines Servers, der mehrere Workloads hostet, kann jedoch mehrere Wiederherstellungen von verschiedenen Schutzgruppen erfordern.
• Nach RPO und RTO Diese Methode gruppiert Datenquellen mit ähnlichen RPOs. Sie steuern das RPO, indem Sie die Synchronisierungsfrequenz für die Schutzgruppe festlegen, die das Ausmaß des potenziellen Datenverlusts (gemessen in Zeiteinheiten) während unerwarteter Ausfälle bestimmt. In dem in diesem Artikel beschriebenen Szenario steuern Sie das RTO, indem Sie die Aufbewahrungsdauer innerhalb des kurzfristigen Speichers festlegen. Dadurch wird der Zeitraum bestimmt, in dem Sicherungen aus dem lokalen kurzfristigen Speicher und nicht aus dem cloudbasierten langfristigen Speicher wiederhergestellt werden können. Die Sicherung aus dem lokalen kurzfristigen Speicher führt zu einer schnelleren Wiederherstellung.
• Nach Dateneigenschaften Diese Methode berücksichtigt die Häufigkeit von Datenänderungen, die Wachstumsrate der Daten oder ihre Speicheranforderungen als Kriterien für Gruppierungen.

Verwenden Sie bei der Benennung von Schutzgruppen eindeutige, aussagekräftige Namen. Ein Name kann aus einer beliebigen Kombination von alphanumerischen Zeichen und Leerzeichen bestehen und bis zu 64 Zeichen lang sein.

Wenn Sie eine Schutzgruppe erstellen, wählen Sie eine Methode für die Erstellung des ersten Replikats aus. Bei der ersten Replikation werden alle zum Schutz ausgewählten Daten auf den Server kopiert, auf dem MABS gehostet wird, und dann in den Azure Site Recovery-Tresor kopiert. Beide Kopien werden auf Konsistenz überprüft. MABS kann Replikate automatisch über das Netzwerk erstellen. Sie können Replikate aber auch manuell erstellen, indem Sie Daten offline sichern, übertragen und wiederherstellen.

Informationen zum Auswählen der Replikaterstellungsmethode finden Sie unter Erste Replikation über das Netzwerk. Der Artikel enthält eine Tabelle mit Schätzwerten zur Dauer einer automatischen Replikaterstellung durch MABS über das Netzwerk für unterschiedliche Datengrößen und Netzwerkgeschwindigkeiten.

Der Offlineseedingprozess unterstützt die Verwendung des Azure Import/Export-Diensts, der Daten mithilfe von SATA-Datenträgern an ein Azure Storage-Konto übertragen kann. Diese Funktion kann verwendet werden, wenn die Onlinesicherung aufgrund der Menge der Sicherungsdaten oder der Geschwindigkeit der Netzwerkverbindung mit Azure zu langsam ist.

Der Offelineseedingworkflow umfasst die folgenden Schritte:

1. Sie kopieren die anfänglichen Sicherungsdaten mit dem AzureOfflineBackupDiskPrep-Tool auf einen oder mehrere SATA-Datenträger.
2. Das Tool generiert automatisch einen Azure-Importauftrag und eine Microsoft Entra-App im Abonnement, das das Azure Storage-Zielkonto und den Azure Recovery Services-Tresor hostet. Die App ermöglicht Azure Backup einen sicheren und bereichsbezogenen Zugriff auf den Azure-Importdienst, der für den Offlineseedingvorgang erforderlich ist.
3. Sie senden die Datenträger an das Azure-Rechenzentrum, in dem das Azure Storage-Zielkonto gehostet wird.
4. Die Mitarbeiter des Azure-Rechenzentrums kopieren Daten von den Datenträgern in das Azure Storage-Konto.
5. Der Workflow löst eine Kopie vom Azure Storage-Konto in den Azure Recovery Services-Tresor aus.

DevOps

Während Sicherung und Wiederherstellung als Teil der IT-Abläufe betrachtet werden, gibt es einige DevOps-spezifische Überlegungen, die es wert sind, in eine umfassende Sicherungsstrategie einbezogen zu werden. Azure Stack Hub erleichtert die automatisierte Bereitstellung verschiedener Workloads, einschließlich VM-basierter Anwendungen und Dienste. Sie können diese Funktion nutzen, um die Bereitstellung von MABS auf Azure Stack Hub-VMs zu optimieren, was die anfängliche Einrichtung in Szenarien mit mehreren Mandanten vereinfacht. Durch die Kombination von Azure Resource Manager-Vorlagen, VM-Erweiterungen und dem DPM PowerShell-Modul ist es möglich, die Konfiguration von MABS einschließlich der Einrichtung seiner Schutzgruppen, Aufbewahrungseinstellungen und Sicherungszeitpläne zu automatisieren. Im Einklang mit den bewährten Methoden von DevOps sollten Sie Vorlagen und Skripts in einer Quellcodeverwaltung speichern und ihre Bereitstellung mithilfe von Pipelines konfigurieren. Diese Methoden tragen dazu bei, die Wiederherstellungszeit in Fällen zu minimieren, in denen die für die Wiederherstellung von Datei- und Anwendungsdaten erforderliche Infrastruktur neu erstellt werden muss.

Effiziente Leistung

Leistungseffizienz ist die Fähigkeit Ihrer Workload, auf effiziente Weise eine den Anforderungen der Benutzer entsprechende Skalierung auszuführen. Weitere Informationen finden Sie unter Übersicht über die Säule „Leistungseffizienz“.

Wenn Sie planen, MABS in Azure Stack Hub bereitzustellen, müssen Sie die Menge an Verarbeitungs-, Speicher- und Netzwerkressourcen berücksichtigen, die den VMs, die die Bereitstellung hosten, zugewiesen werden. Microsoft empfiehlt die Zuweisung einer CPU mit 2,33 Gigahertz (GHz) und vier Kernen, um den MABS-Verarbeitungsanforderungen zu entsprechen, sowie mit etwa 10 GB Speicherplatz auf dem Datenträger für die Binärdateien der Installation. Andere Speicheranforderungen können wie folgt kategorisiert werden:

• Speicherplatz für Sicherungen. Die allgemeine Empfehlung für den Speicherplatz für Sicherungen ist die Zuweisung eines Speicherpools, der etwa der 1,5-fachen Größe aller zu sichernden Daten entspricht. Nachdem die Datenträger an die VM angefügt sind, wird die Verwaltung von Volumes und Speicherplatz von MABS übernommen. Die Anzahl der Datenträger, die Sie an eine VM anfügen können, hängt von ihrer Größe ab.

  Hinweis

  Sie sollten Sicherungen nicht länger als fünf Tage lokal speichern. Sicherungen, die älter als fünf Tage sind, sollten in den Azure Site Recovery-Tresor ausgelagert werden.

• Speicherplatz für den Cachespeicherort des MARS-Agents. Erwägen Sie die Verwendung von Laufwerk C auf dem virtuellen Computer, der die MABS-Installation hostet.

• Speicherplatz für den lokalen Stagingbereich bei Wiederherstellungen. Erwägen Sie die Verwendung des temporären Laufwerks D auf dem virtuellen Computer, der die MABS-Installation hostet.

Verwenden Sie zur Bereitstellung von Speicher für den virtuellen Computer, der die MABS-Installation hostet, verwaltete Datenträger mit der Premium-Leistungsstufe. Die erwarteten Leistungsmerkmale sind 2.300 E/A-Vorgänge pro Sekunde (IOPS) und 145 MB/Sekunde pro Datenträger. Im Gegensatz zu Azure gibt es keine Leistungsgarantien für Azure Stack Hub.

Um eine genauere Schätzung des für Azure Stack Hub-basierte Workloadsicherungen erforderlichen Speicherplatzes zu erhalten, sollten Sie den Rechner für die Azure Stack-VM-Größe für MABS verwenden, der unter Microsoft Downloads erhältlich ist. Der Rechner ist als Microsoft Excel-Arbeitsmappe mit Makros implementiert, die auf der Grundlage einer Reihe von Parametern, die Sie angeben, Informationen zur optimalen Dimensionierung von Azure Stack Hub ableiten. Diese Parameter umfassen:

• Quelldetails mit einer Liste der zu schützenden VMs, die Folgendes für die einzelnen VMs umfasst:
  • Die Größe der geschützten Daten
  • Workloadtyp (Windows Server, SharePoint oder SQL Server)
• Datenaufbewahrungszeitraum, in Tagen

Jeder Workloadtyp ist standardmäßig mit einer vordefinierten täglichen Änderungsrate (oder Datenänderung) verbunden. Sie können diese Werte anpassen, wenn sie nicht die Nutzungsmuster in Ihrer Umgebung widerspiegeln.

Der Rechner für die Azure Stack-VM-Größe für MABS verwendet die von Ihnen angegebenen Informationen für Folgendes:

• Eine geschätzte Größe der Azure Stack Hub-VM, die die Installation von MABS hostet
• Eine geschätzte Menge an MABS-Speicherplatz, der für das Hosting gesicherter Daten erforderlich ist
• Eine Gesamtzahl von Datenträgern mit jeweils 1 Terabyte (TB).
• Die für die MABS-Nutzung verfügbare IOPS-Rate
• Geschätzte Dauer der Fertigstellung der ersten Sicherung. Die Schätzung basiert auf der Gesamtgröße der geschützten Daten und den für die MABS-Nutzung verfügbaren IOPS.
• Geschätzte Dauer der Fertigstellung täglicher Sicherungen. Die Schätzung basiert auf der täglichen Änderungsrate und den für die MABS-Nutzung verfügbaren IOPS.

Wenn Sie eine Schutzgruppe mithilfe der grafischen MABS-Benutzeroberfläche erstellen, berechnet MABS beim Hinzufügen einer Datenquelle zu einer Schutzgruppe die Zuweisung des lokalen Speicherplatzes auf der Grundlage der von Ihnen angegebenen kurzfristigen Wiederherstellungsziele. Sie können dann entscheiden, wie viel Speicherplatz im Speicherpool für Replikate und Wiederherstellungspunkte für jede Datenquelle in der Gruppe zugewiesen werden soll. Sie müssen sicherstellen, dass auf lokalen Datenträgern geschützter Server genügend Speicherplatz für das Änderungsjournal vorhanden ist. In MABS werden die Speicherplatzzuordnungen für die Mitglieder der Schutzgruppe bereitgestellt. Details zu den standardmäßigen Speicherplatzzuweisungen für verschiedene MABS-Komponenten finden Sie in der Dokumentation zur Bereitstellung von Schutzgruppen.

Erwägen Sie die Verwendung der standardmäßigen Speicherplatzzuweisungen, es sei denn, Sie wissen, dass diese nicht Ihren Anforderungen entsprechen. Ein Überschreiben der Standardzuordnungen kann dazu führen, dass zu viel oder zu wenig Speicherplatz zugeordnet wird. Wenn für die Wiederherstellungspunkte zu wenig Speicherplatz zugeordnet wird, können von MABS u. U. nicht ausreichend Wiederherstellungspunkte gespeichert werden, um die gewünschte Beibehaltungsdauer einzuhalten. Durch Zuordnung von zu viel Speicherplatz wird Festplattenkapazität verschwendet. Wenn Sie nach dem Erstellen einer Schutzgruppe zu wenig Platz für eine Datenquelle zugewiesen haben, können Sie die Zuweisungen für die Volumes der Replikate und Wiederherstellungspunkte für jede Datenquelle erhöhen. Wenn Sie der Schutzgruppe zu viel Speicherplatz zugewiesen haben, können Sie die Datenquelle aus der Schutzgruppe entfernen und das Replikat löschen. Fügen Sie dann die Datenquelle der Schutzgruppe mit kleineren Zuteilungen hinzu.

Wenn Sie nach der Bereitstellung die geschätzte Größe der Azure Stack Hub-VMs, die MABS hosten, anpassen müssen, um Änderungen der Verarbeitungs- oder Speicheranforderungen zu berücksichtigen, haben Sie drei Optionen:

• Implementieren von vertikaler Skalierung. Dies setzt die Änderung der Menge und des Typs von Prozessor, Arbeitsspeicher und Datenträgerressourcen der Azure Stack Hub-VMs voraus, die MABS hosten.
• Implementieren von horizontaler Skalierung. Dies erfordert das Bereitstellen oder das Aufheben der Bereitstellung von Azure Stack Hub-VMs mit installiertem MABS, um den Verarbeitungsanforderungen geschützter Workloads gerecht zu werden.
• Ändern der Schutzrichtlinien. Dies erfordert das Ändern von Parametern der Schutzrichtlinien, einschließlich des Aufbewahrungszeitraums, des Zeitplans für den Wiederherstellungspunkt und des Zeitplans für die schnelle vollständige Sicherung.

Wenn Sie sich für ein automatisches Wachstum der Volumes entscheiden, dann berücksichtigt MABS das erhöhte Sicherungsvolumen, wenn die Produktionsdaten zunehmen. Andernfalls begrenzt MABS den Sicherungsspeicher auf die Größe der Datenquellen in der Schutzgruppe.

Es gibt zwei Hauptoptionen zur Anpassung der verfügbaren Bandbreite:

• Erhöhen Sie die VM-Größe. Bei Azure Stack Hub-VMs bestimmt die Größe der maximale Netzwerkbandbreite. Es gibt jedoch keine Garantien für die Bandbreite. Stattdessen können VMs die verfügbare Bandbreite bis zu dem Grenzwert nutzen, der durch ihre Größe bestimmt ist.
• Erhöhung des Durchsatzes von Uplinkswitches. Azure Stack Hub-Systeme unterstützen eine Reihe von Hardwareswitches, die mehrere Uplinkgeschwindigkeiten bieten. Jeder Azure Stack Hub-Clusterknoten hat zur Fehlertoleranz zwei Uplinks zur Oberseite von Rackswitches. Das System weist die Hälfte der Uplinkkapazität für kritische Infrastrukturen zu, der Rest ist gemeinsam genutzte Kapazität für Azure Stack-Dienste und den gesamten Benutzerdatenverkehr. Für Systeme, die mit höheren Geschwindigkeiten bereitgestellt werden, ist mehr Bandbreite für den Sicherungsdatenverkehr verfügbar.

Obwohl es möglich ist, den Netzwerkdatenverkehr dadurch zu trennen, dass einem Server ein zweiter Netzwerkadapter zugeordnet wird, wird für den gesamten Datenverkehr von Azure Stack Hub-VMs ins Internet derselbe Uplink verwendet. Ein zweiter virtueller Netzwerkadapter führt nicht dazu, dass Datenverkehr auf physischer Transportebene getrennt wird.

Um größere Sicherungen zu verarbeiten, könnten Sie in Erwägung ziehen, Azure ExpressRoute mit Microsoft-Peering für die Verbindung zwischen virtuellen Azure Stack Hub-Netzwerken und dem Azure Recovery Services-Tresor zu nutzen. Azure ExpressRoute erweitert lokale Netzwerke über eine von einem Konnektivitätsanbieter bereitgestellte private Verbindung in die Microsoft-Cloud. Sie können ExpressRoute-Leitungen für eine große Vielzahl an Bandbreiten (von 50 MBit/s bis 10 GBit/s) erwerben.

Zusammenfassung

Azure Stack Hub ein einzigartiges Angebot, das sich in vielen Aspekten von anderen Virtualisierungsplattformen unterscheidet. Daher sind spezielle Überlegungen hinsichtlich der Geschäftskontinuitätsstrategien für Workloads gerechtfertigt, die auf seinen VMs ausgeführt werden. Durch die Verwendung von Azure-Diensten wird die Entwurfs- und Implementierungsstrategie vereinfacht. In diesem Artikel haben wir die Verwendung von MABS zur Sicherung von Datei- und Anwendungsdaten auf Azure Stack Hub-VMs im verbundenen Bereitstellungsmodell untersucht. Diese Vorgehensweise ermöglicht es Kunden, von der Resilienz und Verwaltbarkeit von Azure Stack Hub und von der Hyperskalierung (Hyperscale) und globalen Präsenz der Azure-Cloud zu profitieren.

Die hier beschriebene Sicherungslösung konzentriert sich ausschließlich auf Datei- und Anwendungsdaten auf Azure Stack Hub-VMs. Dies ist nur ein Teil einer umfassenden Geschäftskontinuitätsstrategie, die verschiedene andere Szenarien berücksichtigen sollte, die sich auf die Verfügbarkeit von Workloads auswirken. Einige Beispiele: Lokale Hardware- und Softwarefehler, Systemausfälle, katastrophale Vorfälle und umfangreiche Notfälle.

Nächste Schritte

• Schrittanleitungen: Sichern von Speicherkonten in Azure Stack
• Schrittanleitungen: Sichern von virtuellen Computern in Azure Stack Hub mithilfe von Commvault
• Sichern von Cloudworkloads und lokalen Workloads in der Cloud
• Installieren von Azure Backup Server
• Sichern von Dateien und Anwendungen in Azure Stack
• Sichern einer SharePoint-Farm in Azure Stack
• Sichern einer SQL Server-Instanz in Azure Stack

Zugehörige Ressourcen

Verwandte Hybridleitfäden:

• Entwurf einer Hybridarchitektur
• Azure-Hybridoptionen
• Überlegungen zum Entwurf von Hybrid-Apps
• Bereitstellen einer Hybrid-App mit lokalen Daten mit cloudübergreifender Skalierung

Verwandte Architekturen:

• Notfallwiederherstellung für Azure Stack Hub-VMs
• Sichern lokaler Anwendungen und Daten in der Cloud