Compartilhar via

Backup e restauração no Banco de Dados do Azure para MySQL

  • Artigo

APLICA-SE A: Banco de Dados do Azure para MySQL – Servidor Único

Importante

O servidor único do Banco de Dados do Azure para MySQL está no caminho da desativação. É altamente recomendável que você atualize para o servidor flexível do Banco de Dados do Azure para MySQL. Para obter mais informações sobre a migração para o servidor flexível do Banco de Dados do Azure para MySQL, confira O que está acontecendo com o Servidor Único do Banco de Dados do Azure para MySQL?

O Banco de Dados do Azure para MySQL cria backups de servidor automaticamente e os armazena no armazenamento com redundância geográfica ou local configurado pelo usuário. Os backups podem ser usados para restaurar o servidor pontualmente. Os recursos de backup e restauração são uma parte essencial de qualquer estratégia de continuidade dos negócios, pois eles protegem seus dados contra exclusão ou corrupção acidentais.

Backups

O Banco de Dados do Azure para MySQL faz backups dos arquivos de dados e do log de transações. Esses backups permitem que você restaure um servidor pontualmente dentro de seu período de retenção de backup configurado. O período de retenção de backup padrão é de sete dias. É possível opcionalmente, configurá-lo para até 35 dias. Todos os backups são criptografados usando a criptografia AES de 256 bits.

Esses arquivos de backup não são expostos pelo usuário e não podem ser exportados. Os backups podem ser usados somente para operações de restauração no Banco de Dados do Azure para MySQL. Você pode utilizar mysqldump para copiar um banco de dados.

O tipo e a frequência de backup dependem do armazenamento de back-end para os servidores.

Tipo e frequência de backup

Servidores de armazenamento básico

O armazenamento básico é o armazenamento de back-end com suporte a servidores de Camada básica. Os backups em servidores de Armazenamento básico são baseados em instantâneos. Um instantâneo de banco de dados completo é executado diariamente. Não há backups diferenciais executados para servidores de Armazenamento básico e todos os backups de instantâneo são apenas backups de banco de dados completos.

Os backups de log de transações ocorrem a cada cinco minutos.

Servidores com armazenamento para uso geral v1 (compatível com um armazenamento de até 4 TB)

O armazenamento de uso geral é o armazenamento de back-end com suporte ao uso geral e ao servidor de camada Otimizado para memória. Para servidores com armazenamento de uso geral de até 4 TB, os backups completos ocorrem uma vez por semana. Os backups diferenciais ocorrem duas vezes ao dia. Os backups de log de transações ocorrem a cada cinco minutos. Os backups no armazenamento de uso geral até 4 TB não são baseados em instantâneos e consomem largura de banda de E/S no momento do backup. Para bancos de dados grandes (> 1 TB) no armazenamento de 4 TB, recomendamos que você considere

  • Provisionar mais IOPs para E/S de backup ou
  • Como alternativa, migrar para o armazenamento de uso geral que dá suporte a até 16 TB de armazenamento se a infraestrutura de armazenamento subjacente estiver disponível em suas regiões do Azurepreferenciais. Não há nenhum custo adicional para o armazenamento de uso geral que dá suporte a até 16 TB de armazenamento. Para obter assistência com a migração para o armazenamento de 16 TB, abra um tíquete de suporte no portal do Azure.

Servidores com armazenamento para uso geral v2 (compatível com um armazenamento de até 16 TB)

Em um subconjunto de regiões do Azure, todos os servidores recentemente provisionados podem dar suporte ao armazenamento de uso geral de até 16 TB. Em outras palavras, o armazenamento de até 16 TB é o armazenamento padrão de uso geral para todas as regiões em que há suporte. Os backups nos servidores de armazenamento de 16-TB são baseados em instantâneos. O primeiro backup de instantâneo será agendado imediatamente após a criação de um servidor. Os backups de instantâneos são executados uma vez todos os dias. Os backups de log de transações ocorrem a cada cinco minutos.

Para obter mais informações sobre o armazenamento Básico e de Uso Geral, confira a documentação sobre o armazenamento.

Retenção de backup

Os backups são mantidos no servidor com base na configuração do período de retenção de backup. É possível definir um período de retenção de 7 a 35 dias. O período de retenção padrão é de 7 dias. É possível definir o período de retenção durante a criação do servidor ou posteriormente, atualizando a configuração de backup pelo portal do Azure ou pela CLI do Azure.

O período de retenção de backup determina até quando a restauração de pontos anteriores pode ser feita, já que ele se baseia em backups disponíveis. O período de retenção de backup também pode ser tratado como uma janela de recuperação sob uma perspectiva de restauração. Todos os backups necessários para executar uma restauração pontual dentro do período de retenção de backup são mantidos no armazenamento de backup. Por exemplo, se o período de retenção de backup for definido como sete dias, a janela de recuperação será considerada nos últimos sete dias. Nesse cenário, são mantidos todos os backups necessários para restaurar o servidor nos últimos sete dias. Com uma janela de retenção de backup de sete dias:

  • Os servidores com armazenamento para uso geral v1 (compatíveis com um armazenamento de até 4 TB) manterão até dois backups completos de bancos de dados, todos os backups diferenciais e backups de log de transações executados do primeiro backup completo de banco de dados em diante.
  • Os servidores com armazenamento para uso geral v2 (compatíveis com um armazenamento de até 16 TB) manterão os instantâneos completos do banco de dados e os backups de log de transações dos últimos 8 dias.

Retenção de longo prazo

A retenção de longo prazo de backups acima de 35 dias no momento ainda não tem suporte nativo pelo serviço. Está disponível uma opção de usar mysqldump para fazer backups e armazená-los para retenção de longo prazo. Nossa equipe de suporte técnico publicou em um blog um artigo passo a passo que compartilha como é possível fazer isso.

Opções de redundância de backup

O Banco de Dados do Azure para MySQL fornece a flexibilidade de escolher entre o armazenamento de backup com redundância local ou com redundância geográfica nas camadas de Uso Geral e Otimizado para Memória. Quando os backups são armazenados no armazenamento de backup com redundância geográfica, eles não são somente armazenados dentro da região em que o servidor está hospedado, mas também replicados em um datacenter emparelhado. A redundância geográfica fornece maior proteção e a capacidade de restaurar o servidor em uma região diferente em caso de desastre. A camada Básica oferece apenas o armazenamento de backup de redundância local.

Observação

Nas regiões Índia Central, França Central, Norte dos EAU e Norte da África do Sul, o armazenamento para uso geral v2 está em Versão Prévia Pública. Caso crie um servidor de origem no armazenamento para uso geral v2 (compatível com um armazenamento de até 16 TB) nas regiões mencionadas acima, habilitar o Backup com Redundância Geográfica não será compatível.

Mudar o armazenamento de backup com redundância local para redundância geográfica

A configuração do armazenamento com redundância local ou geográfica para backup só é permitida durante a criação do servidor. Quando o servidor é provisionado, você não pode alterar a opção de redundância do armazenamento de backup. Para mudar o armazenamento de backup com armazenamento com redundância local para o armazenamento com redundância geográfica, criar um novo servidor e migrar os dados usando dump e restore é a única opção com suporte.

Custo do armazenamento de backup

O Banco de Dados do Azure para MySQL fornece até 100% de seu armazenamento de servidor configurado como armazenamento de backup sem custo adicional. Qualquer armazenamento de backup adicional usado será cobrado em GB por mês. Por exemplo, caso tenha provisionado um servidor com 250 GB de armazenamento, terá 250 GB de armazenamento adicional disponíveis para backups de servidor, sem nenhum custo adicional. O armazenamento consumido para backups com mais de 250 GB é cobrado de acordo com o modelo de preços.

É possível a métrica Armazenamento de backup usado no Azure Monitor disponível no portal do Azure para monitorar o armazenamento de backup consumido por um servidor. A métrica Armazenamento de backup usado representa a soma do armazenamento consumido por todos os backups de banco de dados, backups diferenciais e backups de log retidos com base no período de retenção de backup definido para o servidor. A frequência dos backups é gerenciada pelo serviço e foi explicada anteriormente. Uma atividade transacional intensa no servidor pode fazer com que o uso do armazenamento de backup aumente, independentemente do tamanho total do banco de dados. Para o armazenamento com redundância geográfica, o uso de armazenamento de backup é o dobro do armazenamento com redundância local.

O principal meio de controlar o custo de armazenamento de backup é definir o período de retenção de backup apropriado e escolher as opções de redundância de backup corretas para atender aos objetivos de recuperação que você deseja. É possível definir um período de retenção no intervalo de 7 a 35 dias. Para servidores de uso geral e otimizados de memória existe a opção de armazenamento com redundância geográfica para backups.

Restaurar

No Banco de Dados do Azure para MySQL, executar uma restauração cria um novo servidor a partir dos backups do servidor original e restaura todos os bancos de dados contidos nele. Atualmente, não há suporte para a restauração se o servidor original estiver no estado parado.

Há dois tipos de restauração disponíveis:

  • A restauração pontual está disponível em qualquer opção de redundância de backup e cria um novo servidor na mesma região do servidor original por meio da combinação de backups completos e de log de transações.
  • A restauração geográfica está disponível somente se o servidor foi configurado para armazenamento com redundância geográfica e ela permite restaurar o servidor em uma região diferente utilizando o backup mais recente.

O tempo estimado para a recuperação do servidor depende de vários fatores:

  • O Qual é o tamanho dos bancos de dados
  • O número de logs de transações envolvidos
  • A quantidade de atividade que precisa ser repetida para recuperar até o ponto de restauração
  • A largura de banda de rede se a restauração for para uma região diferente
  • O número de solicitações de restauração simultâneas sendo processadas na região de destino
  • A presença de chave primária nas tabelas no banco de dados. Para uma recuperação mais rápida, considere adicionar a chave primária a todas as tabelas do banco de dados. Para verificar se as tabelas têm a chave primária, é possível usar a consulta a seguir:
select tab.table_schema as database_name, tab.table_name from information_schema.tables tab left join information_schema.table_constraints tco on tab.table_schema = tco.table_schema and tab.table_name = tco.table_name and tco.constraint_type = 'PRIMARY KEY' where tco.constraint_type is null and tab.table_schema not in('mysql', 'information_schema', 'performance_schema', 'sys') and tab.table_type = 'BASE TABLE' order by tab.table_schema, tab.table_name;

Para um banco de dados muito grande ou muito ativo, a restauração pode levar várias horas. Quando há uma interrupção prolongada em uma região, é possível que um número alto de solicitações de restauração geográfica seja iniciado para recuperação de desastre. Quando houver muitas solicitações, o tempo de recuperação dos bancos de dados individuais poderá aumentar. A maioria das restaurações de banco de dados é concluída em menos de 12 horas.

Importante

Os servidores excluídos podem ser restaurados somente dentro de cinco dias da exclusão, após esse período os backups são excluídos. O backup do banco de dados pode ser acessado e restaurado somente da assinatura do Azure que hospeda o servidor. Para restaurar um servidor descartado, consulte as etapas documentadas. Para proteger recursos do servidor, após a implantação, da exclusão acidental ou de alterações inesperadas, os administradores podem usar bloqueios de gerenciamento.

Restauração em um momento determinado

Independentemente de sua opção de redundância de backup, você pode executar uma restauração para qualquer ponto anterior dentro de seu período de retenção de backup. Um novo servidor é criado na mesma região do Azure do servidor original. Ele é criado com a configuração do servidor original para o tipo de preço, a geração de computação, o número de núcleos virtuais, o tamanho do armazenamento, o período de retenção de backup e a opção de redundância de backup.

Observação

Há dois parâmetros de servidor que são redefinidos para os valores padrão (e não são copiados do servidor primário) após a operação de restauração:

  • time_zone ꟷ defina esse valor para PADRÃO doSISTEMA
  • event_scheduler ꟷ o event_scheduler está definido como DESATIVADO no servidor restaurado

Será necessário definir esses parâmetros de servidor reconfigurando o parâmetro de servidor

A Restauração pontual é útil em vários cenários. Por exemplo, quando um usuário exclui dados acidentalmente, descarta uma tabela ou um banco de dados importante, ou se um aplicativo acidentalmente substitui dados bons por dados inválidos devido a um defeito no aplicativo.

Talvez seja necessário aguardar a execução do próximo backup de log de transações antes de poder restaurar para um ponto anterior nos últimos cinco minutos.

Restauração geográfica

É possível restaurar um servidor para outra região do Azure onde o serviço está disponível caso você tenha configurado o servidor para backups com redundância geográfica.

  • Os servidores com armazenamento para uso geral v1 (compatíveis com um armazenamento de até 4 TB) podem ser restaurados para a região emparelhada geograficamente ou para outras regiões do Azure compatíveis com Banco de Dados do Azure para MySQL - Serviço de Servidor Único.
  • Os servidores com armazenamento para uso geral v2 (compatíveis com um armazenamento de até 16 TB) podem ser restaurados somente em regiões do Azure compatíveis com a infraestrutura de servidores com armazenamento para uso geral v2. Examine os tipos de preço do BD do Azure para MySQL para a lista de regiões com suporte.

A restauração geográfica é a opção de recuperação padrão quando o servidor não está disponível devido a um incidente na região em que ele está hospedado. Se um incidente de grande escala em uma região resultar na indisponibilidade do seu aplicativo de banco de dados, você poderá restaurar um servidor do backup com redundância geográfica para um servidor em qualquer outra região. A restauração geográfica utiliza o backup mais recente do servidor. Há um atraso entre quando um backup é feito e quando ele é replicado em uma região diferente. Esse atraso pode ser de até uma hora, então, em caso de desastre pode haver perda de dados de até uma hora.

Importante

Se uma restauração geográfica for executada para um servidor recém-criado, a sincronização de backup inicial, dependendo do tamanho dos dados, poderá levar mais de 24 horas, pois o tempo de cópia inicial do backup do instantâneo completo é muito maior. Os backups de instantâneo subsequentes são cópias incrementais e, portanto, as restaurações são mais rápidas após 24 horas da criação do servidor. Caso esteja avaliando restaurações geográficas para definir o RTO, a recomendação é aguardar e avaliar a restauração geográfica somente após 24 horas de criação do servidor para obter estimativas melhores.

Durante a restauração geográfica, as configurações de servidor que podem ser alteradas incluem as opções de geração de computação, vCore, período de retenção de backup e redundância de backup. Não há suporte para a alteração do tipo de preço (Básico, Uso Geral ou Otimizado para Memória) ou do tamanho de armazenamento durante a restauração geográfica.

O tempo estimado de recuperação dependerá de vários fatores, incluindo os tamanhos dos bancos de dados, o tamanho do log de transações, a largura de banda de rede e o número total de bancos de dados de recuperação na mesma região e ao mesmo tempo. Normalmente, o tempo de recuperação é menor do que 12 horas.

Executar tarefas de pós-restauração

Após uma restauração de um dos mecanismos de recuperação, você deve executar as seguintes tarefas para colocar os usuários e os aplicativos novamente em execução:

  • Se o novo servidor é usado para substituir o servidor original, redirecione clientes e aplicativos de cliente para o novo servidor
  • Verifique se as regras de VNet adequadas estão em vigor para que os usuários se conectem. Essas regras não são copiadas do servidor original.
  • Verifique se as permissões e os logons adequados no nível do banco de dados estão em vigor
  • Configurar os alertas, conforme apropriado

Próximas etapas