Umgebungsspezifischer Leitfaden für die Notfallwiederherstellung

Dieses Dokument enthält einen umgebungsspezifischen Leitfaden für die Wiederherstellung Ihrer Fabric-Daten im Falle eines regionalen Notfalls.

Beispielszenario

Viele Anleitungsabschnitte in diesem Dokument verwenden das folgende Beispielszenario für Erläuterungen und Illustrationen. Hier können Sie bei Bedarf noch einmal Informationen zu diesem Szenario nachlesen.

Angenommen, in der Region A mit dem Arbeitsbereich W1 gibt es die Kapazität C1. Wenn Sie für die Kapazität C1 die Notfallwiederherstellung aktiviert haben, werden OneLake-Daten in einer Sicherung in der Region B repliziert. Im Falle von Unterbrechungen in der Region A wird für den Fabric-Dienst in C1 ein Failover auf die Region B ausgeführt.

Das Szenario wird in der folgenden Abbildung veranschaulicht. Das Feld auf der linken Seite zeigt den unterbrochenen Bereich. Das Feld in der Mitte stellt die weitere Verfügbarkeit der Daten nach dem Failover dar, und das Feld auf der rechten Seite zeigt die vollständig abgedeckte Situation, nachdem der Kunde aktiv geworden ist, um seine Dienste vollständig wiederherzustellen.

So sieht der allgemeine Wiederherstellungsplan aus:

1. Erstellen Sie eine neue Fabric-Kapazität (C2) in einer neuen Region.

2. Erstellen Sie in C2 einen neuen Arbeitsbereich (W2), der die entsprechenden Elemente mit den gleichen Namen wie in C1.W1 enthält.

3. Kopieren Sie Daten aus der unterbrochenen Kapazität bzw. aus dem unterbrochenen Arbeitsbereich (C1.W1) in C2.W2.

4. Befolgen Sie die speziellen Anweisungen für die jeweilige Komponente, um die vollständige Funktion der Elemente wiederherzustellen.

Bei diesem Wiederherstellungsplan wird davon ausgegangen, dass die Mandanten-Heimregion weiterhin betriebsbereit bleibt. Wenn die Mandanten-Heimregion einen Ausfall aufweist, sind die in diesem Dokument beschriebenen Schritte von der Wiederherstellung abhängig, die zuerst von Microsoft initiiert und abgeschlossen werden muss.

Umgebungsspezifische Wiederherstellungspläne

In den folgenden Abschnitten finden Sie schrittweise Anleitungen für jede Fabric-Umgebung, um Kunden bei der Wiederherstellung zu unterstützen.

Datentechnik

Dieser Leitfaden führt Sie durch die Wiederherstellungsverfahren für die Datentechnikumgebung. Hier werden Lakehouses, Notebooks und Spark-Auftragsdefinitionen behandelt.

Lakehouse

Lakehouses aus der ursprünglichen Region können für Kunden nicht wieder verfügbar gemacht werden. Um ein Lakehouse wiederherzustellen, können Kunden es im Arbeitsbereich C2.W2 neu erstellen. Für die Wiederherstellung von Lakehouses gibt es zwei empfohlene Ansätze:

Ansatz 1: Verwenden eines benutzerdefinierten Skripts zum Kopieren von Delta-Tabellen und Dateien des Lakehouse

Kunden können Lakehouses mithilfe eines benutzerdefinierten Scala-Skripts neu erstellen.

1. Erstellen Sie das Lakehouse (z. B. LH1) im neu erstellten Arbeitsbereich C2.W2.

2. Erstellen Sie im Arbeitsbereich C2.W2 ein neues Notebook.

3. Informationen zum Wiederherstellen der Tabellen und Dateien aus dem ursprünglichen Lakehouse finden Sie in den Daten mit OneLake-Pfaden wie z. B. Abfss (siehe Herstellen einer Verbindung mit Microsoft OneLake). Sie können das folgende Codebeispiel (siehe Einführung in Microsoft Spark Utilities) im Notizbuch verwenden, um die ABFS-Pfade von Dateien und Tabellen aus dem ursprünglichen Lakehouse abzurufen. (Ersetzen Sie C1.W1 durch den tatsächlichen Arbeitsbereichsnamen.)

   mssparkutils.fs.ls('abfs[s]://<C1.W1>@onelake.dfs.fabric.microsoft.com/<item>.<itemtype>/<Tables>/<fileName>')
   

4. Verwenden Sie das folgende Codebeispiel, um Tabellen und Dateien in das neu erstellte Lakehouse zu kopieren.

   1. Bei Delta-Tabellen müssen die Tabellen einzeln kopiert werden, um sie im neuen Lakehouse wiederherzustellen. Bei Lakehouse-Dateien können Sie die vollständige Dateistruktur mit allen zugrunde liegenden Ordnern in einem einzelnen Schritt kopieren.

   2. Wenden Sie sich an das Supportteam, um den im Skript erforderlichen Zeitstempel des Failovers zu erhalten.

   %%spark
   val source="abfs path to original Lakehouse file or table directory"
   val destination="abfs path to new Lakehouse file or table directory"
   val timestamp= //timestamp provided by Support
   
   mssparkutils.fs.cp(source, destination, true)
   
   val filesToDelete = mssparkutils.fs.ls(s"$source/_delta_log")
       .filter{sf => sf.isFile && sf.modifyTime > timestamp}
   
   for(fileToDelte <- filesToDelete) {
       val destFileToDelete = s"$destination/_delta_log/${fileToDelte.name}"
       println(s"Deleting file $destFileToDelete")
       mssparkutils.fs.rm(destFileToDelete, false)
   }
   
   mssparkutils.fs.write(s"$destination/_delta_log/_last_checkpoint", "", true)
   

5. Sobald Sie das Skript ausgeführt haben, werden die Tabellen im neuen Seehaus angezeigt.

Ansatz 2: Verwenden von Azure Storage-Explorer zum Kopieren von Dateien und Tabellen

Wenn Sie nur bestimmte Lakehouse-Dateien oder -Tabellen aus dem ursprünglichen Lakehouse wiederherstellen möchten, verwenden Sie Azure Storage-Explorer. Ausführliche Schritte finden Sie unter Integrieren von OneLake in Azure Storage-Explorer. Verwenden Sie für große Datenmengen Ansatz 1.

Notebook

Notizbücher aus der primären Region bleiben für Kunden nicht verfügbar, und der Code in Notizbüchern wird nicht in die sekundäre Region repliziert. Für die Wiederherstellung von Notebook-Codeinhalten in der neuen Region gibt es zwei Ansätze.

Ansatz 1: Benutzerseitig verwaltete Redundanz mit Git-Integration (Public Preview)

Am schnellsten und einfachsten ist es, die Git-Integration von Fabric zu verwenden und Ihr Notebook anschließend mit Ihrem ADO-Repository zu synchronisieren. Nachdem für den Dienst ein Failover auf eine andere Region ausgeführt wurde, können Sie das Notebook mithilfe des Repositorys in dem von Ihnen neu erstellten Arbeitsbereich neu erstellen.

1. Konfigurieren Sie die Git-Integration für Ihren Arbeitsbereich, und wählen Sie Verbinden und synchronisieren mit dem ADO-Repository aus.

   

   Die folgende Abbildung zeigt das synchronisierte Notebook.

   

2. Stellen Sie das Notebook aus dem ADO-Repository wieder her.

   1. Stellen Sie in dem neu erstellten Arbeitsbereich wieder eine Verbindung mit Ihrem Azure ADO-Repository her.

      

   2. Wählen Sie die Schaltfläche Quellcodeverwaltung aus. Wählen Sie dann den relevanten Branch des Repositorys aus. Wählen Sie Alle aktualisieren aus. Das ursprüngliche Notizbuch wird angezeigt.

      

      

   3. Wenn das ursprüngliche Notebook über ein Standard-Lakehouse verfügt, können Benutzer*innen den Lakehouse-Abschnitt heranziehen, um das Lakehouse wiederherzustellen und das neu wiederhergestellte Lakehouse mit dem neu wiederhergestellten Notebook zu verbinden.

      

   4. Die Git-Integration unterstützt keine Synchronisierung von Dateien, Ordnern oder Notebook-Momentaufnahmen im Ressourcen-Explorer für Notebooks.

      1. Wenn das ursprüngliche Notebook Dateien im Ressourcen-Explorer für Notebooks enthält, gilt Folgendes:

         1. Speichern Sie Dateien oder Ordner auf einem lokalen Datenträger oder an einem anderen Ort speichern.

         2. Laden Sie die Datei von Ihrem lokalen Datenträger oder Cloudlaufwerk wieder in das wiederhergestellte Notebook hoch.

      2. Wenn das ursprüngliche Notebook über eine Notebook-Momentaufnahme verfügt, speichern Sie auch die Notebook-Momentaufnahme in Ihrem eigenen Versionskontrollsystem oder auf Ihrem lokalen Datenträger.

         

         

Weitere Informationen zur Git-Integration finden Sie unter Einführung in die Git-Integration.

Ansatz 2: Manuelle Sicherung von Codeinhalten

Wenn Sie nicht die Git-Integration verwenden möchten, können Sie die neueste Version Ihres Codes sowie die Dateien im Ressourcen-Explorer und die Notebook-Momentaufnahme in einem Versionskontrollsystem wie Git speichern und den Notebook-Inhalt nach einem Notfall manuell wiederherstellen:

1. Verwenden Sie das Feature „Notebook importieren“, um den wiederherzustellenden Notebook-Code zu importieren.

   

2. Wechseln Sie nach dem Importieren zum gewünschten Arbeitsbereich (z. B. C2.W2), um darauf zuzugreifen.

3. Wenn das ursprüngliche Notebook über ein Standard-Lakehouse verfügt, lesen Sie den Lakehouse-Abschnitt. Verbinden Sie dann das neu wiederhergestellte Lakehouse (das über den gleichen Inhalt verfügt wie das ursprüngliche Standard-Lakehouse) mit dem neu wiederhergestellten Notebook.

4. Wenn das ursprüngliche Notebook Dateien oder Ordner im Ressourcen-Explorer enthält, laden Sie die Dateien oder Ordner, die im Versionskontrollsystem des Benutzers bzw. der Benutzerin gespeichert sind, wieder hoch.

Spark-Auftragsdefinition

Spark-Auftragsdefinitionen (Spark Job Definitions, SJDs) aus der primären Region können für Kunden nicht wieder verfügbar gemacht werden, und die Hauptdefinitionsdatei und die Referenzdatei im Notebook werden über OneLake in der sekundären Region repliziert. Wenn Sie die SJD in der neuen Region wiederherstellen möchten, können Sie die nachstehend beschriebenen manuellen Schritte ausführen. Historische Läufe der SJD werden nicht wiederhergestellt.

Sie können die SJD-Elemente wiederherstellen, indem Sie den Code mithilfe von Azure Storage-Explorer aus der ursprünglichen Region kopieren und die Verbindung von Lakehouse-Verweisen nach dem Notfall manuell wiederherstellen.

1. Erstellen Sie im neuen Arbeitsbereich C2.W2 ein neues SJD-Element (z. B. SJD1) mit den Einstellungen und Konfigurationen des ursprünglichen SJD-Elements (z. B. Sprache, Umgebung usw.).

2. Verwenden Sie Den Azure Storage-Explorer, um Libs, Mains und Snapshots aus dem ursprünglichen SJD-Element in das neue SJD-Element zu kopieren.

   

3. Der Codeinhalt wird in der neu erstellten SJD angezeigt. Der neu wiederhergestellte Lakehouse-Verweis muss dem Auftrag manuell hinzugefügt werden. (Weitere Informationen finden Sie in den Schritten für die Lakehouse-Wiederherstellung.) Benutzer*innen müssen die ursprünglichen Befehlszeilenargumente manuell erneut eingeben.

   

Nun können Sie Ihre neu wiederhergestellte SJD ausführen oder planen.

Ausführliche Informationen zu Azure Storage-Explorer finden Sie unter Integrieren von OneLake in Azure Storage-Explorer.

Data Science

Dieser Leitfaden führt Sie durch die Wiederherstellungsverfahren für die Data Science-Umgebung. Hier werden ML-Modelle und -Experimente behandelt.

ML-Modell und -Experiment

Data Science-Elemente aus der primären Region können für Kunden nicht wieder verfügbar gemacht werden, und die Inhalte und Metadaten in ML-Modellen und -Experimenten werden nicht in der sekundären Region repliziert. Um sie vollständig in der neuen Region wiederherzustellen, müssen Sie die Codeinhalte in einem Versionskontrollsystem wie Git speichern und nach dem Notfall manuell erneut ausführen.

1. Stellen Sie das Notebook wieder her. Weitere Informationen finden Sie in den Schritten für die Notebookwiederherstellung.

2. Die Konfiguration, historische Metriken sowie Metadaten werden nicht in der gekoppelten Region repliziert. Sie müssen jede Version Ihres Data Science-Codes erneut ausführen, um ML-Modelle und -Experimente nach dem Notfall vollständig wiederherzustellen.

Data Warehouse

Dieser Leitfaden führt Sie durch die Wiederherstellungsverfahren für die Data Warehouse-Umgebung. Hier werden Warehouses behandelt.

Warehouse

Warehouses aus der ursprünglichen Region können für Kunden nicht wieder verfügbar gemacht werden. Führen Sie die beiden folgenden Schritte aus, um Warehouses wiederherzustellen.

1. Erstellen Sie im Arbeitsbereich C2.W2 ein neues vorübergehendes Lakehouse für die Daten, die Sie aus dem ursprünglichen Warehouse kopieren.

2. Füllen Sie die Delta-Tabellen des Warehouse auf. Verwenden Sie dazu den Warehouse-Explorer und die T-SQL-Funktionen. (Weitere Informationen finden Sie unter Tabellen in Data Warehousing in Microsoft Fabric.)

Datenerfassung über Lakehouse und T-SQL-Code

Gehen Sie im neu erstellten Arbeitsbereich C2.W2 wie folgt vor:

1. Erstellen Sie in C2.W2 ein vorübergehendes Lakehouse (LH2).

2. Stellen Sie die Delta-Tabellen aus dem ursprünglichen Warehouse im vorübergehenden Lakehouse wieder her, wie in den Schritten für die Lakehouse-Wiederherstellung beschrieben.

3. Erstellen Sie in C2.W2 ein neues Warehouse (WH2).

4. Stellen Sie in Ihrem Warehouse-Explorer eine Verbindung mit dem vorübergehenden Lakehouse her.

5. Je nachdem, wie Sie Tabellendefinitionen vor dem Datenimport bereitstellen, kann der tatsächlich für Importe verwendete T-SQL-Code variieren. Sie können INSERT INTO, SELECT INTO oder CREATE TABLE AS SELECT verwenden, um Warehouse-Tabellen aus Lakehouses wiederherzustellen. Im weiteren Verlauf des Beispiels wird INSERT INTO verwendet. (Falls Sie den folgenden Code verwenden möchten, ersetzen Sie die Beispiele durch tatsächliche Tabellen- und Spaltennamen.)

   USE WH1
   
   INSERT INTO [dbo].[aggregate_sale_by_date_city]([Date],[City],[StateProvince],[SalesTerritory],[SumOfTotalExcludingTax],[SumOfTaxAmount],[SumOfTotalIncludingTax], [SumOfProfit])
   
   SELECT [Date],[City],[StateProvince],[SalesTerritory],[SumOfTotalExcludingTax],[SumOfTaxAmount],[SumOfTotalIncludingTax], [SumOfProfit]
   FROM  [LH11].[dbo].[aggregate_sale_by_date_city] 
   GO
   

6. Ändern Sie abschließend die Verbindungszeichenfolge in Anwendungen, die Ihr Fabric-Warehouse verwenden.

Gespiegelte Datenbanken

Gespiegelte Datenbanken aus der primären Region bleiben für Kunden nicht verfügbar, und die Einstellungen werden nicht in die sekundäre Region repliziert. Um sie im Falle eines regionalen Fehlers wiederherzustellen, müssen Sie die gespiegelte Datenbank in einem anderen Arbeitsbereich aus einer anderen Region neu erstellen.

Data Factory

Data Factory-Elemente aus der primären Region bleiben für Kunden nicht verfügbar, und die Einstellungen und Konfiguration in Pipelines oder Dataflow gen2-Elementen werden nicht in die sekundäre Region repliziert. Um diese Elemente im Falle eines regionalen Ausfalls wiederherzustellen, müssen Sie Ihre Datenintegrationselemente in einem anderen Arbeitsbereich aus einer anderen Region neu erstellen. Die folgenden Abschnitte enthalten ausführlichere Informationen.

Dataflows Gen2

Wenn Sie ein Dataflow Gen2-Element in der neuen Region wiederherstellen möchten, müssen Sie eine PQT-Datei in ein Versionskontrollsystem wie Git exportieren und dann den Dataflow Gen2-Inhalt nach dem Notfall manuell wiederherstellen.

1. Wählen Sie über Ihr Dataflow Gen2-Element auf der Registerkarte „Start“ des Power Query-Editors die Option Vorlage exportieren aus.

   

2. Geben Sie im Dialogfeld „Vorlage exportieren“ einen Namen (obligatorisch) und eine Beschreibung (optional) für diese Vorlage ein. Wählen Sie dann OK.

   

3. Erstellen Sie nach dem Notfall ein neues Dataflow Gen2-Element im neuen Arbeitsbereich C2.W2.

4. Wählen Sie im aktuellen Ansichtsbereich des Power Query-Editors die Option Aus Power Query-Vorlage importieren aus.

   

5. Navigieren Sie im Dialogfeld Öffnen zu Ihrem Standardordner für Downloads, und wählen Sie die PQT-Datei aus, die Sie in den vorherigen Schritten gespeichert haben. Wählen Sie anschließend Öffnen aus.

6. Die Vorlage wird dann in Ihr neues Dataflow Gen2-Element importiert.

Die Funktion "Datenflüsse speichern unter" wird im Falle einer Notfallwiederherstellung nicht unterstützt.

Pipelines

Kunden können im Falle einer regionalen Katastrophe nicht auf Pipelines zugreifen, und die Konfigurationen werden nicht in die gekoppelte Region repliziert. Es wird empfohlen, Ihre kritischen Pipelines in mehreren Arbeitsbereichen in verschiedenen Regionen zu erstellen.

Kopierauftrag

CopyJob-Benutzer müssen proaktive Maßnahmen ergreifen, um vor einer regionalen Katastrophe zu schützen. Mit dem folgenden Ansatz wird sichergestellt, dass nach einer regionalen Katastrophe die CopyJobs eines Benutzers weiterhin verfügbar bleiben.

Benutzerverwaltete Redundanz mit Git-Integration (in der öffentlichen Vorschau)

Die beste Möglichkeit, diesen Prozess einfach und schnell zu machen, besteht darin, die Fabric Git-Integration zu verwenden, und dann Ihren CopyJob mit Ihrem ADO-Repository zu synchronisieren. Nachdem der Dienst auf eine andere Region umgeschaltet wurde, können Sie das Repository verwenden, um den CopyJob im neuen, von Ihnen erstellten Arbeitsbereich neu zu erstellen.

1. Konfigurieren Sie die Git-Integration für Ihren Arbeitsbereich, und wählen Sie Verbinden und synchronisieren mit dem ADO-Repository aus.

   

   Die folgende Abbildung zeigt den synchronisierten CopyJob.

   

2. Stellen Sie den CopyJob aus dem ADO-Repository wieder her.

   1. Stellen Sie im neu erstellten Arbeitsbereich erneut eine Verbindung mit Ihrem Azure ADO-Repository her, und synchronisieren Sie sie erneut. Alle Fabric-Elemente in diesem Repository werden automatisch in Ihren neuen Arbeitsbereich heruntergeladen.

      

   2. Wenn der ursprüngliche CopyJob ein Lakehouse verwendet, können Benutzer auf den abschnitt Lakehouse verweisen, um das Lakehouse wiederherzustellen und dann den neu wiederhergestellten CopyJob mit dem neu wiederhergestellten Lakehouse zu verbinden.

Weitere Informationen zur Git-Integration finden Sie unter Einführung in die Git-Integration.

Apache Airflow-Auftrag

Apache Airflow Job in Fabric-Benutzer müssen proaktive Maßnahmen ergreifen, um sich vor einer regionalen Katastrophe zu schützen.

Es wird empfohlen, Redundanz mit der Fabric Git-Integration zu verwalten. Synchronisieren Sie zuerst Ihren Airflow-Auftrag mit Ihrem ADO-Repository. Wenn der Dienst in eine andere Region verschoben wird, können Sie das Repository nutzen, um den Airflow-Auftrag im neuen Arbeitsbereich, den Sie erstellt haben, neu aufzubauen.

Dies sind die folgenden Schritte:

1. Konfigurieren Sie die Git-Integration Ihres Arbeitsbereichs, und wählen Sie "Verbinden und Synchronisieren" mit dem ADO-Repository aus.

2. Danach sehen Sie, dass Ihr Airflow-Auftrag mit Ihrem ADO-Repository synchronisiert wurde.

3. Wenn Sie den Airflow-Auftrag aus dem ADO-Repository wiederherstellen müssen, erstellen Sie einen neuen Arbeitsbereich, stellen Sie eine Verbindung her, und synchronisieren Sie es erneut mit Ihrem Azure ADO-Repository. Alle Fabric-Elemente, einschließlich Airflow, in diesem Repository werden automatisch in Ihren neuen Arbeitsbereich heruntergeladen.

Echtzeitintelligenz

Dieser Leitfaden führt Sie durch die Wiederherstellungsprozesse für die Real-Time Business Intelligence-Erfahrung. Hier werden KQL-Datenbanken/-Abfragesets und Eventstreams behandelt.

KQL-Datenbank/-Abfrageset

Benutzer*innen von KQL-Datenbanken/-Abfragesets müssen proaktive Maßnahmen ergreifen, um sich vor einem regionalen Notfall zu schützen. Mit dem folgenden Ansatz wird sichergestellt, dass Daten in Ihren KQL-Datenbanken/-Abfragesets im Falle eines regionalen Notfalls sicher und zugänglich bleiben.

Verwenden Sie die folgenden Schritte, um eine effektive Notfallwiederherstellungslösung für KQL-Datenbanken und -Abfragesets zu gewährleisten:

1. Einrichten unabhängiger KQL-Datenbanken: Konfigurieren Sie mindestens zwei unabhängige KQL-Datenbanken/-Abfragesets für dedizierte Fabric-Kapazitäten. Diese müssen in zwei verschiedenen Azure-Regionen (vorzugsweise in Azure-Regionspaaren) eingerichtet werden, um die Resilienz zu maximieren.

2. Replizieren von Verwaltungsaktivitäten: Alle Verwaltungsaktionen, die in einer KQL-Datenbank ausgeführt werden, müssen in der anderen Datenbank gespiegelt werden. Dadurch wird sichergestellt, dass beide Datenbanken synchron bleiben. Einige wichtige Aktivitäten, die repliziert werden müssen, sind:

   • Tabellen: Stellen Sie sicher, dass die Tabellenstrukturen und Schemadefinitionen in den Datenbanken konsistent sind.

   • Zuordnung: Duplizieren Sie alle erforderlichen Zuordnungen. Stellen Sie sicher, dass Datenquellen und -ziele korrekt ausgerichtet sind.

   • Richtlinien: Stellen Sie sicher, dass beide Datenbanken über ähnliche Richtlinien für Datenaufbewahrung, Zugriff und andere relevante Bereiche verfügen.

3. Verwalten von Authentifizierung und Autorisierung: Richten Sie für jedes Replikat die erforderlichen Berechtigungen ein. Stellen Sie sicher, dass die richtigen Autorisierungsstufen eingerichtet werden, um dem Personal den nötigen Zugriff zu erteilen und Sicherheitsstandards einzuhalten.

4. Parallele Datenerfassung: Damit die Daten konsistent und in mehreren Regionen verfügbar sind, laden Sie dasselbe Dataset zum gleichen Zeitpunkt in die einzelnen KQL-Datenbanken, zu dem Sie es erfassen.

Eventstream

Ein Eventstream ist ein zentraler Ort der Fabric-Plattform zum Erfassen, Transformieren und Weiterleiten von Echtzeitereignissen an verschiedene Ziele (z. B. Lakehouses, KQL-Datenbanken/-Abfragesets) ohne Programmieraufwand. Wenn die Ziele von der Notfallwiederherstellung unterstützt werden, gehen bei Eventstreams keine Daten verloren. Daher sollten Kunden die Notfallwiederherstellungsfunktionen dieser Zielsysteme verwenden, um die Datenverfügbarkeit zu gewährleisten.

Kunden können auch Georedundanz erreichen, indem identische Eventstream-Workloads in mehreren Azure-Regionen im Rahmen einer Aktiv-Aktiv-Strategie mit mehreren Standorten bereitgestellt werden. Bei einem Aktiv-Aktiv-Ansatz mit mehreren Standorten können Kunden auf ihre Workload in einer beliebigen der bereitgestellten Regionen zugreifen. Dieser Ansatz ist der komplexeste und teuerste Ansatz für die Notfallwiederherstellung, kann aber die Wiederherstellungszeit in den meisten Situationen auf nahezu Null reduzieren. Um vollständige Georedundanz zu erreichen, können Kunden folgende Schritte ausführen:

1. Erstellen von Replikaten ihrer Datenquellen in verschiedenen Regionen

2. Erstellen von Eventstream-Elementen in entsprechenden Regionen

3. Verbinden dieser neuen Elemente mit den identischen Datenquellen

4. Hinzufügen identischer Ziele für jeden Eventstream in verschiedenen Regionen

Transaktionsdatenbank

In diesem Leitfaden werden die Wiederherstellungsprozeduren für die Transaktionsdatenbank beschrieben.

SQL database

Um vor einem regionalen Fehler zu schützen, können Benutzer von SQL-Datenbanken proaktive Maßnahmen ergreifen, um ihre Daten regelmäßig zu exportieren und die exportierten Daten zu verwenden, um die Datenbank bei Bedarf in einem neuen Arbeitsbereich neu zu erstellen.

Dies kann mithilfe des SqlPackage CLI-Tools erreicht werden, das Datenbankübertragbarkeit bereitstellt und Datenbankbereitstellungen erleichtert.

1. Verwenden Sie das SqlPackage-Tool, um die Datenbank in eine .bacpac Datei zu exportieren. Weitere Informationen finden Sie unter Exportieren einer Datenbank mit SqlPackage .
2. Speichern Sie die .bacpac Datei an einem sicheren Speicherort, der sich in einer anderen Region als der Datenbank befindet. Beispiele hierfür sind das Speichern der .bacpac Datei in einem Lakehouse, das sich in einer anderen Region befindet, mithilfe eines georedundanten Azure Storage-Kontos oder mithilfe eines anderen sicheren Speichermediums, das sich in einer anderen Region befindet.
3. Wenn die SQL-Datenbank und -Region nicht verfügbar sind, können Sie die .bacpac Datei mit SqlPackage verwenden, um die Datenbank in einem Arbeitsbereich in einem neuen Bereich – Arbeitsbereich C2 – neu zu erstellen. W2 in Region B wie im obigen Szenario beschrieben. Führen Sie die in " Importieren einer Datenbank mit SqlPackage " beschriebenen Schritte aus, um die Datenbank mit Ihrer .bacpac Datei neu zu erstellen.

Die neu erstellte Datenbank ist eine unabhängige Datenbank aus der ursprünglichen Datenbank und gibt den Status der Daten zum Zeitpunkt des Exportvorgangs wieder.

Failback-Überlegungen

Die neu erstellte Datenbank ist eine unabhängige Datenbank. Daten, die der neu erstellten Datenbank hinzugefügt wurden, werden nicht in der ursprünglichen Datenbank widerzuspiegeln. Wenn Sie beabsichtigen, ein Failback zur ursprünglichen Datenbank auszuführen, wenn die Heimregion verfügbar wird, müssen Sie die manuelle Abstimmung von Daten aus der neu erstellten Datenbank in der ursprünglichen Datenbank in Betracht ziehen.

Plattform

Plattform bezieht sich auf die zugrunde liegenden gemeinsamen Dienste und Architekturen, die für alle Workloads gelten. Dieser Abschnitt führt Sie durch die Wiederherstellungsprozeduren für gemeinsame Erfahrungen. Es behandelt Variablenbibliotheken.

Variable Library

Mit Microsoft Fabric Variable-Bibliotheken können Entwickler Elementkonfigurationen innerhalb eines Arbeitsbereichs anpassen und freigeben, um die Verwaltung des Inhaltslebenszyklus zu optimieren. Aus Sicht der Notfallwiederherstellung müssen Benutzer von Variablenbibliotheken proaktiv vor einer regionalen Katastrophe schützen. Dies kann über die Fabric Git-Integration erfolgen, wodurch sichergestellt wird, dass nach einem regionalen Notfall die Variable-Bibliothek eines Benutzers verfügbar bleibt. Zum Wiederherstellen einer Variablenbibliothek empfehlen wir Folgendes:

• Verwenden Sie die Fabric Git-Integration, um Ihre Variable-Bibliothek mit Ihrem ADO-Repository zu synchronisieren. Im Falle eines Notfalls können Sie das Repository verwenden, um die Variable-Bibliothek im neuen Arbeitsbereich neu zu erstellen, den Sie erstellt haben. Führen Sie die folgenden Schritte aus:

  1. Verbinden Sie Ihren Arbeitsbereich mit Git-Repository, wie hier beschrieben.
  2. Stellen Sie sicher, dass die WS und das Repository mit Commit und Update synchronisiert werden.
  3. Wiederherstellung – Verwenden Sie im Notfall das Repository, um die Variable-Bibliothek in einem neuen Arbeitsbereich neu zu erstellen:

• Stellen Sie im neu erstellten Arbeitsbereich erneut eine Verbindung mit Ihrem Azure ADO-Repository her, und synchronisieren Sie sie erneut.

• Alle Fabric-Elemente in diesem Repository werden automatisch in Ihren neuen Arbeitsbereich heruntergeladen.

• Nachdem Sie Ihre Elemente aus Git synchronisiert haben, öffnen Sie Ihre Variablenbibliotheken im neuen Arbeitsbereich, und wählen Sie den gewünschten aktiven Wertsatz manuell aus.

Vom Kunden verwaltete Schlüssel für Fabric-Arbeitsbereiche

Sie können kundenverwaltete Schlüssel (CMK) verwenden, die in Azure Key Vault gespeichert sind, um zusätzlich zu von Microsoft verwalteten Schlüsseln für ruhende Daten eine zusätzliche Verschlüsselungsebene hinzuzufügen. Wenn Fabric in einer Region nicht mehr zugänglich oder funktionsfähig ist, wechseln die Komponenten zu einer Sicherungsinstanz. Während des Failovers unterstützt das CMK-Feature schreibgeschützte Vorgänge. Solange der Azure Key Vault-Dienst fehlerfrei bleibt und Die Berechtigungen für den Tresor intakt sind, stellt Fabric weiterhin eine Verbindung mit Ihrem Schlüssel her und ermöglicht es Ihnen, Daten normal zu lesen. Dies bedeutet, dass die folgenden Vorgänge während des Failovers nicht unterstützt werden: Aktivieren und Deaktivieren der CMK-Einstellung des Arbeitsbereichs und Aktualisieren des Schlüssels.

Verwandte Informationen

• Leitfaden zur Notfallwiederherstellung von Microsoft Fabric