Erfahrungsspezifischer Leitfaden für die Notfallwiederherstellung

Dieses Dokument enthält erfahrungsspezifische Anleitungen zum Wiederherstellen Ihrer Fabric Daten im Falle einer regionalen Katastrophe.

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.

Nehmen wir an, Sie haben eine Kapazität C1 in Region A, die einen Arbeitsbereich W1 enthält. Wenn Sie die Notfallwiederherstellung für Kapazität C1 aktiviert haben, werden die OneLake-Daten in eine Sicherungskopie in Region B repliziert. Wenn in Region A Störungen auftreten, wechselt der Fabric-Dienst in C1 nach Region B.

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. Arbeiten Sie kopierte Daten aus dem gestörten C1.W1 in C2.W2 ein.

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.

Erfahrungsspezifische Wiederherstellungspläne

In den folgenden Abschnitten finden Sie schrittweise Anleitungen für jede Fabric Erfahrung, die Kunden beim Wiederherstellungsvorgang unterstützt.

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. Wir empfehlen zwei Ansätze für die Wiederherstellung von Lakehouses:

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 unter Datenpfaden mit OneLake wie z. B. abfss (siehe Verbinden mit Microsoft OneLake). Sie können das folgende Codebeispiel (siehe Einführung in die Microsoft Spark Utilities) im Notizbuch verwenden, um die ABFS-Pfade von Dateien und Tabellen aus dem ursprünglichen Lakehouse zu erhalten. (Ersetzen Sie C1.W1 durch den tatsächlichen Arbeitsbereichsnamen.)

   notebookutils.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
   
   notebookutils.fs.cp(source, destination, true)
   
   val filesToDelete = notebookutils.fs.ls(s"$source/_delta_log")
       .filter{sf => sf.isFile && sf.modifyTime > timestamp}
   
   for(fileToDelete <- filesToDelete) {
       val destFileToDelete = s"$destination/_delta_log/${fileToDelete.name}"
       println(s"Deleting file $destFileToDelete")
       notebookutils.fs.rm(destFileToDelete, false)
   }
   
   notebookutils.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

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

Wiederherstellen von Fabric bereitgestellten Datenlake-Ansichten

Materialisierte Lake Views aus der ursprünglichen Region bleiben nach dem Failover für Kunden nicht verfügbar. Aktualisierungszeitpläne und Ausführungsverlauf werden nicht in die sekundäre Region repliziert. Um sie wiederherzustellen, führen Sie die folgenden Schritte aus, nachdem Sie Ihre Lakehouse-Daten wiederhergestellt haben.

• Stellen Sie die Lakehouse-Tabellen mithilfe von Approach 1 oder Approach 2 wieder her, wie oben beschrieben. Kopieren Sie nur die Quelltabellen.
• Stellen Sie die Notizbücher wieder her, die Ihre MLV-Definitionen enthalten. Anleitung für die Wiederherstellung finden Sie im Bereich Notebook.
• Führen Sie die wiederhergestellten Notizbücher aus, um die MLVs im neuen Lakehouse neu zu erstellen. Informationen zum Erstellen von MLVs finden Sie unter Create a Materialized Lake View. Wenn MLVs auch im vorherigen Schritt kopiert wurden, führen Sie CREATE OR REPLACE aus, während Sie sie neu erstellen.
• Erstellen Sie die MLV-Aktualisierungszeitpläne manuell im neuen Arbeitsbereich neu. Zeitplanverlaufs- und Ausführungsmetriken können nicht wiederhergestellt werden.
• Wenn Ihre MLVs semantische Modelle oder Berichte versorgen, überprüfen und aktualisieren Sie die Lakehouse-ID und Dataset-ID Verweise nach Bedarf. Verbinden Sie Berichte mit dem aktualisierten Semantikmodell erneut, und überprüfen Sie die Aktualität der Daten.

Laptop

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)

Die beste Möglichkeit, dies einfach und schnell zu machen, besteht darin, Fabric Git-Integration zu verwenden, und dann Ihr Notizbuch 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 im neu erstellten Arbeitsbereich erneut eine Verbindung mit Ihrem Azure ADO-Repository her.

      

   2. Wählen Sie die Schaltfläche Quellcodeverwaltung aus. Wählen Sie dann den entsprechenden Branch des Repository 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. Stellen Sie sicher, dass 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, verweisen Sie auf 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 aus der ursprünglichen Region kopieren, indem Sie Azure Storage-Explorer verwenden und lakehouse-Verweise nach der Katastrophe manuell erneut verbinden.

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 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 Integrate OneLake with Azure Storage-Explorer.

GraphQL

GraphQL-Elemente aus der primären Region sind nach einem regionalen Notfall nicht verfügbar, und GraphQL-Definitionen und -Konfigurationen werden nicht in die sekundäre Region repliziert. Um GraphQL in einer neuen Region wiederherzustellen, verwenden Sie einen der folgenden Ansätze.

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

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

1. Erstellen Sie einen neuen Arbeitsbereich in der Zielkapazität und -region.

2. Stellen Sie alle abhängigen Datenquellen wie Lakehouse-, Warehouse- oder SQL-Datenbanken wieder her, indem Sie die entsprechenden Wiederherstellungsschritte ausführen.

3. Aktualisieren Sie die GraphQL-Definition so, dass sie auf die neu wiederhergestellten Ressourcen verweist, indem Sie umgebungsspezifische Verweise wie Quellarbeitsbereichs-IDs, Quellartefakte-IDs und Verbindungsdetails ändern. Dieser Schritt stellt die korrekte Bindung bei der Bereitstellung sicher.

4. Stellen Sie GraphQL-Artefakte aus dem Git-Repository erneut im neuen Arbeitsbereich bereit. In diesem Schritt wird die API-Struktur und -Konfiguration mithilfe der aktualisierten Definitionen neu erstellt.

5. Erneutes Anwenden von Artefakteinstellungen, einschließlich Rollen, Zugriffssteuerungen und Authentifizierungskonfiguration.

6. Erneutes Anwenden von Endpunktreferenzen durch Aktualisieren von Anwendungen oder Integrationen für die Verwendung des neu erstellten GraphQL-Endpunkts.

7. Aktualisieren Sie alle vorhandenen Bereitstellungspipelines, die auf den alten Arbeitsbereich verweisen, um auf den neu erstellten Arbeitsbereich zu verweisen.

8. Überprüfen der End-to-End-Funktionalität der API.

Ansatz 2: Manueller Ansatz

Wenn Sie den Git-Integrationsansatz nicht verwenden, können Sie den folgenden manuellen Ansatz verwenden, um GraphQL wiederherzustellen.

1. Erstellen Sie einen neuen Arbeitsbereich in der Zielkapazität und -region.

2. Wiederherstellen aller abhängigen Datenquellen, z. B. Lakehouse-, Warehouse- oder SQL-Datenbanken.

3. Erstellen Sie die GraphQL-API manuell im neuen Arbeitsbereich neu, einschließlich Schemadefinitionen, Datenquellenverbindungen und Beziehungen.

4. Erneutes Anwenden von Artefakteinstellungen, einschließlich Rollen, Zugriffssteuerungen und Authentifizierungskonfiguration.

5. Erneutes Anwenden von Endpunktreferenzen durch Aktualisieren von Anwendungen oder Integrationen für die Verwendung des neu erstellten GraphQL-Endpunkts.

6. Aktualisieren Sie alle vorhandenen Bereitstellungspipelines, die auf den alten Arbeitsbereich verweisen, um auf den neu erstellten Arbeitsbereich zu verweisen.

7. Überprüfen der End-to-End-Funktionalität der API.

Wichtige Überlegungen

1. GraphQL basiert auf externen Abhängigkeiten (z. B. Lakehouse, Warehouse und SQL), die Sie vor der GraphQL-Bereitstellung wiederherstellen müssen.

2. GraphQL-API-Definitionen enthalten umgebungsspezifische Verweise (wie sourceWorkspaceId und sourceItemId). Bei der Wiederherstellung in einem neuen Bereich werden diese Verweise möglicherweise ungültig. Aktualisieren Sie sie so, dass sie auf neu bereitgestellte Ressourcen verweisen.

3. Die automatische Neubindung von Datenquellen ist in Notfallwiederherstellungsszenarien nicht garantiert, insbesondere bei Verwendung gespeicherter Anmeldeinformationen oder arbeitsbereichübergreifender Verbindungen.

4. Andere Artefakteinstellungen wie Überwachung, Autorisierung, RBAC, Introspection und mehr werden nach dem Failover nicht übernommen. Sie müssen diese Einstellungen in der neuen Region erneut einrichten.

Referenzen

• Übersicht über die Fabric Git-Integration – Microsoft Fabric | Microsoft Lernen

• Quellcodeverwaltungs- und Bereitstellungspipelinen in der API für GraphQL – Microsoft Fabric | Microsoft Lernen 

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 Erfahrung. Hier werden Warehouses behandelt.

Lagerhaus

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 Lagerlagers auf, indem Sie den Lager-Explorer und die T-SQL-Funktionen nutzen (siehe Tables in Data Warehouse 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 temporären Lakehouse wieder her, indem Sie die Schritte zur Lakehouse-Wiederherstellung befolgen.

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 auf Warehouse-Tabellen aus Lakehouses zuzugreifen. 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 schließlich die Verbindungszeichenfolge in Anwendungen, die Ihr Fabric Data 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 von Ihrem Element für Dataflow Gen2 auf der Registerkarte "Startseite" des Power Query-Editors die Exportvorlage 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 Import aus einer Power Query Vorlage 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, 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. 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 vor einer regionalen Katastrophe zu schützen.

Es wird empfohlen, Redundanz mit 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.

Activator

Aktiviererelemente aus der primären Region sind für Kunden nicht verfügbar, und Aktivierungsauslöserdefinitionen werden nicht in die sekundäre Region repliziert. Aktivierer müssen proaktive Schritte unternehmen, um sich auf die regionale Notfallwiederherstellung vorzubereiten.

Um sicherzustellen, dass Sie Aktivatorelemente im Falle eines regionalen Notfalls wiederherstellen können, richten Sie Fabric Git-Integration ein, um Triggerdefinitionen zu sichern und in einem Arbeitsbereich in einer anderen Region wiederherzustellen.

1. Konfigurieren Sie Fabric Git-Integration für den Arbeitsbereich, der Ihr Aktivatorelement enthält, und synchronisieren Sie Ihre Triggerdefinitionen mit Ihrem Git-Repository.
2. Halten Sie die Definitionen Ihrer Activator-Trigger regelmäßig eingecheckt und synchronisiert.
3. Erstellen Sie während der Wiederherstellung einen neuen Arbeitsbereich in der Zielregion (C2). W2), verbinden Sie es mit demselben Repository, und synchronisieren Sie sie, um die Triggerdefinitionen wiederherzustellen.
4. Konfigurieren und Überprüfen aller Aktivatordatenquellen und Abhängigkeiten im neuen Arbeitsbereich.

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

Graph-Modell/Queryset

Gegenstände des Graph-Modells und der Graph-Abfrage aus der primären Region bleiben für Kunden weiterhin nicht verfügbar, und diese Gegenstände werden nicht in die sekundäre Region repliziert. Um wiederherzustellen, erstellen oder verwenden Sie eine Kapazität in einer anderen Region; erstellen Sie dort die Elemente "Graph-Modell" und "Graph-Queryset" neu.

1. Erstellen Sie oder verwenden Sie eine vorhandene Fabric-Kapazität in einer anderen Region, die von der Katastrophe nicht betroffen ist.

2. Erstellen Sie einen neuen Arbeitsbereich, oder verwenden Sie einen vorhandenen Arbeitsbereich in dieser Kapazität.

3. Erstellen Sie das Diagrammmodellelement im sekundären Arbeitsbereich neu (in Schritt 2 referenziert). Konfigurieren Sie die Modelldefinition neu, einschließlich Knoten, Kanten usw., um dem ursprünglichen Graph-Modell zu entsprechen.

4. Wenn sich das ursprüngliche Lakehouse in der fehlerhaften Region befindet, stellen Sie es zuerst wieder her, indem Sie dem Lakehouse-Abschnitt folgen.

5. Verbinden Sie ein Seehaus als OneLake-Datenquelle für das neu erstellte Graph-Modellelement. Verwenden Sie das wiederhergestellte Seehaus, wenn es sich in der fehlerhaften Region befand, oder stellen Sie die Verbindung zum vorhandenen Seehaus wieder her, wenn es weiterhin verfügbar ist.

6. Konfigurieren Sie alle Datenladezeitpläne oder Verbindungen für das Graph-Modell im neuen Arbeitsbereich neu.

7. Erstellen Sie das Graph Queryset-Element im sekundären Arbeitsbereich neu. Geben Sie die Abfragen und alle gespeicherten Abfragekonfigurationen aus dem ursprünglichen Graph Queryset manuell erneut ein.

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 zwei oder mehr unabhängige KQL-Datenbanken/Querysets auf dedizierten Fabric-Kapazitäten. Diese sollten in zwei verschiedenen Azure Regionen (vorzugsweise Azure-gekoppelten Regionen) 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 richtig 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.

Ereignisstrom

Ein Eventstream ist ein zentraler Ort in der Fabric-Plattform zum Erfassen, Transformieren und Weiterleiten von Echtzeitereignissen an verschiedene Ziele (z. B. Lakehouses, KQL-Datenbanken/Querysets) mit einer No-Code-Benutzererfahrung. 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 als Teil einer aktiv/aktiven 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

Geschäftsereignisse, Fabric-Ereignisse und Azure-Ereignisse

Obwohl Geschäftsereignisse, Fabric Ereignisse und Azure Ereignisse die gleiche Real-Time Hubinfrastruktur in Microsoft Fabric aufweisen, weisen sie unterschiedliche Ursprünge, Verhaltensweisen und Wiederherstellungsanforderungen auf, die vor der Planung der Notfallwiederherstellung verstanden werden müssen:

• Fabric-Events sind Ereignisabonnements, die auf Aktivitäten reagieren, die von Fabric-Ressourcen selbst erzeugt werden, einschließlich Änderungen im Lebenszyklus von Arbeitsbereichselementen (z. B. dem Erstellen, Aktualisieren oder Löschen von Lakehouses, Notebooks oder Warehouses), Auftragsausführungen (z. B. Pipelineausführungen oder Notebookausführungen) sowie Datei- und Ordnervorgängen in OneLake. Diese Abonnements sind pushbasiert und kurzlebig. Die Abonnements werden nicht in die sekundäre Region repliziert.

• Azure Ereignisse sind Ereignisabonnements für Aktivitäten, die von Azure Blob Storage Konten erstellt werden. Diese Azure Ressourcen sind unabhängig von jeder Fabric Kapazität oder Region vorhanden. Obwohl die Azure Blob Storage Ressource selbst während eines Fabric regionalen Ausfalls verfügbar bleiben kann, werden die in Real-Time Hub konfigurierten Abonnements nicht in die sekundäre Region repliziert und müssen neu erstellt werden.

• Geschäftsereignisse sind eine unterschiedliche Funktion in Fabric Real-Time Intelligence, mit der Teams aussagekräftige Geschäftssignale definieren, veröffentlichen und darauf reagieren können. Geschäftsereignisse werden aus Fabric über Aktivierer, Spark-Notizbücher oder Benutzerdatenfunktionen generiert, die dann auf Real-Time Hub veröffentlicht werden, in dem nachgeschaltete Verbraucher wie Aktivator, Eventhouse oder Power Automate darauf reagieren können. Ereignisschemas werden zentral über die Schemaregistrierung gesteuert. Eventhouse speichert automatisch jedes veröffentlichte Geschäftsereignis, sodass sich die Wiederherstellung direkt auf die Verfügbarkeit des Geschäftsereignisverlaufs auswirkt. Keine der Herausgeber- oder Verbraucherkonfigurationen, Schemadefinitionen oder Abonnements werden in die sekundäre Region repliziert.

Führen Sie die folgenden Schritte aus, um Business Events, Fabric-Ereignisse und Azure-Ereignisse im neuen Arbeitsbereich in der Wiederherstellungsregion wiederherzustellen.

Für Geschäftsveranstaltungen:

1. Erstellen Sie das von Herausgebern und Verbrauchern verwendete Geschäftsereignis neu, indem Sie dem Artikel "Geschäftsereignisse erstellen" in Fabric Real-Time Hub folgen. Während der Erstellung des Geschäftsereignisses erstellen Sie die Ereignisschemasatz-Ressource. Die Eventhouse-Ressource ist je nach Szenario optional.

2. Erstellen Sie alle publisher Elemente neu, die Geschäftsereignisse generieren, z. B. Spark-Notizbücher oder Benutzerdatenfunktionen, im neuen Arbeitsbereich, indem Sie den publisher Artikeln folgen: Verwenden von User Data Function as a Business Events Publisher, Use Activator as a Business Events Publisher, Use Notebook as a Business Events Publisher und "Eventstream" als Publisher für Geschäftsereignisse verwenden.

3. Erstellen Sie die Consumer-Abonnements im Real-Time Hub neu (z. B. Activator-Regeln, Notebook-Trigger oder Power Automate-Flows), die ursprünglich auf Geschäftsereignisse in der betroffenen Region reagierten, indem Sie die Artikel Eventhouse and Real-Time Dashboard Integration with Business Events und Geschäftsereignisse aus Activator nutzen befolgen.

4. Überprüfen Sie, ob Ereignisse end-to-End ablaufen, indem Sie überprüfen, ob Abonnements aktiv sind und dass Daten an den erwarteten Zielen in der Wiederherstellungsregion ankommen.

Für Fabric-Events:

1. Erstellen Sie die Abonnements im Real-Time hub neu, die auf die Workspaceelemente, Jobs oder OneLake-Pfade verweisen, die in der Wiederherstellungsregion wiederhergestellt wurden, indem Sie dem Artikel Fabric-Ereignisse im Fabric Real-Time hub erkunden folgen.

2. Überprüfen Sie, ob Ereignisse end-to-End ablaufen, indem Sie überprüfen, ob Abonnements aktiv sind und dass Daten an den erwarteten Zielen in der Wiederherstellungsregion ankommen.

Für Azure Ereignisse:

1. Azure Blob Storage Konten sind von einem Fabric regionalen Ausfall nicht betroffen. Erstellen Sie die Ereignisabonnements in Real-Time Hub neu, die auf dieselben Azure Blob Storage Konten zeigen, indem Sie dem Artikel "Benachrichtigungen für Azure Blob Storage Ereignisse im Real-Time Hub festlegen" folgen.

2. Überprüfen Sie, ob Ereignisse end-to-End ablaufen, indem Sie überprüfen, ob Abonnements aktiv sind und dass Daten an den erwarteten Zielen in der Wiederherstellungsregion ankommen.

Map

Kartenelemente aus der primären Region bleiben für Kunden nicht verfügbar, und die Kartenelemente werden nicht in die sekundäre Region repliziert.

Wenn Sie ein Kartenelement wiederherstellen möchten, wenn ein Notfall auftritt, richten Sie Fabric Git-Integration und synchronisieren Ihr Kartenelement mit Ihrem Git-Repository ein.

Während der Wiederherstellung können Sie, nachdem die neue Region/Kapazität in Fabric eingerichtet wurde, das Repo verwenden, um das Map-Element im neuen Arbeitsbereich, den Sie erstellt haben, neu zu erstellen. Da der neue Arbeitsbereich leer ist, ruft Git sync den Inhalt aus dem Repository in den leeren Arbeitsbereich ab. In diesem Schritt wird das Kartenelement wieder zum Leben erweckt.

Ontologie

Ontologiebenutzer müssen proaktive Schritte ausführen, um sich auf die regionale Notfallwiederherstellung vorzubereiten. Der unten beschriebene Ansatz stellt sicher, dass Ihre Ontology nach einer regionalen Katastrophe wiederherstellbar bleibt und schnell wiederhergestellt werden kann.

Die einfachste und schnellste Möglichkeit zum Aktivieren der Wiederherstellung besteht darin, Fabric Git-Integration zu verwenden und Ihre Ontology mit einem Azure DevOps -Repository (ADO) zu synchronisieren. Wenn der Dienst in eine andere Region übergeht, können Sie dieses Repository verwenden, um die Ontologie in einem neu erstellten Arbeitsbereich wiederherzustellen.

Ontology-Elemente in der primären Region sind nach einem regionalen Notfall nicht für Kunden verfügbar, und Ontology-Elemente werden nicht in die sekundäre Region repliziert.

Um ein Ontology-Element während eines Notfalls wiederherzustellen, konfigurieren Sie Fabric Git-Integration und synchronisieren das Ontology-Element vorab mit Ihrem ADO-Repository.

Während der Wiederherstellung, sobald die neue Region und Kapazität in Fabric eingerichtet sind, können Sie das Repository verwenden, um das Ontologie-Element in einem neuen Arbeitsbereich wiederherzustellen. Da der neue Arbeitsbereich leer ist, ruft Git sync den Inhalt aus dem Repository in den Arbeitsbereich ab und stellt das Ontology-Element effektiv wieder her.

Planen

In diesem Artikel werden die Wiederherstellungsverfahren für die Planerfahrung in IQ beschrieben. Es beschreibt die Schritte, die zum Wiederherstellen wichtiger Komponenten erforderlich sind, einschließlich Planung, PowerTable, Intelligence, InfoBridge und zugehöriger Datenressourcen.

Git-Integration zum Wiederherstellen von Planelementen

Der bevorzugte Ansatz besteht darin, alle Planelemente mit einem Azure DevOps (ADO) oder GitHub Repository mithilfe Fabric Git-Integration zu synchronisieren. Verwenden Sie nach einem Failover das Repository, um die Elemente im neuen Arbeitsbereich wiederherzustellen.

Prädisaster (proaktive Schritte):

1. Wechseln Sie im Arbeitsbereich W1 zu "Arbeitsbereichseinstellungen" , und konfigurieren Sie die Git-Integration.

2. Wählen Sie "Verbinden" und "Synchronisieren" mit Ihrem ADO- oder GitHub-Repository aus.

3. Wählen Sie die Planelemente aus, die in das Repository hochgeladen werden sollen, und wählen Sie "Commit ausführen" aus.

   

4. Vergewissern Sie sich, dass der Git-Status von Planelementen synchronisiert ist.

5. Führen Sie eine Commit-Disziplin ein – erstellen Sie nach jeder wesentlichen Änderung an einer Plandefinition einen Commit, damit das Repository immer den neuesten Stand widerspiegelt.

Schritte zur Wiederherstellung:

1. Erstellen Sie einen neuen Arbeitsbereich W2 innerhalb der Kapazität C2 in der fehlerfreien Region.

2. Wechseln Sie im Arbeitsbereich W2 zu "Arbeitsbereichseinstellungen", und stellen Sie die Verbindung mit demselben ADO/GitHub Repository wieder her.

3. Wählen Sie "Quellcodeverwaltung" aus. Wählen Sie den relevanten Repositoryzweig und dann "Alle aktualisieren" aus. Alle Planelemente werden in W2 heruntergeladen.

Die folgenden Komponenten werden nach der Wiederherstellung wiederhergestellt:

• PowerTable-Blätter: Quelltabelleneinstellungen, Spaltenkonfiguration, Zeilenzugriff, visuelle Eigenschaften (Layout, Formate und mehr), Zeilenidentifikation, Kommentareinstellungen, langsam ändernde Dimensionen (SCD), Genehmigungen, Automatisierungen und Formulare.
• Planungsblätter: Blatteigenschaften (Formatierung, bedingte Formatierung und mehr), Kommentareinstellungen, Rückschreibeinstellungen, Dateneingabespalten, Dateneingabezeilen, Szenarien und Lesezeichen.
• InfoBridge: InfoBridge-Quellen, InfoBridge-Abfragen, Transformationsschritte, Rückschreibziele, Rückschreibeinstellungen, verknüpfte Abfragezuordnungen, Abfragegruppen, visuelle Eigenschaften (Blend). Diese Elemente können nicht wiederhergestellt werden: dateibasierte Quellen (CSV, Excel), Arbeitsauslastungsübergreifende Blätter, die dateibasierte Quellen verwenden.
• Intelligenz: Alle Diagramme und Matrizen.

Fabric SQL-Wiederherstellung für den Plan

In Planungsblättern eingegebene Daten, tabellen, die in PowerTable verwendet werden, und Rückschreibdaten werden in SQL-Datenbanken gespeichert und müssen als Teil Ihrer Notfallwiederherstellungsstrategie betrachtet werden. Informationen zum Wiederherstellen von SQL-Datenbanken finden Sie im Abschnitt zur SQL-Datenbank .

• Wiederherstellungsplanmetadaten: Jedes Planelement ist einer __fabric_plan_sys Datenbank zugeordnet, in der Metadaten für Planungsfeatures gespeichert werden, einschließlich Kommentare, Szenarien, Dateneingaben und Rückschreibkonfiguration. Die __fabric_plan_sys Datenbank wird nicht automatisch wiederhergestellt und muss explizit wiederhergestellt werden.

• Wiederherstellen von Rückschreibdatenbanken: Wenn Ihr Plan SQL-Zurückschreibziele verwendet, müssen Sie die zugehörigen Datenbanken auch manuell wiederherstellen. Konfigurierte SQL-Zurückschreibziele werden nicht automatisch wiederhergestellt.

• Wiederherstellen von Tabellen, die in PowerTable verwendet werden: Alle mithilfe von PowerTable erstellten Tabellen werden in einer Fabric SQL-Datenbank gespeichert. Sie müssen diese Tabellen auch im Rahmen der DR-Wiederherstellung wiederherstellen.

Operationsagenten

Operations-Agent-Benutzer sollten proaktive Schritte ausführen, um sich auf die regionale Notfallwiederherstellung vorzubereiten. Wenn Sie den in diesem Abschnitt beschriebenen Ansatz befolgen, können Sie sicherstellen, dass Ihre Agents nach einem regionalen Ausfall schnell wiederhergestellt werden können.

Verwenden Sie Fabric Git-Integration, um Ihren Arbeitsbereich mit einem Repository zu synchronisieren. Mit diesem Ansatz können Sie Agentkonfigurationen in einem neuen Arbeitsbereich wiederherstellen, wenn der Dienst ein Failover in eine andere Region durchführt.

Operations Agent-Elemente in der primären Region sind während eines regionalen Notfalls nicht verfügbar. Agentkonfigurationen, Verhaltensmodelle und Aktivitätsprotokolle werden nicht in die sekundäre Region repliziert. Laufende Vorgänge, aktive Chatsitzungen und zuvor aufgenommene Ereignisse zum Zeitpunkt der Katastrophe gehen ebenfalls verloren.

Um sich auf die Wiederherstellung vorzubereiten, konfigurieren Sie Fabric Git-Integration, und synchronisieren Sie Ihre Agentelemente mit Ihrem ADO-Repository, bevor ein Notfall auftritt.

Richten Sie beim Wiederherstellen Ihre neue Region und Kapazität in Fabric ein, und verwenden Sie dann das synchronisierte Repository, um Agentkonfigurationen in einem neuen Arbeitsbereich wiederherzustellen. Git-Synchronisierung ruft die gespeicherten Inhalte aus dem Repository in den leeren Arbeitsbereich ab und erstellt Ihre Agent-Elemente neu.

Nachdem Konfigurationen wiederhergestellt wurden, vergewissern Sie sich, dass auf alle referenzierten Eventhouse-Datenbanken (KQL)-Datenbanken oder regionsspezifischen Datenquellen in der neuen Region zugegriffen werden kann. Aktualisieren Sie Endpunktverweise in Agentkonfigurationen nach Bedarf. Starten Sie schließlich Ihre Agents neu, und lassen Benutzer neue Chatsitzungen initiieren. Frühere Unterhaltungen können nicht fortgesetzt werden.

Transaktionsdatenbank

In diesem Leitfaden werden die Wiederherstellungsprozeduren für das Erlebnis mit der transaktionalen Datenbank 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 datei .bacpac 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 werden, werden nicht in der ursprünglichen Datenbank widergespiegelt. 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 mit 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

Microsoft Fabric Variablenbibliotheken ermöglichen Entwicklern das Anpassen und Freigeben von Elementkonfigurationen innerhalb eines Arbeitsbereichs und optimieren die Verwaltung des Inhaltslebenszyklus. Aus Sicht der Notfallwiederherstellung müssen Benutzer von Variablenbibliotheken proaktiv vor einer regionalen Katastrophe schützen. Dies kann über 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 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.

• 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 Microsoft verwalteten Schlüsseln für ruhende Daten eine zusätzliche Verschlüsselungsebene hinzuzufügen. Falls Fabric in einer Region nicht zugänglich oder funktionsunfähig wird, werden seine Komponenten auf eine Sicherungsinstanz umgeschaltet. 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, wird Fabric weiterhin eine Verbindung mit Ihrem Schlüssel herstellen und es Ihnen ermöglichen, 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.

OneLake

Dieser Abschnitt führt Sie durch die Wiederherstellungsprozeduren für OneLake-Features. Weitere Informationen zur Notfallwiederherstellung für OneLake-Daten finden Sie unter OneLake-Notfallwiederherstellung.

Richtlinien für die Lebenszyklusverwaltung

Falls Fabric in einer Region nicht mehr zugänglich oder funktionsfähig ist, kann Ihre OneLake-Lifecycle-Richtlinie während eines Failovers weiterhin gelesen und aktualisiert werden. Alle Daten, die in die kühle oder kalte Ebene verschoben werden, verbleiben in dieser Ebene. Sie können die folgenden Schritte ausführen, um Ihre vorhandene Richtlinie auf Ihren neuen Wiederherstellungsarbeitsbereich anzuwenden:

1. Rufen Sie die Exportrichtlinie für Ihren ursprünglichen Arbeitsbereich auf, und speichern Sie die gesamte Lebenszyklusrichtlinie.
2. Rufen Sie Import Policy für Ihren wiederhergestellten Arbeitsbereich auf, wobei Ihre exportierte Lebenszyklusrichtlinie den Anforderungstext bildet.

Verwandte Informationen

• Microsoft Fabric Notfallwiederherstellungshandbuch