Conseils sur la récupération d’urgence spécifiques à l’expérience

Ce document fournit des conseils basés sur l'expérience pour récupérer vos données de Fabric dans l'éventualité d'un sinistre régional.

Exemple de scénario

De nombreuses sections de conseils de ce document utilisent l’exemple de scénario suivant à des fins d’explication et d’illustration. Reportez-vous à ce scénario le cas échéant.

Supposons que vous avez une capacité C1 dans la région A qui a un espace de travail W1. Si vous avez activé la récupération d'urgence pour la capacité C1, les données OneLake sont répliquées dans une sauvegarde dans la région B. Si la région A subit des interruptions, le service Fabric en C1 bascule vers la région B.

L’image suivante illustre ce scénario. La boîte à gauche montre la région interrompue. La zone du milieu représente la disponibilité continue des données après le basculement, et la zone à droite montre la situation entièrement rétablie après l’action du client pour restaurer le plein fonctionnement de ses services.

Voici le plan de récupération général :

1. Créez une nouvelle capacité de tissu C2 dans une nouvelle région.

2. Créez un espace de travail W2 dans C2, incluant ses éléments correspondants avec les mêmes noms que dans C1.W1.

3. Copiez les données du C1.W1 perturbé vers C2.W2.

4. Suivez les instructions dédiées de chaque composant pour restaurer les éléments afin qu’ils fonctionnent pleinement.

Ce plan de récupération suppose que la région d’accueil du locataire reste opérationnelle. Si la région d’accueil du locataire subit une panne, les étapes décrites dans ce document sont subordonnées à sa récupération, qui doit d’abord être lancée et terminée par Microsoft.

Plans de récupération spécifiques à l’expérience

Les sections suivantes fournissent des guides pas à pas pour chaque expérience de Fabric pour aider les clients dans le processus de récupération.

Ingénierie des données

Ce guide vous guide tout au long des procédures de récupération pour l’expérience Ingénieurs de données. Il couvre les lakehouses, les notebooks, les définitions de tâches Spark, les fonctions de données utilisateur et les API GraphQL.

Lakehouse

Les lakehouses de la région d’origine restent indisponibles aux clients. Pour récupérer un lakehouse, les clients peuvent le recréer dans l'espace de travail C2.W2. Nous recommandons deux approches pour la récupération de lakehouses :

Approche 1 : utilisation d’un script personnalisé pour copier des fichiers et des tables Delta Lakehouse

Les clients peuvent recréer des lakehouses en utilisant un script Scala personnalisé.

1. Créez le lakehouse (par exemple, LH1) dans l’espace de travail C2.W2 nouvellement créé.

2. Créez un notebook dans l’espace de travail C2.W2.

3. Pour récupérer les tables et les fichiers de la lakehouse d'origine, consultez les données en utilisant des chemins OneLake tels que "abfss" (voir Connexion à Microsoft OneLake). Vous pouvez utiliser l’exemple de code suivant (voir Introduction aux utilitaires Microsoft Spark) dans le notebook pour obtenir les chemins ABFS des fichiers et des tables du lakehouse d’origine. (remplacer C1.W1 par le nom d’espace de travail réel)

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

4. Utilisez l’exemple de code suivant pour copier des fichiers et des tables dans le lakehouse nouvellement créé.

   1. Pour les tables Delta, vous devez copier les tables une par une afin de les récupérer dans le nouvel entrepôt de données. Dans le cas des fichiers Lakehouse, vous pouvez copier la structure complète du fichier avec tous les dossiers sous-jacents à l’aide d’une seule exécution.

   2. Contactez l’équipe du support technique pour obtenir le timestamp du basculement requis dans le script.

   %%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. Une fois que vous avez exécuté le script, les tables apparaissent dans le nouveau lakehouse.

Approche 2 : Utiliser Explorateur Stockage Azure pour copier des fichiers et des tables

Pour récupérer uniquement des fichiers ou des tables Lakehouse spécifiques à partir de la lakehouse d’origine, utilisez Explorateur Stockage Azure. Reportez-vous à Integrate OneLake avec Explorateur Stockage Azure pour obtenir des étapes détaillées. Pour des tailles volumineuses de données, utilisez l’Approche 1.

Récupération des vues de lac matérialisées de "Fabric"

Les vues matérialisées du lac provenant de la région d’origine restent indisponibles pour les clients après le basculement. Les planifications d’actualisation et l’historique d’exécution ne sont pas répliqués dans la région secondaire. Pour les récupérer, effectuez les étapes suivantes après avoir récupéré vos données Lakehouse.

• Récupérez les tables Lakehouse à l’aide de l’approche 1 ou de l’approche 2 décrites ci-dessus. Copiez uniquement les tables sources.
• Récupérez les blocs-notes qui contiennent vos définitions MLV. Reportez-vous à la section Notebook pour connaître les étapes de récupération.
• Exécutez les blocs-notes récupérés pour recréer les MLVs dans le nouveau Lakehouse. Pour plus d’informations sur la création de MLV, consultez Créer une vue Materialized Lake. Si les MLV ont également été copiées à l’étape précédente, exécutez CREATE OR REPLACE lors de leur recréation.
• Recréez manuellement les planifications d’actualisation MLV dans le nouvel espace de travail. Les métriques d’historique et d’exécution de planification ne sont pas récupérables.
• Si vos MLVs alimentent des modèles sémantiques ou des rapports, vérifiez et mettez à jour les références d’ID lakehouse et d’ID de jeu de données si nécessaire. Reconnectez les rapports au modèle sémantique mis à jour et validez l’actualisation des données.

Ordinateur portable

Les blocs-notes de la région primaire restent indisponibles pour les clients et le code dans les blocs-notes n'est pas répliqué dans la région secondaire. Pour récupérer du code Notebook dans la nouvelle région, il existe deux approches pour récupérer du contenu de code Notebook.

Approche 1 : redondance managée par l’utilisateur avec une intégration Git (dans la préversion publique)

La meilleure manière de rendre cela simple et rapide est d'utiliser l'intégration Git de Fabric, puis de synchroniser votre notebook avec votre référentiel ADO. Après le basculement du service vers une autre région, vous pouvez utiliser le référentiel pour reconstruire le notebook dans le nouvel espace de travail que vous avez créé.

1. Configurez l’intégration Git pour votre espace de travail, puis sélectionnez Connecter et synchroniser avec le référentiel ADO.

   

   L’image suivante montre le notebook synchronisé.

   

2. Récupérez le notebook à partir du référentiel ADO.

   1. Dans l’espace de travail nouvellement créé, connectez-vous à nouveau à votre dépôt ADO Azure.

      

   2. Sélectionnez le bouton Contrôle de code source. Sélectionnez ensuite la branche appropriée du référentiel. Sélectionnez ensuite Tout mettre à jour. Le bloc-notes d’origine s’affiche.

      

      

   3. Si le notebook d’origine a un lakehouse par défaut, les utilisateurs peuvent se référer à la section Lakehouse pour récupérer le lakehouse, puis connecter le lakehouse nouvellement récupéré au notebook nouvellement récupéré.

      

   4. L’intégration Git ne prend pas en charge la synchronisation des fichiers, des dossiers ou des captures instantanées de notebook dans l'explorateur de ressources du notebook.

      1. Si le notebook d’origine dispose de fichiers dans l’explorateur de ressources du notebook :

         1. Veillez à enregistrer les fichiers ou les dossiers dans un disque local ou un autre emplacement.

         2. Rechargez le fichier à partir de votre disque local ou de lecteurs cloud dans le notebook récupéré.

      2. Si le notebook d'origine a un instantané, enregistrez également cet instantané dans votre système de contrôle de version ou sur votre disque local.

         

         

Pour obtenir plus d’informations sur l’intégration Git, voir Introduction à l’intégration Git.

Approche 2 : approche manuelle de la sauvegarde du contenu de code

Si vous ne disposez pas d’une approche d’intégration Git, vous pouvez enregistrer la dernière version de votre code et de vos fichiers dans l’explorateur de ressources et l’instantané de notebook dans un système de gestion de version tel que Git, et récupérer manuellement le contenu du notebook après un sinistre :

1. Utilisez la fonctionnalité « Importer le notebook » pour importer le code de notebook que vous souhaitez récupérer.

   

2. Après l’importation, accédez à l’espace de travail souhaité (par exemple, « C2.W2 ») pour y accéder.

3. Si le notebook d’origine a un lakehouse par défaut, consultez la section Lakehouse. Connectez ensuite le lakehouse nouvellement récupéré (qui dispose du même contenu que le lakehouse par défaut d’origine) au notebook nouvellement récupéré.

4. Si le notebook d’origine a des fichiers ou des dossiers dans l’explorateur de ressources, rechargez les fichiers ou dossiers enregistrés dans le système de gestion de version de l’utilisateur.

Définition de la tâche Spark

Les définitions de tâche Spark (SJD) de la région primaire restent indisponibles pour les clients, et le fichier de définition principal ainsi que le fichier de référence du notebook seront répliqués dans la région secondaire via OneLake. Si vous souhaitez récupérer la SJD dans la nouvelle région, vous pouvez suivre les étapes manuelles décrites ci-dessous pour la récupérer. Les processus historiques du SJD ne seront pas restaurés.

Vous pouvez récupérer les éléments SJD en copiant le code de la région d’origine en utilisant Explorateur Stockage Azure et en reconnectant manuellement les références Lakehouse après le sinistre.

1. Créez un élément de SJD (par exemple, SDJ1) dans le nouvel espace de travail C2.W2 avec les mêmes paramètres et configurations que l’élément de SJD d’origine (par exemple, le langage, l’environnement, etc.).

2. Utilisez Explorateur Stockage Azure pour copier les Libs, Mains et Snapshots de l’élément SJD d’origine vers le nouvel élément SJD.

   

3. Le contenu de code apparaît dans la SJD nouvellement créée. Vous devez ajouter manuellement la référence Lakehouse nouvellement récupérée au travail (consultez les Étapes de récupération de Lakehouse). Les utilisateurs doivent entrer à nouveau manuellement les arguments de ligne de commande d’origine.

   

Vous pouvez maintenant exécuter ou planifier votre SJD nouvellement récupérée.

Pour plus d’informations sur Explorateur Stockage Azure, consultez Integrate OneLake avec Explorateur Stockage Azure.

Fonctions de données utilisateur

Pour récupérer vos fonctions de données utilisateur dans une région saine, utilisez l’une des approches suivantes.

Approche 1 : Avec l’intégration Git (recommandée)

Le mécanisme de récupération préféré est l’intégration Fabric Git. En synchronisant les projets de fonctions de données utilisateur avec un dépôt Azure DevOps ou GitHub, vous pouvez rapidement les reconstruire dans un nouvel espace de travail après le basculement.

Préparez-vous avant une catastrophe

1. Configurez l’intégration Fabric Git pour l’espace de travail qui héberge la fonction de données utilisateur.
2. Connectez l’espace de travail à un dépôt Azure DevOps ou GitHub.
3. Enregistrez toutes les données utilisateur dans le dépôt et synchronisez régulièrement les modifications.
4. Stockez les paramètres spécifiques à l’environnement séparément dans des bibliothèques variables si nécessaire.

Étapes de récupération

Après une catastrophe régionale :

1. Créez une nouvelle capacité Fabric dans une région saine, comme le C2.
2. Créez un nouvel espace de travail, comme W2, dans cette nouvelle capacité.
3. Connectez l’espace de travail au même dépôt Azure DevOps ou GitHub.
4. Ouvrez Contrôle de code source et synchronisez le contenu du dépôt dans l’espace de travail.
5. Recréez ou récupérez toutes les ressources Fabric dépendantes, telles que les maisons lacustres, les bases de données SQL dans Fabric, les entrepôts et les événements professionnels.
6. Redéployez les fonctions de données utilisateur.
7. Validez l’exécution des fonctions et la connectivité des dépendances.
8. Mettez à jour les applications en aval, les pipelines de données ou tout autre système intégré afin qu’ils fassent référence aux fonctions restaurées.
9. Validation complète de bout en bout de tous vos scénarios.

Considérations importantes

• L’intégration Git ne récupère que le code source et les assets du projet.
• Les journaux historiques d’exécution ne sont pas récupérés.
• Les systèmes en aval peuvent nécessiter une reconnexion des points d’extrémité.

Pour plus d’informations, voir Fonctions de données utilisateur, contrôle de sources et déploiement.

Approche 2 : récupération manuelle

Si l’intégration Git n’était pas configurée avant la catastrophe, vous pouvez reconstruire manuellement les fonctions de données utilisateur à partir des sauvegardes du code source.

Préparez-vous avant une catastrophe

Accomplissez régulièrement les tâches suivantes et stockez les artefacts dans un dépôt de contrôle de version externe ou un lieu de sauvegarde :

• Exportez le code source de la fonction vers un dépôt GitHub.
• Documentez et conservez les informations de dépendance.
• Paramètres de l’environnement du document.

Étapes de récupération

Après une catastrophe régionale :

1. Créez une nouvelle capacité Fabric dans une région saine, comme le C2.
2. Créez un nouvel espace de travail, comme W2.
3. Récupérer toutes les ressources requises par la fonction, y compris les lakehouses, les bases de données SQL dans Fabric, les entrepôts de données, les eventhouses et les services externes.
4. Créez un nouveau projet de fonction de données utilisateur.
5. Importez ou recréez le code source de la fonction.
6. Réappliquez les paramètres de configuration à l’exécution.
7. Réinstallez toutes les dépendances de fonction.
8. Redéployez la fonction.
9. Reconfigurez l’authentification et l’autorisation.
10. Recréez les éditeurs ou les consommateurs de Business Event, le cas échéant.
11. Effectuez des tests de validation de bout en bout pour vos scénarios et intégrations.

GraphQL

Les éléments GraphQL de la région primaire ne sont pas disponibles après un sinistre régional, et les définitions et configurations GraphQL ne sont pas répliquées dans la région secondaire. Pour récupérer GraphQL dans une nouvelle région, utilisez l’une des approches suivantes.

Approche 1 : Redondance gérée par l’utilisateur avec intégration Git

La meilleure façon de faciliter et de simplifier ce processus consiste à utiliser Fabric intégration Git, puis à synchroniser votre GraphQL avec votre dépôt ADO. Une fois que le service bascule vers une autre région, vous pouvez utiliser le dépôt pour reconstruire GraphQL dans le nouvel espace de travail que vous avez créé.

1. Créez un espace de travail dans la capacité et la région cibles.

2. Récupérez toutes les sources de données dépendantes, telles que Les bases de données Lakehouse, Warehouse ou SQL, en suivant leurs étapes de récupération respectives.

3. Mettez à jour la définition GraphQL pour pointer vers les ressources nouvellement récupérées en modifiant des références spécifiques à l’environnement, telles que les ID d’espace de travail source, les ID d’artefact source et les détails de connexion. Cette étape garantit une liaison correcte au moment du déploiement.

4. Redéployez les artefacts GraphQL du référentiel Git dans le nouvel espace de travail. Cette étape recrée la structure et la configuration de l’API à l’aide des définitions mises à jour.

5. Réappliquez les paramètres d’artefact, notamment les rôles, les contrôles d’accès et la configuration de l’authentification.

6. Réappliquez les références de point de terminaison en mettant à jour toutes les applications ou intégrations pour utiliser le point de terminaison GraphQL nouvellement créé.

7. Mettez à jour tous les pipelines de déploiement existants qui pointaient vers l’ancien espace de travail pour référencer l’espace de travail nouvellement créé.

8. Validez les fonctionnalités de bout en bout de l’API.

Approche 2 : Approche manuelle

Si vous ne suivez pas l’approche d’intégration Git, vous pouvez utiliser l’approche manuelle suivante pour récupérer GraphQL.

1. Créez un espace de travail dans la capacité et la région cibles.

2. Récupérez toutes les sources de données dépendantes, telles que Les bases de données Lakehouse, Warehouse ou SQL.

3. Recréez manuellement l’API GraphQL dans le nouvel espace de travail, notamment les définitions de schéma, les connexions de source de données et les relations.

4. Réappliquez les paramètres d’artefact, notamment les rôles, les contrôles d’accès et la configuration de l’authentification.

5. Réappliquez les références de point de terminaison en mettant à jour toutes les applications ou intégrations pour utiliser le point de terminaison GraphQL nouvellement créé.

6. Mettez à jour tous les pipelines de déploiement existants qui pointaient vers l’ancien espace de travail pour référencer l’espace de travail nouvellement créé.

7. Validez les fonctionnalités de bout en bout de l’API.

Considérations importantes

1. GraphQL s’appuie sur des dépendances externes (telles que Lakehouse, Warehouse et SQL), que vous devez récupérer avant le déploiement de GraphQL.

2. Les définitions d’API GraphQL incluent des références spécifiques à l’environnement (telles que sourceWorkspaceId et sourceItemId). Lors de la récupération dans une nouvelle région, ces références peuvent devenir non valides. Mettez-les à jour pour qu’elles pointent vers des ressources nouvellement approvisionnées.

3. La liaison automatique de sources de données n’est pas garantie dans les scénarios de récupération d’urgence, en particulier lors de l’utilisation d’informations d’identification enregistrées ou de connexions entre espaces de travail.

4. D’autres paramètres d’artefact, tels que la surveillance, l’autorisation, le RBAC, l’introspection et d’autres encore, ne sont pas conservés après le basculement. Vous devez rétablir ces paramètres dans la nouvelle région.

References

• Vue d’ensemble de l’intégration Fabric Git - Microsoft Fabric | Microsoft Learn

• Pipelines de contrôle de code source et de déploiement dans l’API pour GraphQL - Microsoft Fabric | Microsoft Learn 

App

Le système ne réplique pas les applications Fabric, y compris leur code, leur configuration et leurs métadonnées, vers les régions secondaires. Si la région principale échoue, l’application reste indisponible. Pour la récupération, stockez le code source de l’application en dehors du système dans GitHub, Azure DevOps ou un autre système de contrôle de version. Récupérez les données des applications séparément en suivant les conseils de reprise après sinistre pour chaque magasin de données Fabric sous-jacent.

Approche manuelle

Vous pouvez récupérer manuellement une application Fabric après un sinistre régional à l’aide du code source de l’application et de l’interface de ligne de commande Rayfin. 

Conditions préalables 

Avant qu’une catastrophe ne survienne :

• Stockez le code source de Fabric App dans GitHub, Azure DevOps ou un autre dépôt de contrôle de version. 

• Documentez le processus de récupération.  

Étapes de récupération 

1. Créez un espace de travail dans la capacité et la région cibles. 

2. Récupérez les ressources dépendantes avant de redéployer l’application.  

3. Récupérez le dernier code source de l’application Fabric depuis votre dépôt de contrôle de version ou une sauvegarde locale. 

4. Depuis le répertoire source de l’application, déployez l’application Fabric dans l’espace de travail de récupération en utilisant la CLI Rayfin. Exécutez rayfin up --workspace <new workspace>. 

5. Récupérez l’élément enfant de l’application (base de données Fabric SQL) en suivant ses procédures de récupération respectives.  

6. Réappliquez les paramètres de niveau d’artefact, y compris les rôles et les contrôles d’accès si nécessaire.  

7. Validez la fonctionnalité de l’application et assurez-vous que les utilisateurs disposent des bonnes permissions.  

Important 

• Maintenez le code source de Fabric App en dehors de la région Fabric pour permettre la récupération.  

• Les données d'application dans la base de données ne sont pas récupérées dans le cadre du déploiement de l'application Fabric et doivent être restaurées séparément.  Vous pouvez récupérer manuellement une application Fabric après un sinistre régional à l’aide du code source de l’application et de l’interface de ligne de commande Rayfin. 

Science des données

Ce guide vous accompagne tout au long des procédures de récupération pour l’expérience Science des données. Il aborde les modèles et les expériences ML.

Modèle et expérience ML

Les éléments de science de données de la région primaire restent inaccessibles aux clients, et le contenu et les métadonnées dans les modèles et expériences de ML ne seront pas répliqués dans la région secondaire. Pour les récupérer complètement dans la nouvelle région, enregistrez le contenu de code dans un système de gestion de version (tel que Git) et réexécutez manuellement le contenu de code après le sinistre.

1. Récupérez le notebook. Consultez les Étapes de récupération de notebooks.

2. Les configurations, les métriques d'exécution historiques et les métadonnées ne sont pas répliquées dans la région jumelée. Vous devez exécuter à nouveau chaque version de votre code de science des données pour récupérer complètement des expériences et des modèles ML après le sinistre.

Entrepôt de données

Ce guide vous guide tout au long des procédures de récupération pour l’expérience de Data Warehouse. Il couvre les entrepôts.

Entrepôt

Les entrepôts de la région d’origine restent indisponibles aux clients. Pour récupérer des entrepôts, utilisez les deux étapes suivantes.

1. Créez un lakehouse intermédiaire dans l’espace de travail C2.W2 pour les données que vous allez copier à partir de l’entrepôt d’origine.

2. Remplissez les tables Delta de l'entrepôt en tirant parti de l'Explorateur d'entrepôts et des fonctionnalités T-SQL (consultez Tables dans l'entreposage de données dans Microsoft Fabric).

Ingestion de données via un code Lakehouse et T-SQL

Dans un espace de travail C2.W2 nouvellement créé :

1. Créez un lakehouse temporaire « LH2 » dans C2.W2.

2. Récupérez les tables Delta dans le lakehouse intermédiaire à partir de l'entrepôt d'origine en suivant les Étapes de récupération de Lakehouse.

3. Créez un entrepôt « WH2 » dans C2.W2.

4. Connectez le lakehouse provisoire à votre explorateur d’entrepôts.

5. En fonction de la façon dont vous allez déployer des définitions de table avant d’importer des données, le T-SQL réel utilisé pour les importations peut varier. Vous pouvez utiliser l’approche INSERT INTO, SELECT INTO ou CREATE TABLE AS SELECT pour récupérer des tables d’entrepôt à partir des lakehouses. Plus loin dans l’exemple, nous utiliserons la saveur INSERT INTO. (Si vous utilisez le code ci-dessous, remplacez les exemples par la table et les noms de colonne réels)

   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. Enfin, modifiez la chaîne de connexion dans les applications utilisant votre entrepôt Fabric.

Base de données miroir

Les bases de données mises en miroir de la région primaire restent indisponibles pour les clients et les paramètres ne sont pas répliqués vers la région secondaire. Pour le récupérer en de défaillance régionale, vous devez recréer votre base de données mise en miroir dans un autre espace de travail d’une autre région.

Usine de Données (Data Factory)

Les éléments Data Factory de la région primaire restent indisponibles pour les clients et les paramètres et la configuration dans les pipelines ou les éléments gen2 de flux de données ne seront pas répliqués dans la région secondaire. Pour récupérer ces éléments en cas de défaillance régionale, vous devez recréer vos éléments Intégration de données dans un autre espace de travail à partir d’une région différente. Les sections suivantes décrivent les détails.

Flux de données Gen2

Si vous souhaitez récupérer un élément Dataflow Gen2 dans la nouvelle région, vous devez exporter un fichier PQT vers un système de gestion de version tel que Git, puis récupérer manuellement le contenu Dataflow Gen2 après le sinistre.

1. Depuis votre élément Dataflow Gen2, sous l’onglet Accueil de l’éditeur Power Query, sélectionnez Exporter le modèle.

   

2. Dans la boîte de dialogue Exporter un modèle, entrez un nom (obligatoire) et une description (facultative) pour ce modèle. Une fois cette opération effectuée, sélectionnez OK.

   

3. Après le sinistre, créez un élément Dataflow Gen2 dans le nouvel espace de travail « C2.W2 ».

4. Dans le volet d’affichage actuel de l’éditeur de Power Query, sélectionnez Importer à partir d’un modèle Power Query.

   

5. Dans la boîte de dialogue Ouvrir, accédez à votre dossier des téléchargements par défaut et sélectionnez le fichier .pqt que vous avez enregistré lors des étapes précédentes. Sélectionnez ensuite Ouvrir.

6. Le modèle est ensuite importé dans votre nouvel élément Dataflow Gen2.

La fonctionnalité Enregistrer sous des flux de données n’est pas prise en charge en cas de récupération d’urgence.

Pipelines

Les clients ne peuvent pas accéder aux pipelines en cas de sinistre régional et les configurations ne sont pas répliquées dans la région jumelée. Nous vous recommandons de créer vos pipelines critiques dans plusieurs espaces de travail dans différentes régions.

Tâche de copie

Les utilisateurs copyJob doivent entreprendre des mesures proactives pour se protéger contre une catastrophe régionale. L’approche suivante garantit que, après une catastrophe régionale, les CopyJobs d’un utilisateur restent disponibles.

Redondance gérée par l’utilisateur avec l’intégration Git (en préversion publique)

La meilleure façon de faciliter et de simplifier ce processus consiste à utiliser Fabric intégration Git, puis à synchroniser votre CopyJob avec votre dépôt ADO. Une fois que le service bascule vers une autre région, vous pouvez utiliser le référentiel pour reconstruire le CopyJob dans le nouvel espace de travail que vous avez créé.

1. Configurez l’intégration Git de votre espace de travail et sélectionnez connecter et synchroniser avec le référentiel ADO.

   

   L’image suivante montre le CopyJob synchronisé.

   

2. Récupérez l’objet CopyJob à partir du dépôt ADO.

   1. Dans l’espace de travail nouvellement créé, connectez-vous et synchronisez à nouveau avec votre dépôt ADO Azure. Tous les éléments Fabric de ce référentiel sont automatiquement téléchargés dans votre nouvel espace de travail.

      

   2. Si le CopyJob original utilise un Lakehouse, les utilisateurs peuvent se référer à la section Lakehouse pour récupérer le Lakehouse et ensuite connecter le CopyJob nouvellement récupéré au Lakehouse nouvellement récupéré.

Pour obtenir plus d’informations sur l’intégration Git, voir Introduction à l’intégration Git.

Travail Apache Airflow

Apache Airflow Job dans Fabric utilisateurs doit entreprendre des mesures proactives pour se protéger contre une catastrophe régionale.

Nous vous recommandons de gérer la redondance avec Fabric intégration Git. Tout d’abord, synchronisez votre travail Airflow avec votre dépôt ADO. Si le service bascule vers une autre région, vous pouvez utiliser le référentiel pour reconstruire le travail Airflow dans le nouvel espace de travail que vous avez créé.

Voici les étapes à suivre pour ce faire :

1. Configurez l’intégration Git de votre espace de travail et sélectionnez « Se connecter et synchroniser » avec le référentiel ADO.

2. Après cela, vous verrez que votre travail Airflow a été synchronisé avec votre dépôt ADO.

3. Si vous devez récupérer le travail Airflow à partir du référentiel ADO, créez un espace de travail, connectez-vous et synchronisez à nouveau avec votre dépôt ADO Azure. Tous les éléments Fabric, y compris Airflow, dans ce référentiel seront automatiquement téléchargés sur votre nouvel espace de travail.

Intelligence en Temps Réel

Ce guide vous accompagne tout au long des procédures de récupération pour l’expérience Real-Time Intelligence. Il aborde les bases de données et ensembles de requêtes KQL ainsi que les flux d'événements.

Activator

Les éléments de l’Activator de la région principale restent indisponibles pour les clients, et les définitions de déclencheur de l’Activator ne sont pas répliquées vers la région secondaire. Les utilisateurs de l’activateur doivent prendre des mesures proactives pour préparer la récupération d’urgence régionale.

Pour vous assurer que vous pouvez récupérer des éléments d’activateur en cas de sinistre régional, configurez Fabric intégration Git pour sauvegarder les définitions de déclencheur et les restaurer dans un espace de travail dans une autre région.

1. Configurez l’intégration Git de Fabric pour l’espace de travail contenant votre élément Activator, et synchronisez vos définitions de déclencheurs avec votre dépôt Git.
2. Conservez régulièrement les définitions de déclencheur d’activateur validées et synchronisées.
3. Pendant la récupération, créez un espace de travail dans la région cible (C2). W2), connectez-le au même référentiel et synchronisez-le pour restaurer les définitions de déclencheur.
4. Reconfigurez et validez toutes les sources de données et dépendances d’Activator dans le nouvel espace de travail.

Pour obtenir plus d’informations sur l’intégration Git, voir Introduction à l’intégration Git.

Modèle de graphe/ensemble de requêtes

Les éléments du modèle graph et du jeu de requêtes Graph de la région primaire restent indisponibles pour les clients, et ces éléments ne sont pas répliqués dans la région secondaire. Pour récupérer, créez ou utilisez une capacité dans une autre région et recréez les éléments du modèle de graphe et de l'ensemble de requêtes de graphe à cet endroit.

1. Créez ou utilisez une capacité de Fabric existante dans une autre région qui n'est pas affectée par la catastrophe.

2. Créez un espace de travail ou utilisez un espace de travail existant dans cette capacité.

3. Recréez l'élément de modèle de graphe dans l’espace de travail secondaire (référencé à l’étape 2). Reconfigurez la définition du modèle, y compris les nœuds, les arêtes, etc., pour qu’elle corresponde au modèle graph d’origine.

4. Si le lakehouse d’origine se trouve dans la région défaillante, récupérez-le d’abord en suivant la section Lakehouse.

5. Connectez un lakehouse en tant que source de données OneLake pour l’élément de modèle Graph nouvellement créé. Utilisez le lac récupéré s’il était dans la région défaillante ou reconnectez-vous à la zone de lac existante s’il reste disponible.

6. Reconfigurez les planifications ou connexions de chargement de données pour le modèle Graph dans le nouvel espace de travail.

7. Recréez l’élément d’ensemble de requêtes Graph dans l’espace de travail secondaire. Réentez manuellement les requêtes et toutes les configurations de requête enregistrées à partir de l’ensemble de requêtes Graph d’origine.

Base de données/KQL Queryset

Les utilisateurs d’ensembles de requêtes/bases de données KQL doivent prendre des mesures proactives pour se protéger contre un sinistre régional. L’approche suivante veille, en cas de sinistre régional, à ce que les données dans vos ensembles de requêtes de bases de données KQL restent sécurisés et accessibles.

Utilisez les étapes suivantes afin d’assurer une solution de récupération d’urgence efficace pour des ensembles de requêtes et des bases de données KQL.

1. Establish des bases de données KQL indépendantes : configurez deux bases de données/ensembles de requêtes KQL indépendants ou plus sur des capacités de Fabric dédiées. Celles-ci doivent être configurées entre deux régions Azure différentes (de préférence Azure-jumelées) pour optimiser la résilience.

2. Répliquer les activités de gestion : toute mesure de gestion prise sur une base de données KQL doit être mise en miroir dans l’autre. Cela permet aux deux bases de données de rester synchronisées. Les activités clés à répliquer incluent :

   • Tables : vérifiez que les définitions de schéma et les structures de table sont cohérentes dans les bases de données.

   • Mappage : dupliquez les mappages requis. Vérifiez que les sources de données et les destinations s’alignent correctement.

   • Politiques : vérifiez que les deux bases de données ont des politiques de conservation des données similaires, d'accès et d'autres politiques pertinentes.

3. Gestion des authentifications et des autorisations : pour chaque réplica, configurez les autorisations exigées. Vérifiez que des niveaux d’autorisation corrects sont établis pour accorder l’accès au personnel requis tout en maintenant les normes de sécurité.

4. Ingestion de données parallèles : pour maintenir la cohérence et la disponibilité des données dans plusieurs régions, chargez le même jeu de données dans chaque base de données KQL en même temps que vous l'ingérez.

Flux d'événements

Un flux d’événements est un emplacement centralisé dans la plateforme Fabric pour capturer, transformer et router des événements en temps réel vers différentes destinations (par exemple, lakehouses, bases de données KQL/ensembles de requêtes) avec une expérience sans code. Dans la mesure où les destinations sont prises en charge par la récupération d’urgence, les eventstreams ne perdent pas de données. Par conséquent, les clients doivent utiliser les fonctionnalités de récupération d’urgence de ces systèmes de destination pour veiller à la disponibilité des données.

Les clients peuvent également obtenir une redondance géographique en déployant des charges de travail Eventstream identiques dans plusieurs régions Azure dans le cadre d’une stratégie active/active multisite. Grâce à l’approche active/active sur plusieurs sites, les clients peuvent accéder à leur charge de travail dans n’importe quelle région déployée. Cette approche est la plus complexe et la plus coûteuse en ce qui concerne la récupération d’urgence, mais elle peut réduire le temps de récupération à une valeur proche de zéro dans la majorité des situations. Pour assurer une redondance géographique complète, les clients peuvent

1. Créer des réplicas de leurs sources de données dans différentes régions.

2. Créer des éléments Eventstream dans les régions correspondantes.

3. Connecter ces nouveaux éléments aux sources de données identiques.

4. Ajouter des destinations identiques pour chaque eventstream dans diverses régions.

Événements d’entreprise, événements Fabric et événements de Azure

Bien que les événements métier, les événements Fabric et les événements Azure partagent la même infrastructure hub Real-Time dans Microsoft Fabric, ils ont des origines, des comportements et des exigences de récupération distincts qui doivent être compris avant la planification de la reprise d’activité :

• Fabric Événements sont des abonnements aux événements qui réagissent à l’activité produite par des ressources Fabric elles-mêmes, y compris les modifications de cycle de vie des éléments de l’espace de travail (telles que la création, la mise à jour ou la suppression de lakehouses, de notebooks ou d’entrepôts), les exécutions de travaux (telles que les exécutions de pipelines ou d’exécutions de notebooks) et les opérations de fichiers et de dossiers OneLake. Ces abonnements sont basés sur push et éphémères. Les abonnements ne sont pas répliqués vers la région secondaire.

• Les Événements Azure sont des abonnements à des événements liés à l’activité générée par des comptes Stockage Blob Azure. Ces ressources Azure existent indépendamment de n’importe quelle capacité ou région Fabric. Bien que la ressource Stockage Blob Azure elle-même reste disponible pendant une panne régionale Fabric, les abonnements configurés dans Real-Time hub ne sont pas répliqués vers la région secondaire et doivent être recréés.

• Les événements métier sont une fonctionnalité distincte dans Fabric Real-Time Intelligence qui permet aux équipes de définir, de publier et d’agir sur des signaux métier significatifs. Les événements métier sont générés au sein de Fabric via Activator, des notebooks Spark ou des fonctions de données utilisateur, puis publiés dans Real-Time hub, où des consommateurs en aval tels qu’Activator, Eventhouse ou Power Automate peuvent réagir à ces événements. Les schémas d’événement sont régis de manière centralisée via le Registre de schémas. Eventhouse stocke automatiquement chaque événement professionnel publié, de sorte que sa récupération affecte directement la disponibilité de l’historique des événements métier. Aucune des configurations de l’éditeur ou du consommateur, des définitions de schéma ou des abonnements n’est répliquée vers la région secondaire.

Procédez comme suit pour restaurer les événements professionnels, les événements Fabric et les événements Azure dans le nouvel espace de travail de la région de récupération.

Événements d’entreprise :

1. Recréez l’événement métier utilisé par les éditeurs et les consommateurs en suivant l’article Créer des événements métier dans Fabric Real-Time Hub. Lors de la création de l’événement métier, vous créez la ressource Event Schema Set. La ressource Eventhouse est facultative en fonction du scénario. Si vous avez sauvegardé votre ensemble de schéma d’événements avec l’intégration Git, restaurez-le d’abord en suivant la section Ensemble de schémas d’événements, puis pointez l’événement métier vers l’ensemble de schéma restauré.

2. Recréez dans le nouvel espace de travail tous les éléments éditeurs qui génèrent des événements métier, tels que les notebooks Spark ou les fonctions de données utilisateur, en vous appuyant sur les articles consacrés aux éditeurs : Utiliser une fonction de données utilisateur comme éditeur d’événements métier, Utiliser Activator comme éditeur d’événements métier, Utiliser Notebook comme éditeur d’événements métier et Utiliser Eventstream comme éditeur d’événements métier.

3. Recréez les abonnements consommateurs dans Real-Time hub (par exemple, les règles Activator, les déclencheurs de notebook ou les flux Power Automate) qui réagissaient à l’origine aux événements métier dans la région concernée en suivant les articles Eventhouse and Real-Time Dashboard Integration with Business Events et Consume Business Events from Activator.

4. Vérifiez que les événements circulent de bout en bout en vérifiant que les abonnements sont actifs et que les données arrivent aux destinations attendues dans la région de récupération.

Pour les événements Fabric :

1. Recréez les abonnements dans le hub Real-Time qui pointent vers les éléments de l’espace de travail, les tâches ou les chemins OneLake restaurés dans la région de récupération, en suivant l’article Explorer les événements Fabric dans le hub Fabric Real-Time.

2. Vérifiez que les événements circulent de bout en bout en vérifiant que les abonnements sont actifs et que les données arrivent aux destinations attendues dans la région de récupération.

Pour les événements Azure :

1. Stockage Blob Azure comptes ne sont pas affectés par une panne régionale Fabric. Recréez les abonnements aux événements dans Real-Time hub pointant vers les mêmes comptes Stockage Blob Azure en suivant l’article Définir des alertes sur les événements Stockage Blob Azure dans Real-Time hub.

2. Vérifiez que les événements circulent de bout en bout en vérifiant que les abonnements sont actifs et que les données arrivent aux destinations attendues dans la région de récupération.

Ensemble de schémas d’événements

Un ensemble de schémas d’événements est l’élément Fabric qui contient les définitions des types d’événements et des schémas dans Real-Time Intelligence. D’autres capacités s’appuient sur cela : les éditeurs écrivent des événements conformes à leurs schémas, et les consommateurs lisent selon les mêmes définitions.

Les ensembles de schémas d’événements de la région principale restent indisponibles pour les clients et ne sont pas reproduits dans la région secondaire. Cependant, comme un ensemble de schéma d’événements est une définition durable et créée plutôt qu’un abonnement éphémère, vous pouvez le sauvegarder à l’avance et le restaurer plutôt que de le réécrire à la main.

Recommandé : sauvegarder avec l’intégration de Fabric Git

Pour récupérer un schéma d’événement configuré après un désastre régional, configurez l’intégration Fabric Git avant qu’un sinistre ne survienne, et synchronisez l’espace de travail contenant vos ensembles de schémas d’événements avec votre dépôt Git.

1. Configurez l’intégration Fabric Git pour l’espace de travail contenant votre ensemble de schémas d’événements, et synchronisez-le avec votre dépôt Git.

2. Gardez le set de schéma d’événements engagé et synchronisé régulièrement, surtout après avoir ajouté des types d’événements ou publié de nouvelles versions de schéma.

3. Pendant la récupération, créez un nouvel espace de travail dans la région cible (C2. W2), le connecter au même dépôt, et synchroniser pour restaurer le schéma d’événements défini. Comme le nouvel espace de travail est vide, Git Sync amène le contenu du dépôt vers l’espace de travail.

4. Recréez tous les éditeurs et consommateurs qui utilisent l’ensemble de schémas, en suivant les recommandations pour ces types d’articles.

5. Validez que les éditeurs peuvent publier sur les types d’événements restaurés et que les consommateurs reçoivent les événements comme prévu.

La définition synchronisée inclut les types d’événements dans l’ensemble de schémas, les schémas et les versions de schéma. Cela n’inclut pas les inscriptions des éditeurs, les abonnements des consommateurs ni l’historique des événements. Récupérez ces éléments séparément, en suivant les indications pour les types d’éléments utilisant l’ensemble de schéma.

Alternative : recréer manuellement

Si vous n’avez pas configuré l’intégration Git avant le sinistre, recréez le schéma d’événements dans la région de récupération en suivant Créer et gérer les ensembles de schémas d’événements, puis ajoutez les types d’événements et les schémas contenus par l’ensemble de schémas d’origine en suivant Créer et gérer les schémas d’événements dans les ensembles de schémas.

Carte

Les éléments de la carte de la région primaire restent indisponibles pour les clients et ne sont pas répliqués dans la région secondaire.

Si vous souhaitez récupérer un élément map quand un sinistre se produit, configurez Fabric intégration Git et synchronize votre élément Map avec votre dépôt Git.

Pendant la récupération, après la configuration de la nouvelle région/capacité dans Fabric, vous pouvez utiliser le référentiel pour reconstruire l'élément Map dans le nouvel espace de travail que vous avez créé. Étant donné que le nouvel espace de travail est vide, Git sync obtient le contenu du référentiel dans l’espace de travail vide. Cette étape redonne vie à l'élément Map.

Ontologie

Les utilisateurs de l’ontologie doivent prendre des mesures proactives pour préparer la reprise après sinistre régionale. L’approche décrite ci-dessous garantit que, suite à une catastrophe régionale, votre ontologie reste récupérable et peut être restaurée rapidement.

La façon la plus simple et la plus rapide d’activer la récupération consiste à utiliser Fabric intégration Git et à synchroniser votre ontologie avec un référentiel Azure DevOps (ADO). Si le service bascule vers une autre région, vous pouvez utiliser ce référentiel pour reconstruire l’Ontology dans un espace de travail nouvellement créé.

Les éléments d'Ontology dans la région primaire ne sont pas disponibles pour les clients après un sinistre régional, et les éléments d'Ontology ne sont pas répliqués vers la région secondaire.

Pour récupérer un élément Ontology lors d’un sinistre, configurez Fabric intégration Git et synchronize l’élément Ontology avec votre référentiel ADO à l’avance.

Lors de la récupération, une fois la nouvelle région et la capacité dans Fabric configurées, vous pouvez utiliser le référentiel pour reconstruire l’élément Ontology dans un nouvel espace de travail. Étant donné que le nouvel espace de travail est vide, Git sync extrait le contenu du référentiel dans l’espace de travail, en restaurant efficacement l’élément Ontology.

Planning

Cet article décrit les procédures de récupération de la fonctionnalité de planification dans IQ. Il décrit les étapes nécessaires pour restaurer les composants clés, y compris les feuilles de planification, les feuilles PowerTable, les feuilles de renseignement, InfoBridge et les actifs de données associés.

Intégration Git pour la restauration des éléments de plan

L’approche recommandée consiste à synchroniser tous les éléments du plan avec un référentiel Azure DevOps (ADO) ou GitHub à l’aide de l’intégration Git de Fabric. Après un basculement, utilisez le référentiel pour restaurer les éléments dans le nouvel espace de travail.

Avant une catastrophe (mesures proactives) :

1. Dans l’espace de travail W1, accédez aux paramètres de l’espace de travail et configurez l’intégration Git.

2. Sélectionnez Se connecter et synchroniser avec votre référentiel ADO ou GitHub.

3. Sélectionnez les éléments de plan à télécharger vers le référentiel et sélectionnez Commit.

   

4. Vérifiez que l’état Git des éléments de plan est synchronisé.

5. Établir une discipline de validation : valider après chaque modification significative d’une définition de plan afin que le référentiel reflète toujours l’état le plus récent.

Étapes de rétablissement :

1. Créez un espace de travail W2 à l’intérieur de la capacité C2 dans la région saine.

2. Dans l’espace de travail W2, accédez aux paramètres de l’espace de travail et reconnectez-vous au même référentiel ADO/GitHub.

3. Sélectionnez Contrôle de code source. Sélectionnez la branche de dépôt appropriée, puis sélectionnez Mettre à jour tout. Tous les éléments de plan sont téléchargés sur W2.

Les composants suivants sont restaurés après la récupération :

• Feuilles PowerTable : Paramètres de table source, configuration de colonne, accès aux lignes, propriétés visuelles (disposition, formats, etc.), identification des lignes, paramètres de commentaire, dimensions à variation lente (SCD), approbations, automatisations et formulaires.
• Feuilles de planification : Propriétés de la feuille (mise en forme, mise en forme conditionnelle, etc.), paramètres de commentaire, paramètres d’écriture différée, colonnes d’entrée de données, lignes d’entrée de données, scénarios et signets.
• InfoBridge : Sources InfoBridge, requêtes InfoBridge, étapes de transformation, destinations d’écriture différée, paramètres d’écriture différée, mappages de requêtes liés, groupes de requêtes, propriétés visuelles (blend). Ces éléments ne peuvent pas être récupérés : sources basées sur des fichiers (CSV, Excel), feuilles de charge de travail croisée qui utilisent des sources basées sur des fichiers.
• Intelligence: Tous les graphiques et matrices.

Restauration Fabric SQL pour la planification

Les données entrées dans les feuilles de planification, les tables utilisées dans PowerTable et les données d’écriture différée sont stockées dans des bases de données SQL et doivent être considérées comme faisant partie de votre stratégie de récupération d’urgence. Pour récupérer des bases de données SQL, consultez la section base de données SQL .

• Métadonnées du plan de restauration : chaque élément de plan est associé à une base de données __fabric_plan_sys qui stocke les métadonnées pour les fonctionnalités de planification, notamment les commentaires, les scénarios, les entrées de données et la configuration de la réécriture. La base de données __fabric_plan_sys n’est pas restaurée automatiquement et doit être récupérée explicitement.

• Restaurer des bases de données d’écriture différée : si votre plan utilise des destinations d’écriture différée SQL, vous devez également récupérer les bases de données associées manuellement. Les destinations d’écriture différée SQL configurées ne sont pas restaurées automatiquement.

• Restaurer des tables utilisées dans PowerTable : toutes les tables créées à l’aide de PowerTable sont stockées dans une base de données SQL Fabric. Vous devez également récupérer ces tables pendant la récupération d’urgence.

Agents d’opérations

Les utilisateurs de l’agent d’exploitation doivent prendre des mesures proactives pour préparer la récupération d’urgence régionale. La suite de l’approche décrite dans cette section permet de s’assurer que vos agents peuvent être restaurés rapidement après une panne régionale.

Utilisez Fabric intégration Git pour synchroniser votre espace de travail avec un référentiel. Cette approche vous permet de reconstruire des configurations d’agent dans un nouvel espace de travail si le service bascule vers une autre région.

Les éléments de l’agent des opérations dans la région principale ne sont pas disponibles en cas de sinistre régional. Les configurations de l’agent, les modèles de comportement et les journaux d’activité ne sont pas répliqués dans la région secondaire. Les opérations en cours, les sessions de conversation actives et les événements précédemment ingérés au moment de la catastrophe sont également perdus.

Pour préparer la récupération, configurez Fabric intégration Git et synchronisez vos éléments d’agent avec votre référentiel ADO avant qu’un sinistre ne se produise.

Lors de la récupération, configurez votre nouvelle région et votre capacité dans Fabric, puis utilisez le référentiel synchronisé pour restaurer des configurations d’agent dans un nouvel espace de travail. Git Sync extrait le contenu stocké du référentiel dans l’espace de travail vide, recréant vos éléments d’agent.

Une fois les configurations restaurées, vérifiez que toutes les bases de données Eventhouse (KQL) référencées ou les sources de données spécifiques à la région sont accessibles dans la nouvelle région. Mettez à jour les références de point de terminaison dans les configurations de l’agent si nécessaire. Enfin, redémarrez vos agents et les utilisateurs lancent de nouvelles sessions de conversation. Les conversations précédentes ne peuvent pas être reprise.

Base de données transactionnelle

Ce guide décrit les procédures de récupération pour l’expérience de base de données transactionnelle.

SQL database

Pour vous protéger contre une défaillance régionale, les utilisateurs de bases de données SQL peuvent prendre des mesures proactives pour exporter régulièrement leurs données et utiliser les données exportées pour recréer la base de données dans un nouvel espace de travail si nécessaire.

Pour ce faire, utilisez l’outil CLI SqlPackage qui fournit la portabilité de la base de données et facilite les déploiements de base de données.

1. Utilisez l’outil SqlPackage pour exporter la base de données dans un .bacpac fichier. Pour plus d’informations, consultez Exporter une base de données avec SqlPackage .
2. Stockez le .bacpac fichier dans un emplacement sécurisé qui se trouve dans une région différente de celle de la base de données. Les exemples incluent le stockage du fichier .bacpac dans un Lakehouse situé dans une autre région, à l’aide d’un compte de stockage Azure géoredondant ou d’un autre support de stockage sécurisé situé dans une autre région.
3. Si la base de données et la région SQL ne sont pas disponibles, vous pouvez utiliser le .bacpac fichier avec SqlPackage pour recréer la base de données dans un espace de travail dans une nouvelle région – Espace de travail C2. W2 dans la région B, comme décrit dans le scénario ci-dessus. Suivez les étapes détaillées dans Importer une base de données avec SqlPackage pour recréer la base de données avec votre .bacpac fichier.

La base de données recréée est une base de données indépendante de la base de données d’origine et reflète l’état des données au moment de l’opération d’exportation.

Considérations relatives au retour arrière

La base de données recréée est une base de données indépendante. Les données ajoutées à la base de données recréée ne sont pas reflétées dans la base de données d’origine. Si vous prévoyez de revenir à la base de données d'origine une fois que la région d'origine sera à nouveau disponible, vous devrez envisager de rapprocher manuellement les données de la base de données recréée avec la base de données d’origine.

Platform

La plateforme fait référence aux services partagés et à l’architecture sous-jacents qui s’appliquent à toutes les charges de travail. Cette section décrit les procédures de récupération pour les capacités Fabric partagées.

Surveillance d’un espace de travail

La surveillance de l’espace de travail collecte des journaux d’activité dans l’espace de travail dans lequel vous l’activez. Après avoir récupéré votre espace de travail en tant que C2. W2, activez la surveillance de l’espace de travail sur W2. Il commence à collecter des données de surveillance pour l’espace de travail récupéré.

Les données de surveillance de l’espace de travail d’origine (C1.W1) ne sont pas reprises, car elles reflètent l’activité de l’espace de travail auquel elles sont associées.

Bibliothèque de variables

Microsoft Fabric bibliothèques de variables permettent aux développeurs de personnaliser et de partager des configurations d’éléments dans un espace de travail, ce qui simplifie la gestion du cycle de vie du contenu. Du point de vue de la récupération d’urgence, les utilisateurs de la bibliothèque de variables doivent se protéger de manière proactive contre un sinistre régional. Cela peut être effectué via l'intégration Git de Fabric, ce qui garantit qu'après un sinistre régional, la bibliothèque de variables d'un utilisateur reste disponible. Pour récupérer une bibliothèque de variables, nous vous recommandons les éléments suivants :

• Utilisez Fabric intégration Git pour synchroniser votre bibliothèque de variables avec votre référentiel ADO. En cas de sinistre, vous pouvez utiliser le référentiel pour reconstruire la bibliothèque de variables dans le nouvel espace de travail que vous avez créé. Procédez comme suit :

  1. Connectez votre espace de travail au dépôt Git comme décrit ici.
  2. Veillez à conserver WS et le dépôt synchronisés avec commit et update.
  3. Récupération : en cas de sinistre, utilisez le référentiel pour reconstruire la bibliothèque de variables dans un nouvel espace de travail :

• Dans l’espace de travail nouvellement créé, connectez-vous et synchronisez à nouveau avec votre dépôt ADO Azure.

• Tous les éléments Fabric de ce référentiel sont automatiquement téléchargés dans votre nouvel espace de travail.

• Après avoir synchronisé vos éléments à partir de Git, ouvrez vos bibliothèques de variables dans le nouvel espace de travail et sélectionnez manuellement le jeu de valeurs actives souhaité.

Clés gérées par le client pour les espaces de travail Fabric

Vous pouvez utiliser des clés gérées par le client (CMK) stockées dans Azure Key Vault pour ajouter une couche supplémentaire de chiffrement au-dessus des clés gérées par Microsoft pour les données au repos. Si Fabric devient inaccessible ou inopérable dans une région, ses composants basculent vers une instance de sauvegarde. Pendant le basculement, la fonctionnalité CMK prend en charge les opérations en lecture seule. Tant que le service Azure Key Vault reste opérationnel et que les autorisations du coffre sont intactes, Fabric continue de se connecter à votre clé et vous permet de lire les données normalement. Cela signifie que les opérations suivantes ne sont pas prises en charge pendant le basculement : activation et désactivation du paramètre CMK de l’espace de travail et mise à jour de la clé.

OneLake

Cette section vous guide tout au long des procédures de récupération pour les fonctionnalités OneLake. Pour plus d’informations sur la récupération d’urgence pour les données OneLake, consultez La récupération d’urgence de OneLake.

Stratégies de gestion du cycle de vie

Si Fabric devient inaccessible ou inopérable dans une région, votre stratégie de cycle de vie OneLake peut toujours être lue et mise à jour pendant le basculement. Toutes les données déplacées vers le niveau de stockage intermédiaire ou froid resteront dans ce niveau. Vous pouvez suivre ces étapes pour appliquer votre stratégie existante à votre nouvel espace de travail de récupération :

1. Utilisez « Export Policy » dans votre espace de travail d’origine et enregistrez l’intégralité de la stratégie de cycle de vie.
2. Appelez l’API Import Policy sur votre espace de travail récupéré, en utilisant votre stratégie de cycle de vie exportée comme corps de la requête.

Règles d’instance de ressource

Les règles d’instance de ressource vous aident à contrôler en toute sécurité l’accès aux données dans OneLake à l’aide d’identités de ressources Azure approuvées. Lors du basculement régional, le système continue d’appliquer les règles existantes relatives à l’accès en lecture. Toutefois, vous ne pouvez pas créer, mettre à jour ou supprimer des règles d’instance de ressource tant que l’espace de travail n’est pas retourné à un état accessible en écriture.

Informations connexes

• guide de récupération d’urgence Microsoft Fabric