Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
Este tópico é um tutorial sobre como configurar o Backup Gerenciado do SQL Server para o Microsoft Azure para bancos de dados que participam de Grupos de Disponibilidade AlwaysOn.
Configurações do Grupo de Disponibilidade
Há suporte para Backup Gerenciado do SQL Server para o Microsoft Azure em bancos de dados de um grupo de disponibilidade, caso todas as réplicas estejam configuradas nas instalações locais, inteiramente no Azure, ou em uma implementação híbrida entre instalações locais e uma ou mais máquinas virtuais do Azure. No entanto, talvez seja necessário considerar o seguinte para uma ou mais implementações:
Frequência de Backup de Log: a frequência do backup de log depende tanto do tempo quanto do crescimento do log. Por exemplo, o backup de log é feito uma vez a cada 2 horas, a menos que o espaço de log usado no período de duas horas seja de 5 MB ou mais. Isso se aplica a todas as implementações, locais, na nuvem ou em um Híbrido.
Largura de banda de rede: isso se aplica a implementações em que as réplicas estão localizadas em locais físicos diferentes, como em uma nuvem híbrida ou em diferentes regiões do Azure em uma configuração somente na nuvem. A largura de banda de rede pode afetar a latência dos secundários e, se os secundários estiverem definidos como replicação síncrona, isso poderá causar o crescimento do log no primário. Se os secundários estiverem configurados para replicação síncrona, talvez não consigam manter o ritmo devido à latência da rede, o que pode resultar em perda de dados caso ocorra uma mudança para a réplica secundária.
Configurando o Backup Gerenciado do SQL Server para o Microsoft Azure para Bancos de Dados de Disponibilidade.
Permissões:
Requer associação na função de banco de dados db_backupoperator, com permissões ALTER ANY CREDENTIAL e
EXECUTEem sp_delete_backuphistory procedimento armazenado.Requer permissões SELECT na função smart_admin.fn_get_current_xevent_settings.
Requer permissões
EXECUTEno procedimento armazenado smart_admin.sp_get_backup_diagnostics . Além disso, ele requer permissõesVIEW SERVER STATE, pois ele chama internamente outros objetos do sistema que exigem essa permissão.Requer permissões
EXECUTEnos procedimentos armazenadossmart_admin.sp_set_instance_backupesmart_admin.sp_backup_master_switch.
Veja a seguir as etapas básicas para configurar um Grupo de Disponibilidade AlwaysOn com o Backup Gerenciado do SQL Server no Microsoft Azure. Um tutorial detalhado passo a passo é descrito posteriormente neste tópico.
Depois de criar o Grupo de Disponibilidade, configure a réplica de backup preferencial. Essa configuração para o Grupo de Disponibilidade também é usada pelo Backup Gerenciado do SQL Server no Microsoft Azure para determinar qual réplica usar para backup. Para obter instruções passo a passo sobre como configurar a preferência de backup, consulte Configurar Backup em Réplicas de Disponibilidade (SQL Server). Se você estiver criando um novo Grupo de Disponibilidade AlwaysOn, consulte Introdução aos Grupos de Disponibilidade AlwaysOn (SQL Server).
Configure o acesso de conexão somente leitura às réplicas secundárias. Para obter instruções passo a passo sobre como configurar o acesso somente leitura, consulte Configurar o acesso Read-Only em uma réplica de disponibilidade (SQL Server)
Especifique a cópia de segurança. A configuração de réplica preferida de backup é utilizada pelo recurso de Backup Gerenciado do SQL Server para Microsoft Azure, para determinar qual banco de dados usar para agendar backups. Para determinar se a réplica atual é a réplica de backup preferencial, use a função sys.fn_hadr_backup_is_preferred_replica (Transact-SQL).
Em cada réplica, execute a configuração do Backup Gerenciado do SQL Server para Microsoft Azure no banco de dados, usando o procedimento armazenado smart-admin.sp_set_db_backup.
Comportamento do Backup Gerenciado do SQL Server para Microsoft Azure após um failover: O backup gerenciado do SQL Server no Microsoft Azure continuará funcionando e manterá cópias de backup e capacidade de recuperação após um evento de failover. Nenhuma ação específica é necessária após um failover.
Considerações e requisitos:
Configurar o Backup Gerenciado do SQL Server no Microsoft Azure para bancos de dados que participam do Grupo de Disponibilidade AlwaysOn requer considerações e requisitos específicos. Veja a seguir uma lista de considerações e requisitos:
As configurações de Backup Gerenciado do SQL Server para o Microsoft Azure devem ser as mesmas para todos os bancos de dados em todos os nós do SQL Server que participam do mesmo Grupo de Disponibilidade. Você pode fazer isso definindo as mesmas configurações de Backup Gerenciado do SQL Server no Microsoft Azure para o servidor principal e todas as réplicas no nível de banco de dados, ou definindo as mesmas configurações padrão de Backup Gerenciado do SQL Server no Microsoft Azure em todos os nós participantes dos Grupos de Disponibilidade. É recomendável definir o Backup Gerenciado do SQL Server para o Microsoft Azure no banco de dados porque configurar o Backup Gerenciado do SQL Server para o Microsoft Azure no nível do banco de dados permite isolar as configurações dos bancos de dados e as alterações nas configurações padrão afetam todos os outros bancos de dados na instância.
Especifique a réplica de backup. A configuração de réplica de backup preferencial é usada pelo Backup Gerenciado do SQL Server no Microsoft Azure para agendar os backups. Para determinar se a réplica atual é a réplica de backup preferencial, use a função sys.fn_hadr_backup_is_preferred_replica (Transact-SQL).
Se a réplica secundária estiver configurada como a réplica preferencial, ela deverá ser configurada para ter acesso apenas para leitura. Não há suporte para grupos de disponibilidade que não têm acesso de conexão a bancos de dados secundários. Para obter mais informações, confira Configurar o acesso somente leitura em uma réplica de disponibilidade (SQL Server).
Se você estiver configurando o Backup Gerenciado do SQL Server para o Microsoft Azure após configurar o Grupo de Disponibilidade, o Backup Gerenciado do SQL Server para o Microsoft Azure tentará copiar quaisquer backups existentes e transferi-los para o contêiner de armazenamento. Se o Backup Gerenciado do SQL Server para o Microsoft Azure não conseguir localizar ou acessar backups existentes, ele agendará um backup completo do banco de dados. Isso é feito especificamente para otimizar as operações de backup para bancos de dados do Grupo de Disponibilidade.
Talvez você queira considerar desabilitar as configurações de nível de instância se estiver criando um novo banco de dados de disponibilidade e não pretende aplicar as configurações de nível de instância ao banco de dados
Ao usar a criptografia, use o mesmo certificado em todas as réplicas. Isso facilita operações de backup contínuas e ininterruptas no caso de um failover ou restaurações em uma réplica diferente.
Habilitar e configurar o Backup Gerenciado do SQL Server no Microsoft Azure para um Banco de Dados de Disponibilidade
Este tutorial descreve as etapas para habilitar e configurar o Backup Gerenciado do SQL Server no Microsoft Azure para um banco de dados (AGTestDB) nos computadores Node1 e Node2, seguidas por etapas para habilitar o monitoramento do Backup Gerenciado do SQL Server para o status de integridade do Microsoft Azure.
Criar uma conta de armazenamento do Azure: Os backups são armazenados no serviço de Armazenamento de Blobs do Azure. Primeiro, você deve criar uma conta de armazenamento do Azure, caso ainda não tenha uma. Para obter mais informações, consulte Criando uma conta de armazenamento do Azure. Anote o nome da conta de armazenamento, as chaves de acesso e a URL da conta de armazenamento. O nome da conta de armazenamento e as informações da chave de acesso são usados para criar uma Credencial do SQL. A Credencial do SQL é usada pelo Backup Gerenciado do SQL Server no Microsoft Azure durante operações de backup para autenticar na conta de armazenamento.
Criar uma credencial do SQL: Crie uma Credencial do SQL usando o nome da conta de armazenamento como a Identidade e a chave de acesso de armazenamento como a senha.
Verifique se o serviço SQL Server Agent está iniciado e em execução: Inicie o SQL Server Agent se ele não estiver em execução no momento. O Backup Gerenciado do SQL Server no Microsoft Azure requer que o SQL Server Agent esteja em execução na instância para executar operações de backup. Talvez você queira definir o SQL Agent para ser executado automaticamente para garantir que as operações de backup possam ocorrer regularmente.
Determine o período de retenção: Determine o período de retenção desejado para os arquivos de backup. O período de retenção é especificado em dias e pode variar de 1 a 30. O período de retenção determina o período de recuperação do banco de dados.
Crie um certificado ou chave assimétrica para usar para criptografia durante o backup: Crie o certificado no primeiro nó Node1 e exporte-o para um arquivo usando BACKUP CERTIFICATE (Transact-SQL).. No Nó 2, crie um certificado usando o arquivo exportado do Nó 1. Para obter mais informações sobre como criar um certificado de um arquivo, consulte o exemplo em CREATE CERTIFICATE (Transact-SQL).
Habilite e configure o Backup Gerenciado do SQL Server no Microsoft Azure para AGTestDB no Node1: Inicie o SQL Server Management Studio e conecte-se à instância no Node1 em que o banco de dados de disponibilidade está instalado. Na janela de consulta, execute a seguinte instrução depois de modificar os valores para o nome do banco de dados, a URL de armazenamento, a Credencial do SQL e o período de retenção de acordo com seus requisitos:
Use msdb; GO EXEC smart_admin.sp_set_db_backup @database_name='AGTestDB' ,@retention_days=30 ,@credential_name='MyCredential' ,@encryption_algorithm ='AES_128' ,@encryptor_type= 'Certificate' ,@encryptor_name='MyBackupCert' ,@enable_backup=1; GOPara obter mais informações sobre como criar um certificado para criptografia, consulte a etapa Criar um Certificado de Backup em Criar um Backup Criptografado.
Habilite e configure o Backup Gerenciado do SQL Server no Microsoft Azure para AGTestDB no Node2: Inicie o SQL Server Management Studio e conecte-se à instância no Node2 em que o banco de dados de disponibilidade está instalado. Na janela de consulta, execute a seguinte instrução depois de modificar os valores para o nome do banco de dados, a URL de armazenamento, a Credencial do SQL e o período de retenção de acordo com seus requisitos:
Use msdb; GO EXEC smart_admin.sp_set_db_backup @database_name='AGTestDB' ,@retention_days=30 ,@credential_name='MyCredential' ,@encryption_algorithm ='AES_128' ,@encryptor_type= 'Certificate' ,@encryptor_name='MyBackupCert' ,@enable_backup=1; GOO Backup Gerenciado do SQL Server para o Microsoft Azure agora está habilitado no banco de dados especificado. Pode levar até 15 minutos para que as operações de backup no banco de dados comecem a ser executadas. O backup ocorrerá na réplica de backup preferencial.
Examine a configuração padrão do evento estendido: Examine a configuração de Evento Estendido executando a seguinte instrução transact-SQL na réplica da qual o Backup Gerenciado do SQL Server para o Microsoft Azure está usando para agendar os backups. Geralmente, essa é a configuração de réplica de backup preferencial para o Grupo de Disponibilidade ao qual o banco de dados pertence.
SELECT * FROM smart_admin.fn_get_current_xevent_settings();Você deve ver que os eventos de canal Admin, Operacional e Analítico estão habilitados por padrão e não podem ser desabilitados. Isso deve ser suficiente para monitorar os eventos que exigem intervenção manual. Você pode habilitar os eventos de depuração, mas esses canais incluem eventos de informação e depuração que o Backup Gerenciado do SQL Server para o Microsoft Azure utiliza para detectar e resolver problemas. Para obter mais informações, consulte Monitorar o Backup Gerenciado do SQL Server no Azure.
Habilitar e configurar a notificação para o status de integridade: O Backup Gerenciado do SQL Server para o Microsoft Azure tem um procedimento armazenado que cria um trabalho de agente para enviar notificações por email de erros ou avisos que podem exigir atenção. Para receber essas notificações, você deve habilitar a execução do procedimento armazenado que cria um trabalho do SQL Server Agent. As etapas a seguir descrevem o processo para habilitar e configurar notificações por email:
Configure o Database Mail se ele ainda não estiver habilitado na instância. Para obter mais informações, consulte Configurar o Database Mail.
Configure a Notificação do SQL Server Agent para usar o Database Mail. Para obter mais informações, consulte Configurar o SQL Server Agent Mail para usar o Database Mail.
Habilite as notificações por email para receber erros de backup e avisos: Na janela de consulta, execute as seguintes instruções de Transact-SQL:
EXEC msdb.smart_admin.sp_set_parameter @parameter_name = 'SSMBackup2WANotificationEmailIds', @parameter_value = '<email>'Para obter mais informações e um script de exemplo completo, consulte Monitorar o Backup Gerenciado do SQL Server no Azure.
Exibir arquivos de backup na Conta de Armazenamento do Azure: Conecte-se à conta de armazenamento do SQL Server Management Studio ou do Portal de Gerenciamento do Azure. Você verá um contêiner para a instância do SQL Server que hospeda o banco de dados configurado para usar o Backup Gerenciado do SQL Server no Microsoft Azure. Você também pode ver um backup do banco de dados e um backup de log dentro de 15 minutos após habilitar o Backup Gerenciado do SQL Server para o banco de dados no Microsoft Azure.
Monitore o Status de Saúde: Você pode monitorar através das notificações por e-mail configuradas anteriormente ou monitorar ativamente os eventos registrados. Veja a seguir alguns exemplos de Declarações Transact-SQL usadas para exibir os eventos:
-- view all admin events Use msdb; Go DECLARE @startofweek datetime DECLARE @endofweek datetime SET @startofweek = DATEADD(Day, 1-DATEPART(WEEKDAY, CURRENT_TIMESTAMP), CURRENT_TIMESTAMP) SET @endofweek = DATEADD(Day, 7-DATEPART(WEEKDAY, CURRENT_TIMESTAMP), CURRENT_TIMESTAMP) DECLARE @eventresult TABLE (event_type nvarchar(512), event varchar (512), timestamp datetime ) INSERT INTO @eventresult EXEC smart_admin.sp_get_backup_diagnostics @begin_time = @startofweek, @end_time = @endofweek SELECT * from @eventresult WHERE event_type LIKE '%admin%'-- to enable debug events Use msdb; Go EXEC smart_admin.sp_set_parameter 'FileRetentionDebugXevent', 'True'-- View all events in the current week Use msdb; Go DECLARE @startofweek datetime DECLARE @endofweek datetime SET @startofweek = DATEADD(Day, 1-DATEPART(WEEKDAY, CURRENT_TIMESTAMP), CURRENT_TIMESTAMP) SET @endofweek = DATEADD(Day, 7-DATEPART(WEEKDAY, CURRENT_TIMESTAMP), CURRENT_TIMESTAMP) EXEC smart_admin.sp_get_backup_diagnostics @begin_time = @startofweek, @end_time = @endofweek;
As etapas descritas nesta seção são especificamente para configurar o Backup Gerenciado do SQL Server para o Microsoft Azure pela primeira vez no banco de dados. Você pode modificar as configurações existentes usando o mesmo procedimento armazenado do sistema smart_admin.sp_set_db_backup e fornecer os novos valores. Para obter mais informações, consulte Backup Gerenciado do SQL Server no Azure – Configurações de Retenção e Armazenamento.
Considerações ao remover um banco de dados da configuração do grupo de disponibilidade AlwaysOn
Se um banco de dados for removido da configuração do Grupo de Disponibilidade AlwaysOn e agora for um banco de dados autônomo, recomendamos fazer backup usando smart_admin.sp_backup_on_demand (Transact-SQL). Quando você cria um backup de banco de dados dessa forma, ele estabelece uma nova cadeia de backup e o arquivo será colocado no contêiner específico da instância em vez do contêiner de disponibilidade em que os backups foram armazenados quando o banco de dados fazia parte do Grupo de Disponibilidade.
Aviso
A capacidade de recuperação do banco de dados nesse cenário de backups anteriores à alteração no status do Grupo de Disponibilidade não é garantida.