Orientação de recuperação de desastres específica para situações

Este artigo fornece orientações específicas da experiência para recuperar os seus dados do Fabric em caso de desastre numa região.

Cenário de exemplo

Muitas secções de orientação neste artigo utilizam o seguinte exemplo de cenário para fins de explicação e ilustração. Consulte novamente este cenário conforme necessário.

Digamos que você tenha uma capacidade C1 na região A que tenha um espaço de trabalho W1. Se ativou recuperação em desastres para capacidade C1, os dados do OneLake são replicados para um backup na região B. Se a região A enfrentar interrupções, o serviço Fabric em C1 passa para a região B.

A imagem a seguir ilustra esse cenário. A caixa à esquerda mostra a região afetada. A caixa no meio representa a disponibilidade contínua dos dados após o failover, e a caixa à direita mostra a situação totalmente coberta depois que o cliente age para restaurar seus serviços para o pleno funcionamento.

Eis o plano geral de recuperação:

1. Crie uma nova capacidade Fabric C2 numa nova região.

2. Crie um novo espaço de trabalho W2 em C2, incluindo seus itens correspondentes com os mesmos nomes que em C1. W1.

3. Copie os dados do C1.W1 interrompido para C2.W2.

4. Siga as instruções dedicadas para cada componente para restaurar os itens para a sua função completa.

Este plano de recuperação assume que a região de residência dos inquilinos permanece operacional. Se a região de origem do inquilino sofrer uma interrupção, os passos descritos neste artigo dependem da sua recuperação, que deve ser iniciada e concluída primeiro pela Microsoft.

Planos de recuperação adaptados a experiências específicas

As secções seguintes fornecem orientações passo a passo para cada experiência do Fabric, para ajudar no processo de recuperação.

Engenheria de Dados

Este guia orienta você pelos procedimentos de recuperação para a experiência de Engenharia de Dados. Abrange lakehouses, notebooks, definições de tarefas do Spark, funções de dados do utilizador e APIs GraphQL.

Casa do Lago

As residências à beira do lago da região original permanecem indisponíveis para os clientes. Para recuperar uma casa do lago, os clientes podem recriá-la no espaço de trabalho C2. W2. Recomendamos duas abordagens para recuperar casas de lago:

Abordagem 1: Usando script personalizado para copiar tabelas e arquivos Lakehouse Delta

Os clientes podem recriar lakehouses usando um script Scala personalizado.

1. Crie a casa do lago (por exemplo, LH1) no espaço de trabalho C2 recém-criado. W2.

2. Crie um novo bloco de anotações no espaço de trabalho C2. W2.

3. Para recuperar as tabelas e ficheiros do lakehouse original, consulte os dados com os caminhos OneLake, como abfss (ver Ligar ao Microsoft OneLake). Pode usar o seguinte exemplo de código (ver Introdução às Microsoft Spark Utilities) no notebook para obter os caminhos ABFS dos ficheiros e tabelas do lakehouse original. (Substituir C1.W1 pelo nome real do espaço de trabalho)

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

4. Use o exemplo de código a seguir para copiar tabelas e arquivos para o lakehouse recém-criado.

   1. Para tabelas Delta, você precisa copiar a tabela uma de cada vez para recuperar na nova casa do lago. No caso de arquivos Lakehouse, você pode copiar a estrutura completa do arquivo com todas as pastas subjacentes com uma única execução.

   2. Entre em contato com a equipa de suporte para obter a marca temporal necessária do failover no 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. Depois de executar o script, as tabelas aparecem na nova casa do lago.

Abordagem 2: Usar o Explorador de Armazenamento do Azure para copiar ficheiros e tabelas

Para recuperar apenas ficheiros ou tabelas específicas de um Lakehouse a partir do Lakehouse original, use o Explorador de Armazenamento do Azure. Consulte Integrar OneLake com Explorador de Armazenamento do Azure para passos detalhados. Para tamanhos de dados grandes, use a Abordagem 1.

A recuperação de Fabric materializou vistas para o lago

Após o failover, não consegues aceder às vistas materializadas do lago a partir da região original. O processo de failover não replica os cronogramas de atualização ou o histórico de execução para a região secundária. Para recuperar estes itens, complete os seguintes passos após recuperar os seus dados de Lakehouse:

• Recupere as tabelas de Lakehouse utilizando a Abordagem 1 ou Abordagem 2 descrita anteriormente neste artigo. Copie apenas as tabelas de origem.
• Recupera os cadernos que contêm as definições do teu MLV. Para os procedimentos de recuperação, consulte a secção Bloco de notas.
• Executar os cadernos recuperados para recriar os MLVs no novo Lakehouse. Para informações sobre a criação de MLVs, consulte Criar uma Vista de Lago Materializada. Se copiaste MLVs no passo anterior, executa CREATE OR REPLACE quando os recriares.
• Recriar manualmente os agendamentos de atualização do MLV no novo espaço de trabalho. Não consegues recuperar o histórico de agendamento ou métricas de execução.
• Se os seus MLVs fornecem modelos semânticos ou relatórios, verifique e atualize as referências do ID Lakehouse e do ID do conjunto de dados conforme necessário. Reconecte os relatórios ao modelo semântico atualizado e valide a novidade dos dados.

Bloco de Notas

Os cadernos da região principal continuam indisponíveis para os clientes, e o código nos cadernos não se replica para a região secundária. Para recuperar código de caderno na nova região, utilize uma das seguintes abordagens.

Abordagem 1: Redundância gerenciada pelo usuário com integração Git (em visualização pública)

Use a integração do Fabric Git para sincronizar o seu portátil com o seu repositório Azure DevOps (ADO). Depois de o serviço passar para outra região, use o repositório para reconstruir o caderno no novo espaço de trabalho que criou.

1. Configure a Integração Git para seu espaço de trabalho e selecione Conectar e sincronizar com o repositório ADO.

   

   A imagem a seguir mostra o bloco de anotações sincronizado.

   

2. Recupere o bloco de anotações do repositório ADO.

   1. No espaço de trabalho recém-criado, ligue-se novamente ao seu repositório Azure ADO.

      

   2. Selecione o botão Controle do código-fonte . Em seguida, selecione a ramificação relevante do repositório. Em seguida, selecione Atualizar tudo. O bloco de notas original é apresentado.

      

      

   3. Se o notebook original tiver um lakehouse predefinido, consulte a secção Lakehouse para recuperar o lakehouse e, em seguida, ligue o lakehouse recém-recuperado ao notebook também recém-recuperado.

      

   4. A integração do Git não suporta sincronizar ficheiros, pastas ou instantâneos do notebook no explorador de recursos do notebook.

      1. Se o bloco de notas original tiver ficheiros no explorador de recursos do bloco de notas:

         1. Guarde ficheiros ou pastas num disco local ou noutro local.

         2. Recarregue o ficheiro a partir do seu disco local ou unidades na nuvem para o bloco de notas recuperado.

      2. Se o bloco de anotações original tiver um instantâneo do bloco de anotações, também salve o instantâneo no seu próprio sistema de controle de versão ou no disco local.

         

         

Para obter mais informações sobre a integração do Git, consulte Introdução à integração do Git.

Abordagem 2: Abordagem manual para fazer backup do conteúdo do código

Se não adotares a abordagem de integração do Git, guarda a versão mais recente do teu código, ficheiros no explorador de recursos e snapshot do caderno num sistema de controlo de versões como o Git. Recuperar manualmente o conteúdo do caderno após um desastre:

1. Usa a funcionalidade Importar caderno para importar o código do caderno que queres recuperar.

   

2. Após a importação, vá para o espaço de trabalho desejado (por exemplo, "C2. W2") para acessá-lo.

3. Se o notebook original tiver uma lakehouse padrão, consulte a seção Lakehouse. Em seguida, conecte o lakehouse recém-recuperado (que tem o mesmo conteúdo do lakehouse padrão original) ao notebook recém-recuperado.

4. Se o bloco de notas original tiver ficheiros ou pastas no explorador de recursos, volte a carregar os ficheiros ou pastas guardados no sistema de controlo de versão do utilizador.

Definição de trabalho do Spark

As definições de funções Spark (SJD) da região primária continuam indisponíveis, e o OneLake replica o ficheiro principal de definição e o ficheiro de referência no caderno para a região secundária. Se quiser recuperar o SJD na nova região, siga os passos manuais descritos nesta secção. As corridas históricas do SJD não são recuperadas.

Podes recuperar os itens SJD copiando o código da região original usando o Explorador de Armazenamento do Azure e reconectando manualmente as referências do Lakehouse após o desastre.

1. Criar um novo item SJD (por exemplo, SJD1) no novo espaço de trabalho C2. W2, com as mesmas definições e configurações do item SJD original (por exemplo, linguagem, ambiente, etc.).

2. Utilize o Explorador de Armazenamento do Azure para copiar Libs, Mains e Snapshots do item SJD original para o novo item SJD.

   

3. O conteúdo do código aparece no recém-criado SJD. Tem de adicionar manualmente a referência do Lakehouse recentemente recuperado ao trabalho (consulte os passos para recuperar o Lakehouse). Os utilizadores precisam de reintroduzir manualmente os argumentos originais da linha de comandos.

   

Agora você pode executar ou agendar seu SJD recém-recuperado.

Para detalhes sobre Explorador de Armazenamento do Azure, consulte Integrar OneLake com Explorador de Armazenamento do Azure.

Funções de dados do utilizador

Para recuperar as suas funções de dados de utilizador numa região saudável, utilize uma das seguintes abordagens.

Abordagem 1: Com integração Git (recomendada)

O mecanismo de recuperação preferido é a integração Fabric Git. Ao sincronizar projetos de funções de dados de utilizador com um repositório Azure DevOps ou GitHub, pode reconstruí-los rapidamente num novo espaço de trabalho após o failover.

Prepare-se para um desastre

1. Configure a integração do Fabric Git para o espaço de trabalho que aloja a função de dados do utilizador.
2. Ligue o espaço de trabalho a um repositório Azure DevOps ou GitHub.
3. Guarde todos os dados do utilizador no repositório e sincronize as alterações regularmente.
4. Armazene as definições específicas do ambiente separadamente em bibliotecas variáveis, se necessário.

Etapas de recuperação

Após um desastre regional:

1. Crie uma nova capacidade do Fabric numa região em bom estado, como a C2.
2. Crie um novo espaço de trabalho, como o W2, na nova capacidade.
3. Ligue o espaço de trabalho ao mesmo repositório Azure DevOps ou GitHub.
4. Abra Controlo de código-fonte e sincronize o conteúdo do repositório com o espaço de trabalho.
5. Recrie ou restaure todos os recursos dependentes do Fabric, como lakehouses, bases de dados SQL no Fabric, armazéns e Business Events.
6. Reimplementar as funções de dados do utilizador.
7. Validar a execução da função e a conectividade de dependências.
8. Atualize as aplicações posteriores, os pipelines de dados ou outros sistemas integrados para referenciarem as funções recuperadas.
9. Validação completa de ponta a ponta de todos os teus cenários.

Considerações importantes

• A integração com o Git recupera apenas código-fonte e ativos do projeto.
• Os registos históricos de execuções não são recuperados.
• Os sistemas a jusante podem exigir a reassociação dos pontos terminais.

Para mais informações, consulte Controlo de código-fonte e implementação das funções de dados do utilizador.

Abordagem 2: Recuperação manual

Se a integração com o Git não estava configurada antes do desastre, pode reconstruir manualmente as funções de dados do utilizador a partir de backups do código-fonte.

Prepare-se para um desastre

Complete regularmente as seguintes tarefas e armazene os itens num repositório externo de controlo de versões ou numa localização de backup:

• Exportar o código-fonte da função para um repositório GitHub.
• Documente e preserve a informação das dependências.
• Definições do ambiente do documento.

Etapas de recuperação

Após um desastre regional:

1. Crie uma nova capacidade do Fabric numa região em bom estado, como a C2.
2. Crie um novo espaço de trabalho, como o W2.
3. Recupere todos os recursos necessários para a função, incluindo lakehouses, bases de dados SQL no Fabric, armazéns, eventhouses e serviços externos.
4. Crie um novo projeto de função de dados do utilizador.
5. Importa ou recria o código-fonte da função.
6. Reaplique as definições de configuração em tempo de execução.
7. Reinstala todas as dependências de funções.
8. Reimplemente a função.
9. Reconfigure autenticação e autorização.
10. Recrie editores ou consumidores de Eventos de Negócio, caso sejam utilizados.
11. Complete testes de validação de ponta a ponta para os seus cenários e integrações.

GraphQL

Os itens GraphQL da região primária não estão disponíveis após um desastre regional, e as definições e configurações GraphQL não são replicadas para a região secundária. Para recuperar o GraphQL numa nova região, utilize uma das seguintes abordagens.

Abordagem 1: Redundância gerida pelo utilizador com integração Git

A melhor forma de tornar este processo fácil e rápido é usar a integração do Fabric Git e depois sincronizar o seu GraphQL com o seu repositório ADO. Depois de o serviço passar para outra região, podes usar o repositório para reconstruir o GraphQL no novo espaço de trabalho que criaste.

1. Crie um novo espaço de trabalho na capacidade e região alvo.

2. Recupere todas as fontes de dados dependentes, como bases de dados Lakehouse, Warehouse ou SQL, seguindo os respetivos passos de recuperação.

3. Atualize a definição do GraphQL para apontar para os recursos recém-recuperados, modificando referências específicas do ambiente, como IDs de workspace de origem, IDs de itens de origem e detalhes de ligação. Esta etapa assegura a ligação correta no momento da implantação.

4. Reimplante os itens GraphQL do repositório Git para o novo espaço de trabalho. Esta etapa recria a estrutura e configuração da API utilizando as definições atualizadas.

5. Reaplique as definições dos itens, incluindo funções, controlos de acesso e configuração de autenticação.

6. Reaplique referências de endpoint atualizando quaisquer aplicações ou integrações para usar o endpoint recém-criado do GraphQL.

7. Atualize quaisquer pipelines de implantação existentes que apontavam para o antigo espaço de trabalho, de modo a que passem a referenciar o espaço de trabalho recém-criado.

8. Valide a funcionalidade de ponta a ponta da API.

Abordagem 2: Abordagem manual

Se não adotar a abordagem de integração do Git, pode usar a seguinte abordagem manual para recuperar o GraphQL.

1. Crie um novo espaço de trabalho na capacidade e região alvo.

2. Recuperar todas as fontes de dados dependentes, como bases de dados Lakehouse, Warehouse ou SQL.

3. Recrie manualmente a API GraphQL no novo espaço de trabalho, incluindo definições de esquema, ligações de fontes de dados e relações.

4. Reaplique as definições dos itens, incluindo funções, controlos de acesso e configuração de autenticação.

5. Reaplique referências de endpoint atualizando quaisquer aplicações ou integrações para usar o endpoint recém-criado do GraphQL.

6. Atualize quaisquer pipelines de implantação existentes que apontavam para o antigo espaço de trabalho, de modo a que passem a referenciar o espaço de trabalho recém-criado.

7. Valide a funcionalidade de ponta a ponta da API.

Considerações importantes

1. O GraphQL baseia-se em dependências externas (como Lakehouse, Warehouse e SQL), que deve recuperar antes da implementação do GraphQL.

2. As definições da API GraphQL incluem referências específicas do ambiente (como sourceWorkspaceId e sourceItemId). Ao recuperar numa nova região, estas referências podem tornar-se inválidas. Atualize-os para apontar para recursos recém-provisionados.

3. A religação automática das fontes de dados não é garantida em cenários de recuperação de desastres, especialmente quando se utilizam credenciais guardadas ou ligações entre espaços de trabalho.

4. Outras definições de itens como monitorização, autorização, RBAC, introspeção e outras não se mantêm após o failover. Deve restabelecer estas definições na nova região.

References

• Visão geral da integração do Fabric Git - Microsoft Fabric | Microsoft Learn

• Controlo de código-fonte e pipelines de implementação na API para GraphQL - Microsoft Fabric | Microsoft Learn 

App

O sistema não replica as aplicações Fabric, incluindo o seu código, configuração e metadados, para regiões secundárias. Se a região principal falhar, a aplicação permanece indisponível. Para recuperação, armazene o código-fonte da aplicação fora do sistema no GitHub, Azure DevOps ou outro sistema de controlo de versão. Recupere os dados da aplicação separadamente, seguindo as orientações de recuperação de desastres para cada armazenamento de dados Fabric subjacente.

Abordagem manual

Pode recuperar manualmente uma aplicação Fabric após um desastre regional usando o código-fonte da aplicação e a CLI Rayfin. 

Prerequisites 

Antes de ocorrer um desastre:

• Armazene o código-fonte da Fabric App no GitHub, Azure DevOps ou noutro repositório de controlo de versão. 

• Documente o processo de recuperação.  

Passos de recuperação 

1. Crie um novo espaço de trabalho na capacidade e região alvo. 

2. Recuperar recursos dependentes antes de reimplantar a aplicação.  

3. Recupere o código-fonte mais recente da Fabric App do seu repositório de controlo de versões ou backup local. 

4. A partir do diretório de origem da aplicação, implemente a aplicação Fabric no espaço de trabalho de recuperação usando a CLI Rayfin. Execute rayfin up --workspace <new workspace>. 

5. Recupere o item filho da aplicação (base de dados SQL no Fabric) seguindo os respetivos procedimentos de recuperação.  

6. Reaplique definições ao nível do item, incluindo funções e controlos de acesso conforme necessário.  

7. Valide a funcionalidade da aplicação e assegure que os utilizadores têm as permissões corretas.  

Importante 

• Manter o código-fonte da Fabric App fora da região Fabric para permitir a recuperação.  

• Os dados da aplicação na base de dados não são recuperados como parte do processo de implementação do Fabric App e devem ser restaurados separadamente.  Pode recuperar manualmente uma aplicação Fabric após um desastre regional usando o código-fonte da aplicação e a CLI Rayfin. 

Azure Databricks Storage

Azure Databricks Storage armazena dados em OneLake. Para proteger os seus dados contra uma falha regional, ative a definição de recuperação de desastres na capacidade do Fabric que contém o item Azure Databricks Storage. Quando ativas esta definição, o OneLake replica assíncronamente os dados para a região emparelhada do Azure.

Se o OneLake iniciar um failover regional, as aplicações podem continuar a aceder aos dados replicados através do endpoint global OneLake após o fim do failover. O acesso contínuo através das APIs públicas do OneLake não requer criar outro item do Azure Databricks Storage ou copiar os dados para outro espaço de trabalho.

Consulte o OneLake Disaster Recovery and Data Protection para conhecer o comportamento, considerações e limitações aplicáveis.

Para planeamento específico de recuperação de desastres do Azure Databricks, veja Recuperação de desastres - Azure Databricks.

Ciência de Dados

Este guia orienta você pelos procedimentos de recuperação para a experiência de Ciência de Dados. Abrange modelos e experiências de ML.

Modelo e experimento de ML

Os itens de Ciência de Dados da região primária continuam indisponíveis para os clientes, e o conteúdo e os metadados nos modelos e experiências de ML não se replicam para a região secundária. Para recuperá-los totalmente na nova região, salve o conteúdo do código em um sistema de controle de versão (como o Git) e execute manualmente o conteúdo do código novamente após o desastre.

1. Recupere o bloco de notas. Consulte as etapas de recuperação do Notebook.

2. A configuração, as métricas executadas anteriormente e os metadados não são replicados para a região emparelhada. Tens de recorrer cada versão do teu código de ciência de dados para recuperar totalmente os modelos e experiências de ML após o desastre.

Armazém de Dados

Este guia guia-o pelos procedimentos de recuperação para a carga de trabalho Fabric Data Warehouse. Cobre artigos de armazém.

Armazém

Não consegues aceder a armazéns da região original. Para recuperar armazéns, use as duas etapas a seguir.

1. Crie uma nova casa de lago provisória no espaço de trabalho C2. W2 para os dados que copiares do armazém original.

2. Preenche as tabelas Delta do armazém usando o Explorador do armazém e as capacidades T-SQL (ver Tabelas em Fabric Data Warehouse).

Ingestão de dados via Lakehouse e código T-SQL

No espaço de trabalho recém-criado C2.W2:

1. Crie uma casa de lago provisória "LH2" em C2. W2.

2. Recupere as tabelas Delta no lakehouse interino do armazém original seguindo as etapas de recuperação Lakehouse.

3. Crie um novo armazém "WH2" em C2. W2.

4. Conecte a casa do lago provisória em seu explorador de armazém.

5. Dependendo de como implementas as definições de tabelas antes da importação de dados, o T-SQL real usado para importações pode variar. Para recuperar tabelas do Warehouse a partir de lakehouses, pode utilizar a abordagem INSERT INTO, SELECT INTO ou CREATE TABLE AS SELECT. No exemplo seguinte, usamos INSERT INTO. Se usar o código seguinte, substitua exemplos por nomes reais de tabelas e colunas.

   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. Altere a cadeia de ligação nas aplicações que utilizam o armazém do Fabric.

Base de dados espelhada

Os clientes não conseguem aceder a bases de dados espelhadas da região principal, e as definições não se replicam para a região secundária. Para recuperar uma base de dados espelhada após uma falha regional, é necessário recriá-la noutro espaço de trabalho de uma região diferente.

Data Factory

Os clientes não conseguem aceder a itens Data Factory da região principal, e as definições e configuração nos pipelines ou nos itens Dataflow Gen2 não se replicam para a região secundária. Para recuperar estes itens após uma falha regional, precisa de recriar os seus itens de Integração de Dados noutro espaço de trabalho de uma região diferente. As seções a seguir descrevem os detalhes.

Fluxos de dados Gen2

Para recuperar um item Dataflow Gen2 na nova região, exporte um .pqt ficheiro para um sistema de controlo de versões como o Git, e depois recupere manualmente o conteúdo Dataflow Gen2 após o desastre.

1. A partir do seu item Dataflow Gen2, no separador Início do editor Power Query, selecione Exportar modelo.

   

2. No diálogo Exportar modelo , introduza um nome (obrigatório) e uma descrição (opcional) para este modelo. Quando terminar, selecione OK.

   

3. Após o desastre, crie um novo item Dataflow Gen2 no novo espaço de trabalho "C2. W2".

4. No painel de visualização atual do editor de Power Query, selecione Importar de um modelo de Power Query.

   

5. No diálogo Abrir, navegue até à sua pasta predefinida de transferências e selecione o .pqt ficheiro que guardou nos passos anteriores. Em seguida, selecione Abrir.

6. O modelo é então importado para o novo item Dataflow Gen2.

A funcionalidade Guardar Como para Dataflows não é suportada em caso de recuperação de desastres.

Tubulações

Os clientes não podem aceder a pipelines em caso de um desastre regional, e as configurações não são replicadas para a região emparelhada. Construa os seus pipelines críticos em múltiplos espaços de trabalho em diferentes regiões.

Trabalho de cópia

Os usuários do CopyJob devem tomar medidas proativas para se proteger contra um desastre regional. A abordagem a seguir garante que, após um desastre regional, os CopyJobs de um usuário permaneçam disponíveis.

Redundância gerenciada pelo usuário com integração Git (em visualização pública)

A melhor forma de tornar este processo fácil e rápido é usar integração com o Fabric Git e depois sincronizar o seu CopyJob com o seu repositório Azure DevOps. Depois que o serviço fizer failover para outra região, você poderá usar o repositório para reconstruir o CopyJob no novo espaço de trabalho criado.

1. Configure a integração Git do seu espaço de trabalho e selecione ligar e sincronizar com o repositório Azure DevOps.

   

   A imagem a seguir mostra o CopyJob sincronizado.

   

2. Recuperar o CopyJob do repositório Azure DevOps.

   1. No espaço de trabalho recém-criado, ligue-se e sincronize novamente com o seu repositório Azure DevOps. Todos os itens Fabric deste repositório são automaticamente descarregados para o seu novo espaço de trabalho.

      

   2. Se o CopyJob original usar um Lakehouse, os utilizadores podem consultar a seção do Lakehouse para recuperar o Lakehouse e, em seguida, conectar o CopyJob recém-recuperado ao Lakehouse recém-recuperado.

Para obter mais informações sobre a integração do Git, consulte Introdução à integração do Git.

Tarefa Apache Airflow

Deve tomar medidas proativas para proteger os empregos da Apache Airflow em Fabric contra um desastre regional.

Gerir a redundância usando a integração com Fabric Git. Primeiro, sincroniza o teu trabalho Airflow com o teu repositório ADO. Se o serviço fizer failover para outra região, podes usar o repositório para reconstruir o trabalho Airflow no novo espaço de trabalho que criaste.

Siga estes passos para alcançar este objetivo:

1. Configure a integração Git do seu espaço de trabalho e selecione Ligar e sincronizar com o repositório ADO.

2. Depois disso, vês o teu trabalho Airflow sincronizado com o teu repositório ADO.

3. Se precisares de recuperar o trabalho Airflow do repositório ADO, cria um novo espaço de trabalho, liga-te e sincroniza novamente com o repositório Azure ADO. Todos os itens Fabric, incluindo o Airflow, neste repositório descarregam automaticamente para o seu novo espaço de trabalho.

Informação em Tempo Real

Este guia orienta você pelos procedimentos de recuperação para a experiência de Inteligência em Tempo Real. Abrange bases de dados KQL, conjuntos de consultas e itens de eventstream.

Activator

Os itens ativadores da região principal continuam indisponíveis para os clientes, e as definições de gatilhos ativadores não são replicadas para a região secundária. Os utilizadores do ativador devem tomar medidas proativas para se preparar para a recuperação regional de desastres.

Para garantir que pode recuperar itens Ativadores em caso de desastre regional, configure a integração com o Fabric Git para fazer backup das definições de gatilhos e restaurá-las num espaço de trabalho noutra região.

1. Configure a integração do Fabric Git para o espaço de trabalho que contém o seu item Ativador e sincronize as definições dos seus gatilhos com o seu repositório Git.
2. Mantenha as definições dos acionadores do Activator confirmadas e sincronizadas regularmente.
3. Durante a recuperação, crie um novo espaço de trabalho na região-alvo (C2. W2), liga-o ao mesmo repositório e sincroniza para restaurar as definições dos gatilhos.
4. Reconfigure e valide todas as fontes de dados e dependências do Ativador no novo espaço de trabalho.

Para obter mais informações sobre a integração do Git, consulte Introdução à integração do Git.

Modelo de grafo/conjunto de consultas

Os clientes não conseguem aceder ao modelo Graph e aos itens do conjunto de consultas Graph da região principal, e o Fabric não replica estes itens para a região secundária. Para efetuar a recuperação, crie ou utilize uma capacidade numa região diferente e recrie o modelo Graph e os itens do queryset do Graph nessa região.

1. Crie ou use uma capacidade Fabric existente numa região diferente que não seja afetada pelo desastre.

2. Crie um novo espaço de trabalho ou use um espaço de trabalho existente nessa função.

3. Recrie o item do modelo Graph no espaço de trabalho secundário (referenciado no passo 2). Reconfigure a definição do modelo, incluindo nós, arestas e outros, para corresponder ao modelo original do Grafo.

4. Se a casa original do lago estiver na região em decadência, recupere-a primeiro seguindo a secção da Casa do Lago.

5. Ligue uma casa de lago como fonte de dados OneLake para o item recém-criado do modelo Graph. Use um data lakehouse recuperado se este estivesse na região com falhas, ou reconecte-se ao data lakehouse existente se este continuar disponível.

6. Reconfigure quaisquer horários de carregamento de dados ou ligações para o modelo Graph no novo espaço de trabalho.

7. Recrie o item do conjunto de consultas Graph no espaço de trabalho secundário. Reintroduza manualmente as consultas e quaisquer configurações de consultas guardadas do conjunto original de consultas do Graph.

Banco de dados KQL/Queryset

Os utilizadores da base de dados KQL e do queryset devem tomar medidas proativas para se protegerem contra desastres regionais. A abordagem seguinte garante que, no caso de um desastre regional, os dados nas suas bases de dados e conjuntos de consultas KQL permaneçam seguros e acessíveis.

Use as etapas a seguir para garantir uma solução eficaz de recuperação de desastres para bancos de dados e conjuntos de consultas KQL.

1. Configurar bases de dados KQL independentes: Configure duas ou mais bases de dados KQL independentes e querysets em capacidades dedicadas do Fabric. Configure estas bases de dados em duas regiões Azure diferentes (preferencialmente regiões emparelhadas com Azure) para maximizar a resiliência.

2. Replicar atividades de gestão: Espelhe qualquer ação de gestão que tome numa base de dados KQL na outra. Esta abordagem mantém ambas as bases de dados sincronizadas. Atividades-chave a replicar incluem:

   • Tabelas: Garantir que as estruturas das tabelas e as definições de esquemas são consistentes entre as bases de dados.

   • Mapeamento: duplique todos os mapeamentos necessários. Certifique-se de que as fontes e destinos de dados estão alinhados corretamente.

   • Políticas: Garantir que ambas as bases de dados têm políticas semelhantes de retenção, acesso e outras relevantes de dados.

3. Gerir autenticação e autorização: Definir as permissões necessárias para cada réplica. Certifique-se de estabelecer os níveis adequados de autorização, concedendo acesso ao pessoal necessário e mantendo os padrões de segurança.

4. Ingestão paralela de dados: para manter os dados consistentes e prontos em várias regiões, carregue o mesmo conjunto de dados em cada banco de dados KQL ao mesmo tempo em que o ingere.

Eventstream

Um fluxo de eventos é um local centralizado na plataforma Fabric para capturar, transformar e encaminhar eventos em tempo real para vários destinos (por exemplo, lakehouses, bases de dados/conjuntos de consultas KQL) com uma experiência sem código. Desde que os destinos suportem a recuperação de desastres, os fluxos de eventos não perdem dados. Por isso, utilize as capacidades de recuperação de desastres desses sistemas de destino para garantir a disponibilidade dos dados.

Também pode alcançar geo-redundância ao implementar cargas de trabalho de eventstream idênticas em múltiplas regiões do Azure como parte de uma estratégia multi-site ativo/ativo. Com uma abordagem ativa/ativa multi-site, pode aceder à sua carga de trabalho em qualquer uma das regiões implementadas. Essa abordagem é a mais complexa e dispendiosa para a recuperação de desastres, mas pode reduzir o tempo de recuperação para quase zero na maioria das situações. Para ser totalmente geo-redundante:

1. Crie réplicas das suas fontes de dados em diferentes regiões.

2. Criar itens de fluxo de eventos nas regiões correspondentes.

3. Conecte esses novos itens às fontes de dados idênticas.

4. Adicione destinos idênticos para cada fluxo de eventos em regiões diferentes.

Eventos Empresariais, Eventos Fabric e Eventos Azure

Embora os Business Events, Fabric Events e Azure Events partilhem a mesma infraestrutura Real-Time hub em Microsoft Fabric, têm origens, comportamentos e requisitos de recuperação distintos. Compreenda estas diferenças antes de planear a recuperação após desastres:

• Os Fabric Events são subscrições de eventos que reagem à atividade produzida pelos próprios recursos da Fabric. Estes eventos incluem alterações ao longo do ciclo de vida dos itens do espaço de trabalho (como a criação, atualização ou eliminação de lakehouses, notebooks ou warehouses), execuções de tarefas (como execuções de pipelines ou de notebooks) e operações em ficheiros e pastas no OneLake. Estas subscrições são do tipo push e efémeras. As subscrições não são replicadas para a região secundária.

• Os Azure Events são subscrições de eventos para atividades produzidas por contas do Armazenamento de Blobs do Azure. Estes recursos do Azure existem independentemente de qualquer capacidade ou região do Fabric. Embora o próprio recurso do Armazenamento de Blobs do Azure possa permanecer disponível durante uma interrupção regional do Fabric, as subscrições configuradas no Real-Time hub não são replicadas para a região secundária e têm de ser recriadas.

• Os Eventos Empresariais são uma funcionalidade distinta da Inteligência em Tempo Real do Fabric que permite às equipas definir, publicar e agir com base em sinais de negócio relevantes. Os eventos empresariais são gerados no Fabric através do Activator, de notebooks do Spark ou de Funções de Dados do Utilizador, sendo depois publicados no Real-Time hub, onde consumidores subsequentes, como o Activator, o Eventhouse ou o Power Automate, podem reagir aos mesmos. Os esquemas de eventos são governados centralmente através do Registo de Esquemas. O Eventhouse armazena automaticamente todos os eventos empresariais publicados, pelo que a sua recuperação afeta diretamente a disponibilidade do histórico de eventos empresariais. Nenhuma das configurações do editor ou consumidor, definições de esquema ou subscrições é replicada para a região secundária.

Use os seguintes passos para restaurar os Business Events, Fabric Events e Azure Events no novo espaço de trabalho na região de recuperação.

Para Eventos Empresariais:

1. Recrie o evento empresarial utilizado por editores e consumidores seguindo o artigo Criar Eventos Empresariais no Fabric Real-Time Hub. Durante a criação do evento de negócio, cria-se o recurso Event Schema Set (Conjunto de Esquemas de Evento). O recurso da Casa de Eventos é opcional dependendo do cenário. Se fizeste backup do teu conjunto de esquemas de eventos com integração com Git, restaura-o primeiro seguindo a secção do conjunto de esquemas de eventos, depois aponta o evento de negócio para o conjunto de esquemas restaurado.

2. Recrie quaisquer itens do publisher que gerem eventos empresariais, como cadernos Spark ou Funções de Dados do Utilizador, no novo espaço de trabalho seguindo os artigos do publisher: Usar a Função de Dados do Utilizador como Publisher de Eventos Empresariais, Usar o Ativador como Publisher de Eventos Empresariais, Usar o Caderno como Eventos Empresariais Publisher, e usar o Eventstream como Business Events Publisher.

3. Recrie as subscrições de consumidor no hub Real-Time (por exemplo, regras do Activator, disparadores de blocos de notas ou fluxos do Power Automate) que originalmente reagiam a eventos empresariais na região afetada, seguindo os artigos Integração do Eventhouse e do Dashboard em Tempo Real com Eventos Empresariais e Consumir Eventos Empresariais a partir do Activator.

4. Valide que os eventos estão a fluir de ponta a ponta, verificando que as subscrições estão ativas e que os dados estão a chegar aos destinos esperados na região de recuperação.

Para eventos do Fabric:

1. Recrie as subscrições no Real-Time hub que apontem para os itens da área de trabalho, tarefas ou caminhos do OneLake que restaurou na região de recuperação, seguindo o artigo Explorar eventos do Fabric no Fabric Real-Time hub.

2. Valide que os eventos estão a fluir de ponta a ponta, verificando que as subscrições estão ativas e que os dados estão a chegar aos destinos esperados na região de recuperação.

Para eventos Azure:

1. As contas do Armazenamento de Blobs do Azure não são afetadas por uma falha regional do Fabric. Recrie as subscrições de eventos no Real-Time hub, a apontar para as mesmas contas do Armazenamento de Blobs do Azure, seguindo o artigo Definir alertas para eventos do Armazenamento de Blobs do Azure no Real-Time hub.

2. Valide que os eventos estão a fluir de ponta a ponta, verificando que as subscrições estão ativas e que os dados estão a chegar aos destinos esperados na região de recuperação.

Esquema de evento definido

Um conjunto de esquemas de eventos é o Fabric item que contém definições de tipo de evento e esquema em Real-Time Intelligence. Outras capacidades baseiam-se nela: os editores escrevem eventos que seguem os seus esquemas, e os consumidores interpretam as mesmas definições.

Os conjuntos de esquemas de eventos da região principal permanecem indisponíveis para os clientes e não são replicados para a região secundária. No entanto, como um conjunto de esquemas de eventos é uma definição persistente criada, e não uma subscrição efémera, pode criar previamente uma cópia de segurança e restaurá-lo em vez de voltar a criá-lo manualmente.

Recomendado: backup com integração do Fabric Git

Para recuperar um esquema de eventos definido após um desastre regional, configure a integração do Fabric Git antes de ocorrer um desastre e sincronize o espaço de trabalho que contém os seus conjuntos de esquemas de eventos com o seu repositório Git.

1. Configura a integração do Fabric Git para o espaço de trabalho que contém o teu conjunto de esquemas de eventos e sincroniza-o com o teu repositório Git.

2. Mantenha o conjunto do esquema de eventos comprometido e sincronizado regularmente, especialmente após adicionar tipos de eventos ou publicar novas versões do esquema.

3. Durante a recuperação, crie um novo espaço de trabalho na região-alvo (C2. W2), liga-o ao mesmo repositório e sincroniza para restaurar o esquema de eventos definido. Como o novo espaço de trabalho está vazio, o Git sync traz o conteúdo do repositório para o espaço de trabalho.

4. Recrie quaisquer editoras e consumidores que utilizem o conjunto de esquemas, seguindo as orientações para esses tipos de itens.

5. Valide que os editores podem publicar nos tipos de evento restaurados e que os consumidores recebem os eventos conforme esperado.

A definição sincronizada inclui os tipos de eventos no conjunto de esquemas, os esquemas e as versões do esquema. Não inclui registos de editores, subscrições de consumidores ou histórico de eventos. Recupere-os separadamente, seguindo as orientações para os tipos de itens que utilizam o conjunto de esquemas.

Alternativa: recriar manualmente

Se não configurou a integração com o Git antes do desastre, recrie o conjunto de esquemas de eventos na região de recuperação seguindo Criar e gerir conjuntos de esquemas de eventos, depois adicione os tipos de eventos e esquemas que o conjunto original continha, seguindo Criar e gerir esquemas de eventos em conjuntos de esquemas.

Map

Os itens do mapa da região principal continuam indisponíveis para os clientes e os itens do mapa não são replicados para a região secundária.

Se quiser recuperar um item do Mapa quando acontecer um desastre, configure a integração do Git da Fabric e sincronize o seu item do Mapa com o seu repositório Git.

Durante a recuperação, depois de a nova região/capacidade no Fabric estar configurada, podes usar o repositório para reconstruir o item Map no novo espaço de trabalho que criaste. Como o novo espaço de trabalho está vazio, o Git sync coloca o conteúdo do repositório no espaço de trabalho vazio. Este passo traz o item do Mapa de volta à vida.

Ontologia

Os utilizadores de ontologias devem tomar medidas proativas para se prepararem para a recuperação regional de desastres. A abordagem descrita abaixo garante que, após um desastre regional, a sua Ontologia permaneça recuperável e possa ser restaurada rapidamente.

A forma mais simples e rápida de permitir a recuperação é usar a integração com o Fabric Git e sincronizar a sua Ontologia com um repositório Azure DevOps (ADO). Caso o serviço faça failover para outra região, pode usar este repositório para reconstruir a Ontologia num espaço de trabalho recém-criado.

Os itens de ontologia na região primária não estão disponíveis para os clientes após um desastre regional, e os itens de Ontologia não são replicados para a região secundária.

Para recuperar um item de Ontologia durante um desastre, configure a integração Git do Fabric e sincronize o item de Ontologia com o seu repositório ADO antecipadamente.

Durante a recuperação, uma vez que a nova região e capacidade no Fabric estejam configuradas, pode usar o repositório para reconstruir o item Ontology num novo espaço de trabalho. Como o novo espaço de trabalho está vazio, o Git sync puxa o conteúdo do repositório para o espaço de trabalho, restaurando efetivamente o item Ontologia.

Agente de Ontologia

Os utilizadores do Ontology Agent devem tomar medidas proativas para se prepararem para a recuperação após desastre a nível regional. A abordagem descrita nesta secção garante que, após um desastre regional, a sua experiência com o Ontology Agent pode ser restaurada num espaço de trabalho recém-criado.

O Agente de Ontologia depende do item da Ontologia e de quaisquer fontes de dados que estejam ligadas à Ontologia, como os lakehouses. Os clientes não conseguem aceder às sessões do Agente de Ontologia na região principal após um desastre regional, e as sessões do Agente de Ontologia não são replicadas para a região secundária. Sessões de chat ativas, ações em curso e histórico de conversas da região afetada não podem ser retomados.

Para recuperar a experiência do Ontology Agent durante um desastre, configure a integração com o Fabric Git e sincronize o item Ontology com o seu repositório Azure DevOps (ADO) antecipadamente.

Durante a recuperação, uma vez que a nova região e capacidade no Fabric estejam configuradas, complete os seguintes passos:

1. Crie um novo espaço de trabalho na nova capacidade.
2. Ligue o novo espaço de trabalho ao mesmo repositório ADO que contém o item Ontologia.
3. Utilize o Git sync para restaurar o item Ontology no novo espaço de trabalho.
4. Recupere quaisquer itens de dados dependentes, como lakehouses, seguindo as orientações para esses tipos de itens.
5. Confirme que os dados recuperados estão disponíveis na região emparelhada. Para dados respaldados pelo OneLake, assuma que os dados são replicados para a região emparelhada, mas não assuma a ordem dos dados replicados durante a recuperação.
6. Ligue o item de Ontologia recém-recuperado às fontes de dados recuperadas.
7. Inicie uma nova sessão com o Agente de Ontologia e valide que o agente pode ligar-se ao item de Ontologia recuperado e às fontes de dados.

Planning

Este artigo descreve os procedimentos de recuperação para a experiência de planeamento no IQ. Descreve os passos necessários para restaurar componentes-chave, incluindo folhas de planeamento, folhas PowerTable, folhas de inteligência, InfoBridge e ativos de dados relacionados.

Integração com o git para restaurar itens do plano

A abordagem preferida é sincronizar todos os itens do plano com um repositório Azure DevOps (ADO) ou GitHub, utilizando integração com Fabric Git. Após um failover, use o repositório para restaurar os itens no novo espaço de trabalho.

Pré-desastre (medidas proativas):

1. No workspace W1, vai às Definições do Workspace e configura a integração com o Git.

2. Selecione Ligar e sincronizar com o seu repositório ADO ou GitHub.

3. Selecione os itens do plano para carregar para o repositório e selecione Commit.

   

4. Confirme que o estado do Git dos itens do plano está Sincronizado.

5. Estabeleça uma disciplina de commits – faça um commit após cada alteração significativa na definição de um plano, para que o repositório reflita sempre o estado mais recente.

Passos de recuperação:

1. Crie um novo espaço de trabalho W2 dentro da capacidade C2 na zona saudável.

2. No workspace W2, vai às Definições do Workspace e volta a ligar-te ao mesmo repositório ADO/GitHub.

3. Selecione Controlo de Versões. Selecione o ramo do repositório relevante e selecione Atualizar Tudo. Todos os itens do plano são descarregados para o W2.

Os seguintes componentes são restaurados após a recuperação:

• Folhas da PowerTable: Definições da tabela de origem, configuração das colunas, acesso às linhas, propriedades visuais (layout, formatos, entre outras), identificação das linhas, definições de comentários, dimensões de alteração lenta (SCD), aprovações, automatizações e formulários.
• Folhas de planeamento: Propriedades da folha (formatação, formatação condicional e mais), definições de comentários, definições de writeback, colunas de entrada de dados, linhas de entrada de dados, cenários e favoritos.
• InfoBridge: origens do InfoBridge, consultas do InfoBridge, passos de transformação, destinos de reescrita, definições de reescrita, mapeamentos de consultas associadas, grupos de consultas, propriedades visuais (mistura). Estes itens não podem ser recuperados: fontes baseadas em ficheiros (CSV, Excel), folhas de trabalho cruzadas que usam fontes baseadas em ficheiros.
• Inteligência: Todos os gráficos e matrizes.

Restauro do SQL do Fabric para fins de planeamento

Os dados introduzidos em folhas de planeamento, tabelas usadas no PowerTable e dados de writeback são armazenados em bases de dados SQL e devem ser considerados como parte da sua estratégia de recuperação de desastres. Para recuperar bases de dados SQL, consulte a secção de bases de dados SQL .

• Restaurar metadados do plano: Cada item do plano está associado a uma base de dados __fabric_plan_sys que armazena metadados para funcionalidades de planeamento, incluindo comentários, cenários, entradas de dados e configuração de writeback. A base de dados __fabric_plan_sys não é restaurada automaticamente e tem de ser recuperada explicitamente.

• Restaurar bases de dados de escrita diferida: Se o seu plano utiliza destinos SQL de escrita diferida, deve também recuperar manualmente as bases de dados associadas. Os destinos de writeback SQL configurados não são restaurados automaticamente.

• Restaurar tabelas usadas no PowerTable: Quaisquer tabelas criadas através do PowerTable são armazenadas numa base de dados SQL no Fabric. Também tens de recuperar estas tabelas durante o DR.

Agentes de operações

Os utilizadores dos agentes de operações devem tomar medidas proativas para se preparar para a recuperação regional de desastres. Seguir a abordagem descrita nesta secção ajuda a garantir que os seus agentes possam ser restaurados rapidamente após uma interrupção regional.

Use a integração do Fabric Git para sincronizar o seu espaço de trabalho com um repositório. Esta abordagem permite-lhe reconstruir configurações de agentes num novo espaço de trabalho caso o serviço faça failover para outra região.

Os itens dos agentes operacionais na região principal não estão disponíveis em caso de desastre regional. Configurações de agentes, modelos de comportamento e registos de atividade não são replicados para a região secundária. Operações em andamento, sessões ativas de chat e eventos previamente ingeridos no momento do desastre também são perdidos.

Para preparar a recuperação, configure a integração com o Fabric Git e sincronize os seus itens de agente com o seu repositório ADO antes de ocorrer um desastre.

Ao recuperar, configura a tua nova região e capacidade no Fabric, depois usa o repositório sincronizado para restaurar as configurações do agente num espaço de trabalho novo. O git sync retira o conteúdo armazenado do repositório para o espaço de trabalho vazio, recriando os itens do teu agente.

Uma vez restauradas as configurações, confirme que quaisquer bases de dados Eventhouse (KQL) referenciadas ou fontes de dados específicas por região estão acessíveis na nova região. Atualize as referências dos endpoints nas configurações do agente conforme necessário. Por fim, reinicie os seus agentes e peça aos utilizadores para iniciar novas sessões de chat. Conversas anteriores não podem ser retomadas.

Databases

Este guia descreve os procedimentos de recuperação para a experiência da base de dados.

base de dados SQL

Para se proteger contra uma falha regional, os usuários de bancos de dados SQL podem tomar medidas proativas para exportar periodicamente seus dados e usar os dados exportados para recriar o banco de dados em um novo espaço de trabalho quando necessário.

Use a ferramenta CLI SqlPackage , que proporciona portabilidade da base de dados e facilita a implementação de bases de dados.

1. Use a ferramenta SqlPackage para exportar o banco de dados para um .bacpac arquivo. Consulte Exportar um banco de dados com SqlPackage para obter mais detalhes.
2. Guarda o .bacpac ficheiro num local seguro que esteja numa região diferente da base de dados. Exemplos incluem armazenar o .bacpac ficheiro num Lakehouse numa região diferente, usar uma conta Armazenamento do Azure geo-redundante, ou usar outro meio de armazenamento seguro que esteja numa região diferente.
3. Se o banco de dados SQL e a região não estiverem disponíveis, você poderá usar o .bacpac arquivo com SqlPackage para recriar o banco de dados em um espaço de trabalho em uma nova região – Workspace C2. W2 na região B, conforme descrito no cenário acima. Siga as etapas detalhadas em Importar um banco de dados com SqlPackage para recriar o banco de dados com seu .bacpac arquivo.

O banco de dados recriado é um banco de dados independente do banco de dados original e reflete o estado dos dados no momento da operação de exportação.

Considerações sobre a reversão para estado original

O banco de dados recriado é um banco de dados independente. Os dados adicionados à base de dados recriada não seriam refletidos na base de datos original. Se planeia efetuar o failback para a base de dados original quando a região principal voltar a estar disponível, deve ter em conta que terá de reconciliar manualmente os dados da base de dados recriada com os da base de dados original.

Platform

Plataforma refere-se aos serviços compartilhados subjacentes e arquitetura que se aplicam a todas as cargas de trabalho. Esta secção descreve procedimentos de recuperação para capacidades partilhadas do Fabric.

Monitoramento de espaço de trabalho

A monitorização do espaço de trabalho recolhe registos sobre a atividade no espaço de trabalho onde a ativas. Depois de recuperares o teu espaço de trabalho como C2. W2, ativa a monitorização do espaço de trabalho no W2. Começa a recolher dados de monitorização para o espaço de trabalho recuperado.

Os dados de monitorização do espaço de trabalho original (C1.W1) não são transferidos, porque a monitorização reflete a atividade do espaço de trabalho em que é executada.

Biblioteca de variáveis

As bibliotecas Microsoft Fabric Variable permitem aos programadores personalizar e partilhar configurações de itens dentro de um espaço de trabalho, simplificando a gestão do ciclo de vida do conteúdo. Do ponto de vista da recuperação de desastres, os usuários de bibliotecas variáveis devem se proteger proativamente contra um desastre regional. Esta proteção pode ser feita através da integração Fabric Git, que garante que, após um desastre regional, a biblioteca de variáveis do utilizador permaneça disponível. Para recuperar uma biblioteca de variáveis, siga estes passos:

• Use a integração do Fabric Git para sincronizar a sua biblioteca de variáveis com o seu repositório ADO. Em caso de desastre, você pode usar o repositório para reconstruir a biblioteca de variáveis no novo espaço de trabalho criado. Use as seguintes etapas:

  1. Conecte seu espaço de trabalho ao repositório Git conforme descrito aqui.
  2. Certifique-se de manter o WS e o repositório sincronizados com Confirmar e Atualizar.
  3. Recuperação - Em caso de desastre, use o repositório para reconstruir a biblioteca de variáveis em um novo espaço de trabalho:

• No espaço de trabalho recém-criado, ligue-se e sincronize novamente com o seu repositório Azure ADO.

• Todos os itens Fabric neste repositório são automaticamente descarregados para o seu novo Workspace.

• Depois de sincronizar seus itens do Git, abra suas Bibliotecas de Variáveis no novo espaço de trabalho e selecione manualmente o conjunto de valores ativos desejado.

Plano de implantação

Um plano de implementação é um item num espaço de trabalho Fabric. Agrupa os itens e define a ordem para os distribuir. Pode executar ações antes ou depois de cada item ser lançado. A definição do item armazena estas definições, entradas e referências de itens. O plano não tem um armazenamento separado para valores usados em tempo de execução.

Prepare-se para a recuperação utilizando a integração Fabric Git:

1. Ligue o espaço de trabalho que contém o plano a um repositório Azure DevOps ou GitHub.
2. Confirme o plano e todos os itens do espaço de trabalho que este utiliza.
3. Faça commit de cada alteração para que o Git tenha as definições mais recentes.

Após um desastre regional:

1. Crie um espaço de trabalho na região saudável.
2. Ligue a área de trabalho ao mesmo repositório e ramo.
3. Atualize o espaço de trabalho a partir do Git. Este passo restaura o plano e os seus itens.

O git restaura a definição completa do plano. Não restaura os dados nem o estado de execução dos itens ligados. Use as secções deste artigo para recuperar esses itens.

Chaves geridas pelo cliente para os workspaces do Fabric

Pode usar chaves geridas pelo cliente (CMK) armazenadas no Azure Key Vault para adicionar uma camada extra de encriptação por cima das chaves geridas pela Microsoft para os dados em repouso. Se o Fabric se tornar inacessível ou inoperacional numa região, os seus componentes fazem failover para uma instância de backup. Durante o failover, o recurso CMK suporta operações em modo de leitura. Desde que o serviço Azure Key Vault se mantenha operacional e as permissões do cofre permaneçam intactas, o Fabric continua a aceder à sua chave e permite-lhe ler dados normalmente. Isso significa que as seguintes operações não são suportadas durante o failover: habilitar e desabilitar a configuração CMK do espaço de trabalho e atualizar a chave.

Fabric Assistente de Migração para base de dados SQL em Fabric

O Fabric Assistente de Migração pode mover uma base de dados SQL Server para uma base de dados SQL em Fabric em três etapas: o assistente de migração cria a base de dados alvo e inicia a migração, o monitor de migração acompanha o progresso enquanto o esquema é implementado a partir de um DACPAC, o Assistente de Migração ajuda a rever e corrigir erros de script, preparar a base de dados, copiar dados com um trabalho de cópia e finalizar a cópia.

O progresso da migração não é replicado para outra região, e uma implementação interrompida não pode ser retomada. Estas falhas não afetam a base de dados do SQL Server de origem, por isso pode correr novamente o assistente de migração. Se a região original não estiver disponível, siga primeiro o plano geral de recuperação neste artigo para criar capacidade C2 e espaço de trabalho W2 na região emparelhada, e depois execute a migração no W2. Se a região original recuperar, podes tentar a migração novamente no espaço de trabalho original.

Uma perturbação regional pode causar o fracasso de uma migração de três formas:

• A base de dados alvo não é criada

  Se o Fabric não conseguir criar a base de dados alvo, o assistente de migração mostra um erro e a migração não começa. Selecione Iniciar migração para tentar novamente, ou tente novamente mais tarde.

  O assistente tenta remover uma base de dados incompleta, mas a limpeza pode falhar durante uma interrupção. Antes de tentar novamente, verifique se existe, no espaço de trabalho, uma base de dados com o nome de destino. Confirma se é a base de dados incompleta da tentativa falhada antes de a apagar.

• A implementação falha

  Se a implementação for interrompida, o monitor de migração deixa de reportar o progresso, abre a base de dados alvo e apresenta um diálogo indicando que a implementação falhou. Não podes retomar uma implementação falhada, e a base de dados criada pela tentativa permanece no espaço de trabalho.

  Para recuperar:

  1. Confirma que o Fabric está disponível e que tens o DACPAC usado para a migração original.
  2. Identifique a base de dados criada pela tentativa falhada. Apaga se não contiver nada que precises de guardar. Caso contrário, mantém-na e usa um nome diferente para a nova base de dados.
  3. Executa uma nova migração a partir do DACPAC de origem. A migração cria uma nova base de dados.

  Os dados são copiados por uma tarefa de cópia no Data Factory. Se sincronizou o trabalho de cópia com o Git antes da perturbação, consulte Trabalho de Cópia nas orientações do Data Factory. Caso contrário, crie um novo trabalho de cópia como parte da nova migração.

• O histórico de migração não carrega

  Se o Assistente de Migração não conseguir recuperar o histórico de migração, reporta que a informação de migração já não está disponível. O progresso guardado no navegador atual é preservado e a base de dados alvo não é afetada. Atualize a página para carregar novamente o histórico de migração.

OneLake

Esta secção orienta-o pelos procedimentos de recuperação das funcionalidades do OneLake. Para mais informações sobre recuperação de desastres para dados OneLake, consulte recuperação de desastres OneLake.

Políticas de gerenciamento do ciclo de vida

Se o Fabric ficar inacessível ou inoperacional numa região, pode ainda assim ler e atualizar a sua política de ciclo de vida OneLake durante o failover. Qualquer dado movido para a camada fria ou fria mantém-se nesse nível. Para aplicar a sua apólice existente ao novo espaço de trabalho de recuperação, siga estes passos:

1. Chama a política de exportação no teu espaço de trabalho original e guarda a política de ciclo de vida completa.
2. Invoque a Política de Importação na sua área de trabalho recuperada, com a sua política do ciclo de vida exportada no corpo do pedido.

Regras de instância de recurso

As regras de instância de recursos ajudam-no a controlar de forma segura o acesso aos dados no OneLake usando identidades de recursos Azure de confiança. Durante o failover regional, o sistema continua a aplicar as regras existentes de acesso de leitura. No entanto, não pode criar, atualizar ou eliminar regras da instância do recurso até que o espaço de trabalho volte a um estado de escrita.

Informações relacionadas

• Microsoft Fabric guia de recuperação de desastres