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

Ce document vous fournit des conseils spécifiques à l’expérience pour récupérer vos données Fabric en cas de 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 de la région B. Si la région A fait face à des interruptions, le service Fabric de C1 bascule vers la région B.

L’image suivante illustre ce scénario. La zone à gauche illustre 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 totalement couverte après l’action du client pour restaurer le fonctionnement complet de ses services.

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

1. Créez une capacité Fabric 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 de C1.W1 à 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 Fabric afin d’aider les clients via le processus de récupération.

Engineering 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 aborde des lakehouses, des notebooks et des définitions de tâche Spark.

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 un espace de travail C2.W2. Nous recommandons deux approches pour la création 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 à partir de la lakehouse d’origine, reportez-vous aux données avec des chemins OneLake tels qu’abfss (consulter Connexion à Microsoft OneLake). Vous pouvez utiliser l’exemple de code suivant (voir Présentation des utilitaires Microsoft Spark) dans le notebook pour obtenir les chemins ABFS des fichiers et des tables à partir du lakehouse d’origine. (remplacer C1.W1 par le nom d’espace de travail réel)

   mssparkutils.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 une table à récupérer à la fois dans le nouveau lakehouse. 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 avec 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
   
   mssparkutils.fs.cp(source, destination, true)
   
   val filesToDelete = mssparkutils.fs.ls(s"$source/_delta_log")
       .filter{sf => sf.isFile && sf.modifyTime > timestamp}
   
   for(fileToDelte <- filesToDelete) {
       val destFileToDelete = s"$destination/_delta_log/${fileToDelte.name}"
       println(s"Deleting file $destFileToDelete")
       mssparkutils.fs.rm(destFileToDelete, false)
   }
   
   mssparkutils.fs.write(s"$destination/_delta_log/_last_checkpoint", "", true)
   

5. 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écifique à partir du lakehouse d’origine, utilisez Explorateur Stockage Azure. Consultez Intégrer OneLake à Explorateur Stockage Microsoft Azure pour découvrir des étapes détaillées. Pour des tailles volumineuses de données, utilisez l’Approche 1.

Notebook

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 façon de la simplifier et de l’accélérer est d’utiliser l’intégration Git 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 régénérer le notebook dans l’espace de travail 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éé, reconnectez-vous à votre référentiel 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 de fichiers, de dossiers ou d’instantanés 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é de notebook, enregistrez également ce dernier dans votre système de cliché de gestion de version ou 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 aux clients et le principal fichier de définition et le fichier de référence du notebook sont 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 de SJD en copiant le code à partir 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 l’Explorateur Stockage Azure pour copier des Libs, des Mains et des instantanés de l’élément SJD original 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 de la tâche (consultez les Étapes de récupération de lakehouses). 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 obtenir plus d’informations sur l’Explorateur Stockage Azure, voir Intégrer OneLake à l’Explorateur Stockage Azure.

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 Science des données de la région primaire restent indisponibles aux clients, et le contenu et les métadonnées des modèles et expériences ML ne sont pas répliqués vers 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, métriques d’exécutions historiques et 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 accompagne tout au long des procédures de récupération pour l’expérience Data Warehouse. Il aborde 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 temporaire dans l’espace de travail C2.W2 pour les données que vous copiez à partir de l’entrepôt d’origine.

2. Renseignez les tables Delta de l’entrepôt en tirant parti de l’explorateur d’entrepôts et des fonctionnalités T-SQL (voir Tables dans l’entrepôt 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 temporaire à partir de l’entrepôt d’origine en suivant les Étapes de récupération de lakehouses.

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 en 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.

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. Dans 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 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 l’intégration Git fabric, puis à synchroniser votre CopyJob avec votre référentiel 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 référentiel Azure ADO. Tous les éléments Fabric de ce référentiel sont automatiquement téléchargés vers 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

Les utilisateurs de "Apache Airflow Job in Fabric" doivent entreprendre des mesures proactives pour se protéger contre une catastrophe régionale.

Nous vous recommandons de gérer la redondance avec l’intégration de Fabric 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 dépôt ADO, créez un espace de travail, connectez-vous et synchronisez à nouveau votre dépôt Azure ADO. Tous les éléments Fabric, y compris Airflow, sont automatiquement téléchargés dans 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 ensembles de requêtes/bases de données KQL et des eventstreams.

Ensemble de requêtes/base de données KQL

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. Mise en place de bases de données KQL indépendantes : configurez au moins deux ensembles de requêtes/bases de données KQL sur des capacités Fabric dédiées. Celles-ci doivent être configurées dans deux différentes régions Azure (des régions jumelées Azure de préférence) 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 souhaités. Vérifiez que les sources de données et les destinations s’alignent correctement.

   • Stratégies : vérifiez que les deux bases de données sont une conservation des données similaire et d’autres stratégies 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 préparation 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érer.

Eventstream

Un eventstream est un emplacement centralisé dans la plateforme Fabric pour capturer, transformer et router des événements en temps réel vers diverses destinations (par exemple, des lakehouses, des ensembles de requêtes/bases de données KQL) 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 sur plusieurs sites. 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 être redondants géographiquement, 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.

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. Par exemple, le stockage du .bacpac fichier dans un Lakehouse situé dans une autre région, l’utilisation d’un compte de stockage Azure géoredondant ou l’utilisation d’un autre support de stockage sécurisé se trouve 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 à la restauration automatique

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 envisagez de restaurer automatiquement la base de données d’origine lorsque la région d’origine devient disponible, vous devez envisager de rapprocher manuellement les données de la base de données recréée vers 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 vous guide tout au long des procédures de récupération pour les expériences partagées. Il couvre les bibliothèques de gestion de variables.

Bibliothèque de variables

Les bibliothèques de variables Microsoft Fabric permettent aux développeurs de personnaliser et de partager des configurations d’éléments au sein d’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. Cette opération peut être effectuée via l’intégration De Fabric Git, 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 l’intégration De Fabric Git pour synchroniser votre bibliothèque de variables avec votre dépôt 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 référentiel Azure ADO.

• Tous les éléments Fabric de ce référentiel sont automatiquement téléchargés vers 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 en plus 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. Si le service Azure Key Vault fonctionne correctement et que les autorisations du coffre restent intactes, Fabric continuera de se connecter à votre clé de chiffrement et vous permettra 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é.

Informations connexes

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