Erfarenhetsspecifik vägledning för återställning efter katastrof

Det här dokumentet innehåller erfarenhetsspecifik vägledning för att återställa dina Fabric data i händelse av en regional katastrof.

Exempelscenario

Många vägledningsavsnitt i det här dokumentet använder följande exempelscenario för förklaring och illustration. Gå tillbaka till det här scenariot efter behov.

Anta att du har en kapacitet C1 i region A som har en arbetsyta W1. Om du har aktiverat katastrofåterställning för kapacitet C1, replikeras OneLake-data till en säkerhetskopia i region B. Om region A drabbas av störningar, redundansväxlar Fabric-tjänsten i C1 till region B.

Följande bild illustrerar det här scenariot. Rutan till vänster visar det störda området. Rutan i mitten representerar fortsatt tillgänglighet för data efter redundansväxling, och rutan till höger visar den fullständigt täckta situationen när kunden agerar för att återställa sina tjänster till full funktion.

Här är den allmänna återställningsplanen:

1. Skapa en ny Fabric-kapacitet C2 i en ny region.

2. Skapa en ny W2-arbetsyta i C2, inklusive motsvarande objekt med samma namn som i C1. W1.

3. Kopiera data från den störda C1. W1 till C2. W2.

4. Följ de dedikerade anvisningarna för varje komponent för att återställa objekt till deras fullständiga funktion.

Den här återställningsplanen förutsätter att klientorganisationens hemregion förblir i drift. Om klientorganisationens hemregion upplever ett avbrott är de steg som beskrivs i det här dokumentet beroende av dess återställning, som först måste initieras och slutföras av Microsoft.

Erfarenhetsspecifika återställningsplaner

Följande avsnitt innehåller stegvisa guider för varje Fabric upplevelse för att hjälpa kunder genom återställningsprocessen.

Datateknik

Den här guiden vägleder dig genom återställningsprocedurerna för data engineering-upplevelsen. Den täcker sjöhus, anteckningsböcker, Spark-jobbdefinitioner, användardatafunktioner och GraphQL-API:er.

Sjöhus

Lakehouses från den ursprungliga regionen är fortfarande otillgängliga för kunder. För att återställa ett sjöhus kan kunderna återskapa det i arbetsytan C2. W2. Vi rekommenderar två metoder för att återställa sjöhus:

Metod 1: Använda anpassat skript för att kopiera Lakehouse Delta-tabeller och -filer

Kunder kan återskapa lakehouses med hjälp av ett anpassat Scala-skript.

1. Skapa lakehouse (till exempel LH1) i den nyligen skapade arbetsytan C2. W2.

2. Skapa en ny notebook-fil i arbetsytan C2. W2.

3. Om du vill återställa tabellerna och filerna från det ursprungliga sjöhuset läser du data med OneLake-sökvägar som abfss (se Ansluta till Microsoft OneLake). Du kan använda följande kodexempel (se Introduktion till Microsoft Spark Utilities) i notebook för att hämta ABFS-sökvägarna för filer och tabeller från det ursprungliga datahuset. (Ersätt C1. W1 med det faktiska arbetsytans namn)

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

4. Använd följande kodexempel för att kopiera tabeller och filer till det nyligen skapade lakehouse.

   1. För Delta-tabeller måste du kopiera tabell ett i taget för att återställa i det nya sjöhuset. När det gäller Lakehouse-filer kan du kopiera hela filstrukturen med alla underliggande mappar med ett enda utförande.

   2. Kontakta supportteamet för tidsstämpeln för den övergång som krävs i skriptet.

   %%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. När du har kört skriptet visas tabellerna i det nya sjöhuset.

Metod 2: Använd Azure Storage Explorer för att kopiera filer och tabeller

Om du bara vill återställa specifika Lakehouse-filer eller tabeller från det ursprungliga sjöhuset använder du Azure Storage Explorer. Mer information finns i Integrera OneLake med Azure Storage Explorer. För stora datastorlekar använder du Metod 1.

Återställning av materialiserade sjövyer för Fabric

Materialiserade sjövyer från den ursprungliga regionen är fortfarande otillgängliga för kunder efter redundansväxling. Uppdateringsscheman och körningshistorik replikeras inte till den sekundära regionen. Du kan återställa dem genom att utföra följande steg när du har återställt dina Lakehouse-data.

• Återställ Lakehouse-tabellerna med hjälp av metod 1 eller metod 2 som beskrivs ovan. Kopiera endast källtabellerna.
• Återställ de notebook-filer som innehåller dina MLV-definitioner. Se avsnittet Notebook för återställningssteg.
• Kör de återställda notebook-filerna för att återskapa MLV:erna i nya Lakehouse. Information om hur du skapar MLV:er finns i Skapa en materialiserad sjövy. Om MLV:er också kopierades i det tidigare steget kör du CREATE OR REPLACE medan du återskapar dem.
• Återskapa MLV-uppdateringsschemana manuellt på den nya arbetsytan. Schemahistorik och exekveringsmått går inte att återställa.
• Om dina MLV:er används för att mata in information i semantiska modeller eller rapporter, bör du kontrollera och uppdatera lakehouse-ID:t och datamängds-ID:t efter behov. Återanslut rapporter till den uppdaterade semantiska modellen och verifiera datas färskhet.

bärbar dator

Notebook-filer från den primära regionen är fortfarande otillgängliga för kunder och koden i notebook-filer replikeras inte till den sekundära regionen. För att återställa Notebook-koden i den nya regionen finns två metoder för att återställa innehållet i Notebook-kod.

Metod 1: Användarhanterad redundans med Git-integrering (i offentlig förhandsversion)

Det bästa sättet att göra detta enkelt och snabbt är att använda Fabric Git-integrering och sedan synkronisera anteckningsboken med din ADO-lagringsplats. När tjänsten växlar över till en annan region kan du använda förvaringsplatsen för att återskapa notboken i den nya arbetsytan som du skapade.

1. Konfigurera Git-integrering för din arbetsyta och välj Anslut och synkronisera med ADO-lagringsplats.

   

   Följande bild visar den synkroniserade notebook-filen.

   

2. Återställa notebook-filen från ADO-lagringsplatsen.

   1. På den nyligen skapade arbetsytan ansluter du till din Azure ADO-lagringsplats igen.

      

   2. Välj knappen Källkontroll. Välj sedan relevant gren av lagringsplatsen. Välj sedan Uppdatera alla. Den ursprungliga anteckningsboken visas.

      

      

   3. Om den ursprungliga notebook-filen har ett standard lakehouse kan användarna referera till Lakehouse-avsnittet för att återställa lakehouse och sedan ansluta det nyligen återställda lakehouse till den nyligen återställda notebook-filen.

      

   4. Git-integreringen stöder inte synkronisering av filer, mappar eller notebook-ögonblicksbilder i notebook-resursutforskaren.

      1. Om den ursprungliga anteckningsboken har filer i resursutforskaren för anteckningsboken:

         1. Se till att spara filer eller mappar på en lokal disk eller på någon annan plats.

         2. Ladda upp filen igen från din lokala disk eller molndiskar till den återställda anteckningsboken.

      2. Om den ursprungliga notebook-filen har en ögonblicksbild, sparar du även ögonblicksbilden till ditt eget versionskontrollsystem eller din lokala disk.

         

         

Mer information om Git-integrering finns i Introduktion till Git-integrering.

Metod 2: Manuell metod för att säkerhetskopiera kodinnehåll

Om du inte använder Git-integreringsmetoden kan du spara den senaste versionen av din kod, filer i resursutforskaren och ögonblicksbilden av notebook-filer i ett versionskontrollsystem som Git och manuellt återställa notebook-innehållet efter ett haveri:

1. Använd funktionen "Importera anteckningsbok" för att importera den notebook-kod som du vill återställa.

   

2. Efter importen går du till önskad arbetsyta (till exempel "C2. W2") för att komma åt den.

3. Om den ursprungliga notebook-filen har ett standardlakehouse, se avsnittet Lakehouse. Anslut sedan det nyligen återställda lakehouse (som har samma innehåll som det ursprungliga standard lakehouse) till den nyligen återställda notebook-filen.

4. Om den ursprungliga notebook-filen har filer eller mappar i resursutforskaren laddar du upp filerna eller mapparna som sparats i användarens versionskontrollsystem igen.

Definition av Spark-jobb

Spark-jobbdefinitioner (SJD) från den primära regionen är fortfarande otillgängliga för kunderna, och huvuddefinitionsfilen och referensfilen i anteckningsboken replikeras till den sekundära regionen via OneLake. Om du vill återställa SJD i den nya regionen kan du följa de manuella stegen nedan för att återställa SJD. Historiska körningar av SJD återskapas inte.

Du kan återställa SJD-objekten genom att kopiera koden från den ursprungliga regionen med hjälp av Azure Storage Explorer och manuellt återansluta Lakehouse-referenser efter katastrofen.

1. Skapa ett nytt SJD-objekt (till exempel SJD1) i den nya arbetsytan C2. W2, med samma inställningar och konfigurationer som det ursprungliga SJD-objektet (till exempel språk, miljö osv.).

2. Använd Azure Storage Explorer för att kopiera Libs, Mains och Snapshots från det ursprungliga SJD-objektet till det nya SJD-objektet.

   

3. Kodinnehållet visas i den nyligen skapade SJD:en. Du måste manuellt lägga till den nyligen återställda Lakehouse-referensen till jobbet (se Återställningsstegen för Lakehouse). Användarna måste ange de ursprungliga kommandoradsargumenten manuellt.

   

Nu kan du köra eller schemalägga din nyligen återställda SJD.

Mer information om Azure Storage Explorer finns i Integrate OneLake med Azure Storage Explorer.

Användardatafunktioner

För att återställa dina användardatafunktioner i ett hälsosamt område, använd en av följande metoder.

Metod 1: Med Git-integration (rekommenderas)

Den föredragna återhämtningsmekanismen är Fabric Git-integration. Genom att synkronisera användardatafunktionsprojekt med ett Azure DevOps- eller GitHub-repository kan du snabbt rekonstruera dem i en ny arbetsyta efter failover.

Förbered dig inför en katastrof

1. Konfigurera Fabric Git-integration för arbetsytan som är värd för användardatafunktionen.
2. Koppla arbetsytan till ett Azure DevOps- eller GitHub-arkiv.
3. Sätt all användardatafunktion i arkivet och synkronisera ändringar regelbundet.
4. Spara miljöspecifika inställningar separat i variabelbibliotek om det behövs.

Återställningssteg

Efter en regional katastrof:

1. Skapa en ny Fabric-kapacitet i en hälsosam region, som C2.
2. Skapa en ny arbetsyta, som W2, i den nya kapaciteten.
3. Koppla arbetsytan till samma Azure DevOps- eller GitHub-repository.
4. Öppna Källkontroll och synkronisera innehållet i lagringsplatsen med arbetsytan.
5. Återskapa eller återställ alla beroende Fabric-resurser, till exempel lakehouses, SQL-databaser i Fabric, datalager och Business Events.
6. Omdistribuera användardatafunktionerna.
7. Validera funktionsexekvering och beroendekoppling.
8. Uppdatera nedströmsapplikationer, datapipelines eller andra integrerade system så att de hänvisar till de återställda funktionerna.
9. Fullständig fullständig validering av alla dina scenarier.

Viktiga överväganden

• Git-integration återställer endast källkod och projektresurser.
• Historiska avrättningsloggar återfinns inte.
• Nedströmssystem kan kräva ombindning av slutpunkter.

För mer information, se Källkodshantering och distribution för användardatafunktioner.

Metod 2: Manuell återhämtning

Om Git-integrationen inte konfigurerades före katastrofen kan du manuellt rekonstruera användardatafunktioner från källkodsbackuper.

Förbered dig inför en katastrof

Utför regelbundet följande uppgifter och lagra artefakterna i ett externt versionshanteringsarkiv eller en backupplats:

• Exportera källkoden för funktionen till ett GitHub-arkiv.
• Dokumentera och bevara beroendeinformation.
• Dokumentmiljöinställningar.

Återställningssteg

Efter en regional katastrof:

1. Skapa en ny Fabric-kapacitet i en hälsosam region, som C2.
2. Skapa en ny arbetsyta, till exempel W2.
3. Återställ alla resurser som krävs av funktionen, inklusive lakehouses, SQL-databaser i Fabric, lagerlokaler, eventhouses och externa tjänster.
4. Skapa ett nytt projekt för användardata.
5. Importera eller återskapa funktionens källkod.
6. Tillämpa körningskonfigurationsinställningarna igen.
7. Installera om alla funktionsberoenden.
8. Omdistribuera funktionen.
9. Konfigurera om autentisering och auktorisation.
10. Återskapa utgivare eller konsumenter för affärshändelser, om sådana används.
11. Genomför end-to-end-valideringstester för dina scenarier och integrationer.

GraphQL

GraphQL-objekt från den primära regionen är inte tillgängliga efter en regional katastrof och GraphQL-definitioner och konfigurationer replikeras inte till den sekundära regionen. Om du vill återställa GraphQL i en ny region använder du någon av följande metoder.

Metod 1: Användarstyrd redundans med Git-integration

Det bästa sättet att göra den här processen enkel och snabb är att använda Fabric Git-integrering och sedan synkronisera GraphQL med din ADO-lagringsplats. När tjänsten växlar över till en annan region kan du använda repot för att bygga upp GraphQL på nytt i den nya arbetsyta som du skapade.

1. Skapa en ny arbetsyta i målkapaciteten och regionen.

2. Återställ alla beroende datakällor, till exempel Lakehouse-, Warehouse- eller SQL-databaser, genom att följa respektive återställningssteg.

3. Uppdatera GraphQL-definitionen så att den pekar på de nyligen återställda resurserna genom att ändra miljöspecifika referenser som källarbetsyte-ID:n, källartefakt-ID:n och anslutningsinformation. Det här steget säkerställer korrekt bindning vid distributionstillfället.

4. Distribuera om GraphQL-artefakter från Git-lagringsplatsen till den nya arbetsytan. Det här steget återskapar API-strukturen och konfigurationen med hjälp av de uppdaterade definitionerna.

5. Använd artefaktinställningar igen, inklusive roller, åtkomstkontroller och autentiseringskonfiguration.

6. Tillämpa slutpunktsreferenser igen genom att uppdatera program eller integreringar för att använda den nyligen skapade GraphQL-slutpunkten.

7. Uppdatera alla befintliga distributionspipelines som pekade på den gamla arbetsytan så att de hänvisar till den nyligen skapade arbetsytan.

8. Verifiera funktionerna från slutpunkt till slutpunkt för API:et.

Metod 2: Manuell metod

Om du inte använder Git-integreringsmetoden kan du använda följande manuella metod för att återställa GraphQL.

1. Skapa en ny arbetsyta i målkapaciteten och regionen.

2. Återställa alla beroende datakällor, till exempel Lakehouse-, Warehouse- eller SQL-databaser.

3. Återskapa GraphQL-API:et manuellt på den nya arbetsytan, inklusive schemadefinitioner, datakällanslutningar och relationer.

4. Använd artefaktinställningar igen, inklusive roller, åtkomstkontroller och autentiseringskonfiguration.

5. Tillämpa slutpunktsreferenser igen genom att uppdatera program eller integreringar för att använda den nyligen skapade GraphQL-slutpunkten.

6. Uppdatera alla befintliga distributionspipelines som pekade på den gamla arbetsytan så att de hänvisar till den nyligen skapade arbetsytan.

7. Verifiera funktionerna från slutpunkt till slutpunkt för API:et.

Viktiga överväganden

1. GraphQL förlitar sig på externa beroenden (till exempel Lakehouse, Warehouse och SQL), som du måste återställa före GraphQL-distributionen.

2. GraphQL API-definitioner innehåller miljöspecifika referenser (till exempel sourceWorkspaceId och sourceItemId). När du återställer i en ny region kan dessa referenser bli ogiltiga. Uppdatera dem så att de pekar på nyligen etablerade resurser.

3. Automatisk ombindning av datakällor garanteras inte i haveriberedskapsscenarier, särskilt när du använder sparade autentiseringsuppgifter eller anslutningar mellan arbetsytor.

4. Andra artefaktinställningar som övervakning, auktorisering, RBAC, introspektion med mera följer inte med vid felväxling. Du måste återupprätta de här inställningarna i den nya regionen.

References

• Översikt över Fabric Git-integrering – Microsoft Fabric | Microsoft Learn

• Pipelines för källkontroll och distribution i API för GraphQL – Microsoft Fabric | Microsoft Learn 

App

Systemet replikerar inte Fabric Apps, inklusive deras kod, konfiguration och metadata, till sekundära regioner. Om primärregionen misslyckas förblir appen otillgänglig. För återställning, lagra appens källkod utanför systemet i GitHub, Azure DevOps eller något annat källkontrollsystem. Återställ appdata separat genom att följa riktlinjerna för katastrofåterställning för varje underliggande Fabric-datalager.

Manuell strategi

Du kan manuellt återställa en Fabric App efter en regional katastrof genom att använda applikationens källkod och Rayfin CLI. 

Prerequisites 

Innan en katastrof inträffar:

• Lagra Fabric App-källkoden i GitHub, Azure DevOps eller ett annat källkontrollarkiv. 

• Dokumentera processen för återhämtning.  

Återhämtningssteg 

1. Skapa en ny arbetsyta i målkapaciteten och regionen. 

2. Återställ beroende resurser innan du distribuerar applikationen igen.  

3. Hämta den senaste källkoden för Fabric App från ditt versionskontrollarkiv eller lokal backup. 

4. Från applikationskällskatalogen distribuerar du Fabric App till återställningsarbetsytan genom att använda Rayfin CLI. Kör rayfin up --workspace <new workspace>. 

5. Återställ appens barnobjekt (Fabric SQL Database) genom att följa dess respektive återställningsprocedurer.  

6. Applicera artefaktnivåinställningar igen, inklusive roller och åtkomstkontroller vid behov.  

7. Verifiera applikationens funktionalitet och se till att användarna har rätt behörigheter.  

Viktigt 

• Underhåll källkoden för Fabric App utanför Fabric-regionen för att möjliggöra återställning.  

• Applikationsdata i databasen återställs inte som en del av Fabric App-distributionsprocessen och måste återställas separat.  Du kan manuellt återställa en Fabric App efter en regional katastrof genom att använda applikationens källkod och Rayfin CLI. 

Datavetenskap

Den här guiden vägleder dig genom återställningsprocedurerna för Data Science-upplevelse. Den omfattar ML-modeller och experiment.

ML-modell och experiment

Data Science-artiklar från den primära regionen är fortsatt otillgängliga för kunder, och data och metadata i ML-modeller och experiment kommer inte att replikeras till den sekundära regionen. Om du vill återställa dem helt i den nya regionen sparar du kodinnehållet i ett versionskontrollsystem (till exempel Git) och kör kodinnehållet igen manuellt efter katastrofen.

1. Återställ anteckningsboken. Se Notebook-återställningssteg.

2. Konfiguration, historiska körningsmått och metadata replikeras inte till den associerade regionen. Du måste köra om varje version av din datavetenskapskod för att helt återställa ML-modeller och experiment efter katastrofen.

Datalager

Den här guiden vägleder dig genom återställningsprocedurerna för Data Warehouse upplevelse. Den täcker lagerbyggnader.

Lager

Lager från den ursprungliga regionen är fortfarande otillgängliga för kunder. Använd följande två steg för att återställa lager.

1. Skapa ett nytt interim lakehouse i arbetsytan C2.W2 för de data som du kopierar över från det ursprungliga lagret.

2. Fyll i informationslagrets Delta-tabeller genom att utnyttja funktionerna i warehouse Explorer och T-SQL (se Tabeller i datalager i Microsoft Fabric).

Datainmatning via Lakehouse- och T-SQL-kod

I nyskapade arbetsytan C2. W2:

1. Skapa ett interim lakehouse "LH2" i C2.W2.

2. Återställ Delta-tabellerna i det tillfälliga lakehouse från det ursprungliga lagret genom att följa stegen för återställning av lakehouse.

3. Skapa ett nytt lager "WH2" i C2. W2.

4. Anslut det temporära lakehouse i din databasutforskare.

5. Beroende på hur du ska distribuera tabelldefinitioner före dataimporten kan den faktiska T-SQL som används för import variera. Du kan använda metoden INSERT INTO, SELECT INTO eller CREATE TABLE AS SELECT för att återställa lagertabeller från lakehouses. Vidare i exemplet skulle vi använda INSERT INTO i relation till flavor. (Om du använder koden nedan ersätter du exempel med faktiska tabell- och kolumnnamn)

   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. Slutligen ändrar du anslutningssträngen i program som använder ditt Fabric-datalager.

Speglad databas

Speglade databaser från den primära regionen är fortfarande inte tillgängliga för kunder och inställningarna replikeras inte till den sekundära regionen. Om du vill återställa den i händelse av ett regionalt fel måste du återskapa den speglade databasen på en annan arbetsyta från en annan region.

Data Factory

Data Factory-objekt från den primära regionen är fortfarande inte tillgängliga för kunder och inställningarna och konfigurationen i pipelines eller dataflöde gen2-objekt replikeras inte till den sekundära regionen. Om du vill återställa dessa objekt i händelse av ett regionalt fel måste du återskapa dina Dataintegration objekt på en annan arbetsyta från en annan region. I följande avsnitt beskrivs informationen.

Dataflöden Gen2

Om du vill återställa ett Dataflow Gen2-objekt i den nya regionen måste du exportera en PQT-fil till ett versionskontrollsystem som Git och sedan återställa Dataflow Gen2-innehållet manuellt efter katastrofen.

1. På fliken Start i Power Query-redigeraren, välj Exportmallen från ditt Dataflow Gen2-objekt.

   

2. I dialogrutan Exportera mall anger du ett namn (obligatoriskt) och en beskrivning (valfritt) för den här mallen. När du är klar klickar du på OK.

   

3. Efter katastrofen skapar du ett nytt Dataflow Gen2-objekt i den nya arbetsytan "C2. W2".

4. Välj Importera från en Power Query-mall i det aktuella visningsfönstret i Power Query-redigeraren.

   

5. I dialogrutan Öppna bläddrar du till din standardmapp för nedladdningar och väljer den .pqt-fil som du sparade i föregående steg. Välj sedan Öppna.

6. Mallen importeras sedan till ditt nya Dataflow Gen2-objekt.

Funktionen Spara som för dataflöden stöds inte vid katastrofåterställning.

Pipelines

Kunder kan inte komma åt pipelines i händelse av regional katastrof och konfigurationerna replikeras inte till den kopplade regionen. Vi rekommenderar att du skapar kritiska pipelines på flera arbetsytor i olika regioner.

Kopiera jobb

CopyJob-användare måste vidta proaktiva åtgärder för att skydda mot en regional katastrof. Följande metod säkerställer att en användares CopyJobs förblir tillgängliga efter en regional katastrof.

Användarhanterad redundans med Git-integrering (i offentlig förhandsversion)

Det bästa sättet att göra den här processen enkel och snabb är att använda Fabric Git-integrering och sedan synkronisera ditt CopyJob med din ADO-lagringsplats. När tjänsten växlar över till en annan region kan du använda förvaret för att återskapa CopyJob i den nya arbetsytan du skapade.

1. Konfigurera git-integreringen för arbetsytan och välj ansluta och synkronisera med ADO-lagringsplatsen.

   

   Följande bild visar det synkroniserade CopyJob.

   

2. Återställ CopyJob från ADO-lagringsplatsen.

   1. På den nyligen skapade arbetsytan ansluter du och synkroniserar till din Azure ADO-lagringsplats igen. Alla Fabric objekt på den här lagringsplatsen laddas ned automatiskt till din nya arbetsyta.

      

   2. Om det ursprungliga CopyJob använder ett Lakehouse kan användarna referera till avsnittet Lakehouse för att återställa Lakehouse och sedan ansluta det nyligen återställda CopyJob till det nyligen återställda Lakehouse.

Mer information om Git-integrering finns i Introduktion till Git-integrering.

Apache Airflow-uppgift

Användare av Apache Airflow-jobb i Fabric måste vidta proaktiva åtgärder för att skydda mot en regional katastrof.

Vi rekommenderar att du hanterar redundans med Fabric Git-integrering. Synkronisera först airflow-jobbet med din ADO-lagringsplats. Om tjänsten redundansväxlar till en annan region kan du använda lagringsplatsen för att återskapa Airflow-jobbet på den nya arbetsytan som du skapade.

Här är stegen för att uppnå detta:

1. Konfigurera git-integreringen för arbetsytan och välj "anslut och synkronisera" med ADO-lagringsplatsen.

2. Därefter ser du att ditt Airflow-jobb har synkroniserats till din ADO-lagringsplats.

3. Om du behöver återställa Airflow-jobbet från ADO-lagringsplatsen skapar du en ny arbetsyta, ansluter och synkroniserar till din Azure ADO-lagringsplats igen. Alla Fabric objekt, inklusive Airflow, på den här lagringsplatsen laddas ned automatiskt till din nya arbetsyta.

Realtidsinformation

Den här guiden vägleder dig genom återställningsprocedurerna för realtidsinformationsupplevelsen. Den omfattar KQL-databaser/frågeuppsättningar och eventstreams.

Activator

Aktivatorobjekt från den primära regionen är fortfarande inte tillgängliga för kunder, och Utlösardefinitioner för Aktivering replikeras inte till den sekundära regionen. Användare av Activator måste vidta proaktiva åtgärder för att förbereda sig inför regional katastrofåterställning.

För att säkerställa att du kan återställa Aktivatorobjekt i händelse av en regional katastrof konfigurerar du Fabric Git-integrering för att säkerhetskopiera utlösardefinitioner och återställa dem på en arbetsyta i en annan region.

1. Konfigurera Fabric Git-integrering för arbetsytan som innehåller ditt Activator-objekt och synkronisera dina utlösardefinitioner med din Git-lagringsplats.
2. Behåll aktiveringsutlösarens definitioner bekräftade och synkroniserade regelbundet.
3. Under återställningen skapar du en ny arbetsyta i målregionen (C2. W2), anslut den till samma lagringsplats och synkronisera för att återställa utlösardefinitionerna.
4. Konfigurera om och verifiera alla aktivatordatakällor och beroenden i den nya arbetsytan.

Mer information om Git-integrering finns i Introduktion till Git-integrering.

Grafmodell/frågesamling

Graph Model- och Graph Queryset-objekt från den primära regionen är fortfarande inte tillgängliga för kunder och dessa objekt replikeras inte till den sekundära regionen. För att återställa, skapa eller använd en kapacitet i en annan region och återskapa objekten Graph Model och Graph Queryset där.

1. Skapa eller använd en befintlig Fabric kapacitet i en annan region som inte påverkas av katastrofen.

2. Skapa en ny arbetsyta eller använd en befintlig arbetsyta i den kapaciteten.

3. Återskapa Graph Model-objektet på den sekundära arbetsytan (refereras i steg 2). Konfigurera om modelldefinitionen, inklusive noder, kanter osv., så att den matchar den ursprungliga Graph-modellen.

4. Om det ursprungliga sjöhuset finns i den misslyckade regionen kan du återställa det först genom att följa Lakehouse-avsnittet.

5. Anslut ett lakehouse som OneLake-datakälla för det nyligen skapade Graph Model-objektet. Använd det återställda sjöhuset om det fanns i den misslyckade regionen eller återansluta till det befintliga sjöhuset om det förblir tillgängligt.

6. Konfigurera om datainläsningsscheman eller anslutningar för Graph Model på den nya arbetsytan.

7. Återskapa objektet Graph Queryset på den sekundära arbetsytan. Ange frågorna och eventuella sparade frågekonfigurationer manuellt från den ursprungliga Graph Queryset.

KQL-databas/frågeuppsättning

KQL-databas-/frågeuppsättningsanvändare måste vidta proaktiva åtgärder för att skydda mot en regional katastrof. Följande metod säkerställer att data i KQL-databasernas frågeuppsättningar förblir säkra och tillgängliga i händelse av en regional katastrof.

Använd följande steg för att garantera en effektiv haveriberedskapslösning för KQL-databaser och frågeuppsättningar.

1. Establish independent KQL databases: Konfigurera två eller flera oberoende KQL-databaser/frågeuppsättningar på dedikerade Fabric kapaciteter. Dessa bör konfigureras i två olika Azure-regioner (helst Azure-parkopplade regioner) för att maximera resiliens.

2. Replikera hanteringsaktiviteter: Alla hanteringsåtgärder som vidtas i en KQL-databas bör speglas i den andra. Detta säkerställer att båda databaserna förblir synkroniserade. Viktiga aktiviteter som ska replikeras är:

   • Tabeller: Kontrollera att tabellstrukturerna och schemadefinitionerna är konsekventa mellan databaserna.

   • Mappning: Duplicera alla nödvändiga mappningar. Se till att datakällor och destinationer överensstämmer korrekt.

   • Principer: Kontrollera att båda databaserna har liknande datakvarhållning, åtkomst och andra relevanta principer.

3. Hantera autentisering och auktorisering: Konfigurera nödvändiga behörigheter för varje replik. Se till att rätt auktoriseringsnivåer har fastställts, vilket ger åtkomst till den personal som krävs samtidigt som säkerhetsstandarderna upprätthålls.

4. Parallell datainmatning: Om du vill hålla data konsekventa och redo i flera regioner läser du in samma datauppsättning i varje KQL-databas samtidigt som du matar in den.

Evenemangsström

En händelseström är en central plats i Fabric plattform för att samla in, transformera och dirigera realtidshändelser till olika mål (till exempel lakehouses, KQL-databaser/frågeuppsättningar) med en kodfri upplevelse. Så länge som destinationerna stöds av katastrofåterställning förlorar inte eventstreams data. Därför bör kunderna använda haveriberedskapsfunktionerna i dessa målsystem för att garantera datatillgänglighet.

Kunder kan också uppnå geo-redundans genom att distribuera identiska Eventstream-arbetsbelastningar i flera Azure regioner som en del av en aktiv/aktiv strategi för flera platser. Med en aktiv/aktiv metod för flera platser kan kunderna komma åt sin arbetsbelastning i någon av de distribuerade regionerna. Den här metoden är den mest komplexa och kostsamma metoden för haveriberedskap, men det kan minska återställningstiden till nära noll i de flesta situationer. För att vara helt geo-redundanta kan kunderna

1. Skapa repliker av deras datakällor i olika regioner.

2. Skapa Eventstream-objekt i motsvarande regioner.

3. Anslut dessa nya objekt till identiska datakällor.

4. Lägg till identiska mål för varje händelseström i olika regioner.

Affärshändelser, Fabric händelser och Azure händelser

Även om affärshändelser, Fabric-händelser och Azure-händelser delar samma Real-Time Hub-infrastruktur i Microsoft Fabric har de olika ursprung, beteenden och krav för katastrofåterställning som du måste förstå innan du planerar för katastrofåterställning:

• Fabric-händelser är händelseprenumerationer som reagerar på aktivitet som genereras av Fabric-resurserna själva, inklusive livscykeländringar för objekt i arbetsytan (till exempel att skapa, uppdatera eller ta bort lakehouses, anteckningsböcker eller datavarulager), jobbkörningar (till exempel pipelinekörningar eller körningar av anteckningsböcker) samt fil- och mappåtgärder i OneLake. Dessa prenumerationer är push-baserade och tillfälliga. Prenumerationerna replikeras inte till den sekundära regionen.

• Azure Händelser är händelseprenumerationer på aktiviteter som skapats av Azure Blob Storage konton. Dessa Azure resurser finns oberoende av någon Fabric kapacitet eller region. Även om själva Azure Blob Storage resursen kan vara tillgänglig under ett Fabric regionalt avbrott, replikeras inte prenumerationerna som konfigurerats i Real-Time hubb till den sekundära regionen och måste återskapas.

• Affärshändelser är en distinkt funktion i Fabric Real-Time Intelligence som gör det möjligt för team att definiera, publicera och agera på meningsfulla affärssignaler. Affärshändelser genereras inifrån Fabric via Activator, Spark Notebooks eller User Data Functions, och publiceras sedan till Real-Time hubb där nedströmsanvändare som Activator, Eventhouse eller Power Automate kan reagera på dem. Händelsescheman styrs centralt genom Schema Registry. Eventhouse lagrar automatiskt varje publicerad affärshändelse, så dess återställning påverkar direkt tillgängligheten för affärshändelsehistorik. Ingen av utgivar- eller konsumentkonfigurationerna, schemadefinitionerna eller prenumerationerna replikeras till den sekundära regionen.

Använd följande steg för att återställa Business Events, Fabric-händelser och Azure-händelser i den nya arbetsytan i återställningsregionen.

För affärshändelser:

1. Återskapa affärshändelsen som används av utgivare och konsumenter genom att följa artikeln Skapa affärshändelser i Fabric Real-Time Hub. När du skapar affärshändelsen skapar du resursen Händelseschemauppsättning. Eventhouse-resursen är valfri beroende på scenariot. Om du säkerhetskopierade din händelseschema-uppsättning med Git-integration, återställ den först genom att följa avsnittet för händelseschema-uppsättningen, och peka sedan affärshändelsen mot den återställda schema-uppsättningen.

2. Återskapa alla utgivarobjekt som genererar affärshändelser, till exempel Spark-notebook-filer eller användardatafunktioner, i den nya arbetsytan genom att följa de här artiklarna: Använd användardatafunktion som utgivare för affärshändelser, Använd Activator som utgivare för affärshändelser, Använd Notebook som utgivare för affärshändelser och Använd Eventstream som utgivare för affärshändelser.

3. Återskapa konsumentprenumerationerna i Real-Time-hubben (till exempel Activator-regler, anteckningsboksutlösare eller Power Automate-flöden) som ursprungligen reagerade på affärshändelser i den berörda regionen med hjälp av artiklarna Eventhouse och integrering av Real-Time-dashboard med affärshändelser och Använd affärshändelser från Activator.

4. Kontrollera att händelser flödar från slutpunkt till slutpunkt genom att kontrollera att prenumerationer är aktiva och att data anländer till de förväntade destinationerna i återställningsregionen.

För Fabric händelser:

1. Återskapa prenumerationerna i Real-Time Hub som pekar mot objekten i arbetsytan, jobb eller OneLake-sökvägar som återställdes i återställningsregionen genom att följa anvisningarna i artikeln Utforska Fabric-händelser i Fabric Real-Time Hub.

2. Kontrollera att händelser flödar från slutpunkt till slutpunkt genom att kontrollera att prenumerationer är aktiva och att data anländer till de förväntade destinationerna i återställningsregionen.

För Azure händelser:

1. Azure Blob Storage konton påverkas inte av ett Fabric regionalt avbrott. Återskapa händelseprenumerationerna i Real-Time hubb som pekar på samma Azure Blob Storage konton genom att följa artikeln Ange aviseringar för Azure Blob Storage händelser i Real-Time hubb.

2. Kontrollera att händelser flödar från slutpunkt till slutpunkt genom att kontrollera att prenumerationer är aktiva och att data anländer till de förväntade destinationerna i återställningsregionen.

Händelseschemauppsättning

En händelseschemamängd är den Fabric delen som innehåller händelsetyp- och schemadefinitioner i Real-Time Intelligence. Andra funktioner bygger vidare på den: utgivare skriver händelser som följer dess scheman, och konsumenter läser enligt samma definitioner.

Händelsescheman från primärregionen förblir otillgängliga för kunder, och de replikeras inte till sekundärregionen. Men eftersom en händelseschema-uppsättning är en hållbar definierad definition snarare än en flyktig prenumeration, kan du säkerhetskopiera den i förväg och återställa den istället för att återskapa den för hand.

Rekommenderas: säkerhetskopiera med Fabric Git-integration

För att återställa ett händelseschema efter en regional katastrof, sätt upp Fabric Git-integration innan en katastrof inträffar och synkronisera arbetsytan som innehåller dina händelseschema-uppsättningar med ditt Git-repository.

1. Konfigurera Fabric Git-integration för arbetsytan som innehåller din event schema-uppsättning och synkronisera den med ditt Git-repository.

2. Se till att uppsättningen händelsescheman checkas in och synkroniseras regelbundet, särskilt efter att händelsetyper har lagts till eller nya schemaversioner har publicerats.

3. Under återställningen skapar du en ny arbetsyta i målregionen (C2. W2), koppla den till samma repository och synka för att återställa händelseschemaset. Eftersom den nya arbetsytan är tom tar Git Sync innehållet från arkivet in i arbetsytan.

4. Återskapa alla publicister och konsumenter som använder schema-uppsättningen, enligt riktlinjerna för dessa objekttyper.

5. Verifiera att utgivare kan publicera mot de återställda händelsetyperna och att konsumenter får händelser som förväntat.

Den synkroniserade definitionen inkluderar händelsetyperna i schemamängden, scheman och schemaversionerna. Den inkluderar inte utgivarregistreringar, konsumentprenumerationer eller evenemangshistorik. Återställ dessa separat, enligt riktlinjerna för de objekttyper som använder schemasetet.

Alternativ: återskapa manuellt

Om du inte konfigurerade Git-integration före katastrofen, återskapa händelseschema-setet i återställningsregionen genom att följa Create and manage event schema sets, och lägg sedan till händelsetyperna och scheman som det ursprungliga schema-setet innehöll genom att följa Create and manage event schemas in schema sets.

Map

Mappningsobjekt från den primära regionen är fortfarande inte tillgängliga för kunder och mappningsobjekten replikeras inte till den sekundära regionen.

Om du vill återställa ett mappningsobjekt när ett haveri inträffar konfigurerar du Fabric Git-integrering och synkronisera kartobjektet med git-lagringsplatsen.

När det nya regionen/kapaciteten i Fabric har konfigurerats under återhämtningsprocessen kan du använda arkivet för att återskapa kartobjektet i den nya arbetsytan som skapades. Eftersom den nya arbetsytan är tom hämtar Git sync innehållet från lagringsplatsen till den tomma arbetsytan. Det här steget ger liv åt kartobjektet igen.

Ontologi

Ontologianvändare måste vidta proaktiva åtgärder för att förbereda sig för regional katastrofåterhämtning. Den metod som beskrivs nedan säkerställer att ontologin efter en regional katastrof förblir återställningsbar och kan återställas snabbt.

Det enklaste och snabbaste sättet att aktivera återställning är att använda Fabric Git-integrering och synkronisera din ontologi med en Azure DevOps-lagringsplats (ADO). Om tjänsten växlar till en reservregion kan du använda den här lagringsplatsen för att återskapa ontologin i en nyskapad arbetsyta.

Ontologiobjekt i den primära regionen är inte tillgängliga för kunder efter en regional katastrof och Ontologiobjekt replikeras inte till den sekundära regionen.

Om du vill återställa ett ontologiobjekt under en katastrof konfigurerar du Fabric Git-integrering och synkronisera ontologiobjektet med din ADO-lagringsplats i förväg.

När den nya regionen och kapaciteten i Fabric har konfigurerats under återställningen kan du använda lagringsplatsen för att återskapa ontologiobjektet på en ny arbetsyta. Eftersom den nya arbetsytan är tom hämtar Git sync innehållet från lagringsplatsen till arbetsytan och återställer effektivt ontologiobjektet.

Planning

Den här artikeln beskriver återhämtningsprocedurerna för planeringsupplevelsen i IQ. Den beskriver de steg som krävs för att återställa nyckelkomponenter, inklusive planeringsblad, PowerTable-blad, intelligensblad, InfoBridge och relaterade datatillgångar.

Git-integrering för att återställa planobjekt

Den bästa metoden är att synkronisera alla planobjekt med en Azure DevOps (ADO) eller GitHub lagringsplats med hjälp av Fabric Git-integrering. Efter en redundansväxling använder du lagringsplatsen för att återställa objekten på den nya arbetsytan.

Före en katastrof (proaktiva åtgärder):

1. I arbetsytan W1 går du till Arbetsyteinställningar och konfigurerar Git-integrering.

2. Välj Anslut och synkronisera med din ADO eller GitHub lagringsplats.

3. Välj de objekt i planen som ska laddas upp till lagringsplatsen och välj Commit.

   

4. Bekräfta att Git-statusen för planobjekt är Synkroniserad.

5. Inför en disciplinerad commit-rutin – gör en commit efter varje betydande ändring i en plandefinition så att repositoryt alltid återspeglar det senaste tillståndet.

Återställningssteg:

1. Skapa en ny arbetsyta W2 i kapaciteten C2 i den felfria regionen.

2. I arbetsytan W2 går du till Arbetsyteinställningar och återansluter till samma ADO/GitHub-lagringsplats.

3. Välj Källkontroll. Välj relevant lagringsplatsgren och välj Uppdatera alla. Alla planobjekt laddas ned till W2.

Följande komponenter återställs efter återställning:

• PowerTable-blad: Inställningar för källtabeller, kolumnkonfiguration, radåtkomst, visuella egenskaper (layout, format med mera), radidentifiering, kommentarsinställningar, långsamt föränderliga dimensioner (SCD), godkännanden, automatiseringar och formulär.
• Planeringsblad: Bladegenskaper (formatering, villkorsstyrd formatering med mera), kommentarsinställningar, tillbakaskrivningsinställningar, dataindatakolumner, dataindatarader, scenarier och bokmärken.
• InfoBridge: InfoBridge-källor, InfoBridge-frågor, omvandlingssteg, tillbakaskrivningsmål, tillbakaskrivningsinställningar, länkade frågemappningar, frågegrupper, visuella egenskaper (blandning). Det går inte att återställa dessa objekt: filbaserade källor (CSV, Excel), blad för flera arbetsbelastningar som använder filbaserade källor.
• Intelligens: Alla diagram och matriser.

Återställning av SQL i Fabric för planering

Data som anges i planeringsblad, tabeller som används i PowerTable och tillbakaskrivningsdata lagras i SQL-databaser och måste betraktas som en del av din strategi för haveriberedskap. Information om hur du återställer SQL-databaser finns i avsnittet SQL-databas .

• Metadata för återställningsplan: Varje planobjekt är associerat med en __fabric_plan_sys databas som lagrar metadata för planeringsfunktioner, inklusive kommentarer, scenarier, dataindata och konfiguration av tillbakaskrivning. Den __fabric_plan_sys databasen återställs inte automatiskt och måste återställas uttryckligen.

• Återställa tillbakaskrivningsdatabaser: Om planen använder SQL-tillbakaskrivningsmål måste du även återställa de associerade databaserna manuellt. Konfigurerade SQL-tillbakaskrivningsmål återställs inte automatiskt.

• Återställ tabeller som används i PowerTable: Alla tabeller som skapas med powertable lagras i en Fabric SQL-databas. Du måste också återställa dessa tabeller vid DR.

Driftagenter

Användare av driftagenten bör vidta proaktiva åtgärder för att förbereda sig för regional katastrofåterställning. Genom att följa den metod som beskrivs i det här avsnittet ser du till att dina agenter kan återställas snabbt efter ett regionalt avbrott.

Använd Fabric Git-integrering för att synkronisera din arbetsyta med en lagringsplats. Med den här metoden kan du rekonstruera agentkonfigurationer på en ny arbetsyta om tjänsten redundansväxlar till en annan region.

Operations Agent-objekt i primärregionen är inte tillgängliga vid en regional katastrof. Agentkonfigurationer, beteendemodeller och aktivitetsloggar replikeras inte till den sekundära regionen. Pågående åtgärder, aktiva chattsessioner och tidigare inmatade händelser vid tidpunkten för katastrofen går också förlorade.

För att förbereda för återställning konfigurerar du Fabric Git-integrering och synkroniserar dina agentobjekt med ADO-lagringsplatsen innan ett haveri inträffar.

När du återställer konfigurerar du din nya region och kapacitet i Fabric och använder sedan den synkroniserade lagringsplatsen för att återställa agentkonfigurationer till en ny arbetsyta. Git Sync hämtar det lagrade innehållet från lagringsplatsen till den tomma arbetsytan och återskapar dina agentobjekt.

När konfigurationerna har återställts kontrollerar du att alla refererade Eventhouse-databaser (KQL) eller regionspecifika datakällor är tillgängliga i den nya regionen. Uppdatera slutpunktsreferenser i agentkonfigurationer efter behov. Starta slutligen om dina agenter och låt användarna initiera nya chattsessioner. Tidigare konversationer kan inte återupptas.

Transaktionsdatabas

Den här guiden beskriver återställningsprocedurerna för transaktionsdatabasupplevelsen.

SQL database

För att skydda mot ett regionalt fel kan användare av SQL-databaser vidta proaktiva åtgärder för att regelbundet exportera sina data och använda exporterade data för att återskapa databasen på en ny arbetsyta när det behövs.

Detta kan uppnås med hjälp av SQLPackage CLI-verktyget som ger databasportabilitet och underlättar databasdistributioner.

1. Använd SqlPackage-verktyget för att exportera databasen till en .bacpac fil. Mer information finns i Exportera en databas med SqlPackage .
2. .bacpac Lagra filen på en säker plats som finns i en annan region än databasen. Exempel är att lagra filen .bacpac i en Lakehouse som finns i en annan region, använda ett geo-redundant Azure Storage-konto eller använda ett annat säkert lagringsmedium som finns i en annan region.
3. Om SQL-databasen och regionen inte är tillgängliga kan du använda .bacpac filen med SqlPackage för att återskapa databasen på en arbetsyta i en ny region – Arbetsyta C2. W2 i region B enligt beskrivningen i scenariot ovan. Följ stegen som beskrivs i Importera en databas med SqlPackage för att återskapa databasen med din .bacpac fil.

Den återskapade databasen är en oberoende databas från den ursprungliga databasen och återspeglar datatillståndet vid tidpunkten för exportåtgärden.

Överväganden för återställning efter fel

Den återskapade databasen är en oberoende databas. Data som lagts till i den återskapade databasen återspeglas inte i den ursprungliga databasen. Om du planerar att återställa till den ursprungliga databasen när hemregionen blir tillgänglig måste du överväga att manuellt avstäma data från den återskapade databasen till den ursprungliga databasen.

Platform

Plattform refererar till underliggande delade tjänster och arkitektur som gäller för alla arbetsbelastningar. Detta avsnitt beskriver återhämtningsprocedurer för delade Fabric-funktioner.

Övervakning av arbetsyta

Arbetsytsövervakning samlar in loggar om aktivitet i arbetsytan där du aktiverar det. Efter att du återställt din arbetsyta som C2. W2, aktivera övervakning av arbetsytor på W2. Den börjar samla in övervakningsdata för det återvunna arbetsutrymmet.

Övervakningsdata från den ursprungliga arbetsytan (C1. W1) förs inte över, eftersom övervakningen speglar aktiviteten i arbetsytan den körs på.

Variabelbibliotek

Microsoft Fabric variabelbibliotek gör det möjligt för utvecklare att anpassa och dela objektkonfigurationer på en arbetsyta, vilket effektiviserar innehållslivscykelhanteringen. Från haveriberedskapssynpunkt måste användare av variabelbibliotek proaktivt skydda mot en regional katastrof. Detta kan göras via Fabric Git-integrering, vilket säkerställer att efter en regional katastrof förblir en användares variabelbibliotek tillgängligt. För att återställa ett variabelbibliotek rekommenderar vi följande:

• Använd Fabric Git-integrering för att synkronisera ditt variabelbibliotek med din ADO-lagringsplats. Vid haveri kan du använda lagringsplatsen för att återskapa variabelbiblioteket på den nya arbetsytan som du skapade. Följ stegen nedan:

  1. Anslut din arbetsyta till Git-lagringsplatsen enligt beskrivningen här.
  2. Se till att hålla WS och lagringsplatsen synkroniserade med Commit och Update.
  3. Återställning – Vid haveri använder du lagringsplatsen för att återskapa variabelbiblioteket på en ny arbetsyta:

• På den nyligen skapade arbetsytan ansluter du och synkroniserar till din Azure ADO-lagringsplats igen.

• Alla Fabric objekt på den här lagringsplatsen laddas ned automatiskt till din nya arbetsyta.

• När du har synkroniserat dina objekt från Git öppnar du dina variabelbibliotek på den nya arbetsytan och väljer den önskade aktiva värdeuppsättningen manuellt.

Kundhanterade nycklar för Fabric-arbetsytor

Du kan använda kundhanterade nycklar (CMK) som lagras i Azure Key Vault för att lägga till ytterligare ett krypteringslager ovanpå Microsoft hanterade nycklar för vilande data. Om Fabric blir otillgängligt eller oanvändbart i en region, växlar dess komponenter över till en backupinstans. Under failover stöder CMK-funktionen skrivskyddade operationer. Så länge Azure Key Vault-tjänsten förblir felfri och behörigheterna till valvet är intakta fortsätter Fabric att ansluta till din nyckel och gör att du kan läsa data normalt. Det innebär att följande åtgärder inte stöds under redundansväxling: aktivera och inaktivera cmk-inställningen för arbetsytan och uppdatera nyckeln.

OneLake

I det här avsnittet går vi igenom återställningsprocedurerna för OneLake-funktioner. Mer information om haveriberedskap för OneLake-data finns i OneLake-haveriberedskap.

Principer för livscykelhantering

Om Fabric blir otillgängligt eller inte fungerar i en region kan din OneLake-livscykelprincip fortfarande läsas och uppdateras vid en redundansväxling. Alla data som flyttas till lågfrekvent eller kall nivå kommer att finnas kvar på den nivån. Du kan följa de här stegen för att tillämpa din befintliga princip på din nya återställningsarbetsyta:

1. Anropa Exportera policy i den ursprungliga arbetsytan och spara hela livscykelpolicyn.
2. Anropa importprincipen på den återställda arbetsytan med din exporterade livscykelprincip som begärandetext.

Regler för resursinstans

Resursinstansregler hjälper dig att på ett säkert sätt styra åtkomsten till data i OneLake med hjälp av betrodda Azure resursidentiteter. Vid regional redundansväxling fortsätter systemet att tillämpa befintliga regler för läsåtkomst. Du kan dock inte skapa, uppdatera eller ta bort resursinstansregler förrän arbetsytan återgår till ett skrivbart tillstånd.

Relaterad information

• Microsoft Fabric guide för katastrofåterställning