Restaurar um único locatário com um aplicativo SaaS de banco de dados por locatário
Aplica-se a:Banco de Dados SQL do Azure
O modelo de banco de dados por locatário facilita a restauração de um único locatário para um point-in-time anterior sem afetar outros locatários.
Neste tutorial, você aprenderá dois padrões de recuperação de dados:
- Restaure um banco de dados em um banco de dados paralelo (lado a lado).
- Restaure um banco de dados no local, substituindo o banco de dados existente.
Padrão | Description |
---|---|
Restaurar em um banco de dados paralelo | Esse padrão pode ser usado para tarefas como revisão, auditoria e conformidade para permitir que um locatário inspecione seus dados de um ponto anterior. O banco de dados atual do locatário permanece online e inalterado. |
Restaurar no local | Esse padrão geralmente é usado para recuperar um locatário para um ponto anterior, depois que um locatário exclui ou corrompe dados acidentalmente. O banco de dados original é retirado do ar e substituído pelo banco de dados restaurado. |
Para concluir este tutorial, devem ser cumpridos os seguintes pré-requisitos:
- O aplicativo Wingtip SaaS é implantado. Para implantar em menos de cinco minutos, consulte Implantar e explorar o aplicativo SaaS Wingtip.
- O Azure PowerShell está instalado. Para obter detalhes, consulte Introdução ao Azure PowerShell.
Introdução aos padrões de restauração do locatário SaaS
Há dois padrões simples para restaurar os dados de um locatário individual. Como os bancos de dados de locatários são isolados uns dos outros, a restauração de um locatário não tem impacto nos dados de nenhum outro locatário. O recurso de restauração point-in-time-return (PITR) do Banco de Dados SQL do Azure é usado em ambos os padrões. O PITR cria sempre uma nova base de dados.
Restaurar em paralelo: no primeiro padrão, um novo banco de dados paralelo é criado junto com o banco de dados atual do locatário. O locatário recebe acesso somente leitura ao banco de dados restaurado. Os dados restaurados podem ser revisados e potencialmente usados para substituir os valores de dados atuais. Cabe ao designer do aplicativo determinar como o locatário acessa o banco de dados restaurado e quais opções de recuperação são fornecidas. Simplesmente permitir que o locatário revise seus dados em um ponto anterior pode ser tudo o que é necessário em alguns cenários.
Restaurar no local: o segundo padrão é útil se os dados foram perdidos ou corrompidos e o locatário deseja reverter para um ponto anterior. O locatário é retirado do ar enquanto o banco de dados é restaurado. O banco de dados original é excluído e o banco de dados restaurado é renomeado. A cadeia de backup do banco de dados original permanece acessível após a exclusão, para que você possa restaurar o banco de dados para um ponto anterior no tempo, se necessário.
Se o banco de dados usar replicação geográfica ativa e restauração em paralelo, recomendamos que você copie todos os dados necessários da cópia restaurada para o banco de dados original. Se você substituir o banco de dados original pelo banco de dados restaurado, precisará reconfigurar e ressincronizar a replicação geográfica.
Obtenha os scripts de aplicativo de banco de dados SaaS por locatário do Wingtip Tickets
Os scripts Wingtip Tickets SaaS Multitenant Database e o código-fonte do aplicativo estão disponíveis no repositório GitHub WingtipTicketsSaaS-DbPerTenant . Para conhecer as etapas para baixar e desbloquear os scripts SaaS do Wingtip Tickets, consulte as orientações gerais.
Antes de começar
Quando um banco de dados é criado, pode levar de 10 a 15 minutos até que o primeiro backup completo esteja disponível para restauração. Se você acabou de instalar o aplicativo, talvez seja necessário aguardar alguns minutos antes de tentar esse cenário.
Simular a exclusão acidental de dados de um locatário
Para demonstrar esses cenários de recuperação, primeiro exclua "acidentalmente" um evento em um dos bancos de dados do locatário.
Abra a aplicação Eventos para rever os eventos atuais
Abra o Hub de Eventos (
http://events.wtp.<user>.trafficmanager.net
) e selecione Contoso Concert Hall.Desloque-se para a lista de eventos e anote o último evento da lista.
"Acidentalmente" excluir o último evento
No ISE do PowerShell, abra
...\Learning Modules\Business Continuity and Disaster Recovery\RestoreTenant\Demo-RestoreTenant.ps1
e defina o seguinte valor:- = $DemoScenario 1, Excluir último evento (sem venda de ingressos).
Pressione F5 para executar o script e excluir o último evento. É apresentada a seguinte mensagem de confirmação:
Deleting last unsold event from Contoso Concert Hall ... Deleted event 'Seriously Strauss' from Contoso Concert Hall venue.
A página de eventos da Contoso é aberta. Desloque-se para baixo e verifique se o evento desapareceu. Se o evento ainda estiver na lista, selecione Atualizar e verifique se ele desapareceu.
Restaurar um banco de dados de locatário em paralelo com o banco de dados de produção
Este exercício restaura o banco de dados da Sala de Concertos da Contoso para um ponto no tempo anterior à exclusão do evento. Este cenário pressupõe que você deseja revisar os dados excluídos em um banco de dados paralelo.
O script Restore-TenantInParallel.ps1 cria um banco de dados de locatário paralelo chamado ContosoConcertHall_old, com uma entrada de catálogo paralela. Esse padrão de restauração é mais adequado para a recuperação de uma pequena perda de dados. Você também pode usar esse padrão se precisar revisar os dados para fins de conformidade ou auditoria. É a abordagem recomendada quando você usa a replicação geográfica ativa.
- Conclua a seção Simular uma exclusão acidental de dados de um locatário.
- No ISE do PowerShell, abra
...\Learning Modules\Business Continuity and Disaster Recovery\RestoreTenant\Demo-RestoreTenant.ps1
o . - Defina $DemoScenario = 2, Restaurar locatário em paralelo.
- Para executar o script, pressione F5.
O script restaura o banco de dados do locatário para um ponto no tempo antes de você excluir o evento. O banco de dados é restaurado para um novo banco de dados chamado ContosoConcertHall_old
. Os metadados de catálogo que existem neste banco de dados restaurado são excluídos e, em seguida, o banco de dados é adicionado ao catálogo usando uma chave construída a partir do ContosoConcertHall_old
nome.
O script de demonstração abre a página de eventos para esse novo banco de dados de locatários em seu navegador. Observe no URL http://events.wingtip-dpt.<user>.trafficmanager.net/contosoconcerthall_old
que esta página mostra dados do banco de dados restaurado onde _old é adicionado ao nome.
Role os eventos listados no navegador para confirmar que o evento excluído na seção anterior foi restaurado.
É improvável que expor o locatário restaurado como um locatário adicional, com seu próprio aplicativo Eventos, seja como você fornece a um locatário acesso aos dados restaurados. Serve para ilustrar o padrão de restauração. Normalmente, você concede acesso somente leitura aos dados antigos e mantém o banco de dados restaurado por um período definido. No exemplo, você pode excluir a entrada de locatário restaurada depois de terminar executando o cenário Remover locatário restaurado.
- Defina $DemoScenario = 4, Remover inquilino restaurado.
- Para executar o script, pressione F5.
- A entrada ContosoConcertHall_old agora é excluída do catálogo. Feche a página de eventos para este locatário em seu navegador.
Restaurar um locatário no local, substituindo o banco de dados de locatário existente
Este exercício restaura o locatário da Sala de Concertos da Contoso até um ponto anterior à exclusão do evento. O Restore-TenantInPlace
script restaura um banco de dados de locatário para um novo banco de dados e exclui o original. Esse padrão de restauração é mais adequado para a recuperação de corrupção de dados grave, e o locatário pode ter que acomodar uma perda de dados significativa.
- No ISE do PowerShell, abra o
Demo-RestoreTenant.ps1
arquivo. - Conjunto
$DemoScenario
= 5, Restaurar inquilino no local. - Para executar o script, pressione F5.
O script restaura o banco de dados do locatário até um ponto antes do evento ser excluído. Primeiro, ele tira o locatário da Sala de Concertos da Contoso do ar para evitar novas atualizações. Em seguida, um banco de dados paralelo é criado restaurando a partir do ponto de restauração. O banco de dados restaurado é nomeado com um carimbo de data/hora para garantir que o nome do banco de dados não entre em conflito com o nome do banco de dados do locatário existente. Em seguida, o banco de dados de locatário antigo é excluído e o banco de dados restaurado é renomeado para o nome do banco de dados original. Finalmente, a Sala de Concertos da Contoso é colocada online para permitir que o aplicativo acesse o banco de dados restaurado.
Você restaurou com êxito o banco de dados para um ponto no tempo antes do evento foi excluído. Quando a página Eventos abrir, confirme se o último evento foi restaurado.
Depois de restaurar o banco de dados, leva mais 10 a 15 minutos até que o primeiro backup completo esteja disponível para restauração novamente.
Nota
A restauração de bancos de dados multilocatários para um único locatário não é possível.
Próximos passos
Neste tutorial, ficou a saber como:
- Restaure um banco de dados em um banco de dados paralelo (lado a lado).
- Restaure um banco de dados no local.
- Experimente o tutorial Gerenciar esquema de banco de dados de locatário.