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 de desativação. É altamente recomendável que você atualize para o Banco de Dados do Azure para o servidor flexível MySQL. Para obter mais informações sobre como migrar para o Banco de Dados do Azure para servidor flexível MySQL, consulte O que está acontecendo com o Banco de Dados do Azure para Servidor Único MySQL?

A Base de Dados do Azure para MySQL cria automaticamente cópias de segurança do servidor e guarda-as no armazenamento georredundante ou localmente redundante configurado pelo utilizador. As cópias de segurança podem ser utilizadas para restaurar o servidor para um ponto no tempo. A cópia de segurança e o restauro são uma parte essencial de qualquer estratégia de continuidade empresarial, uma vez que protegem os seus dados contra danos e a eliminação acidentais.

Cópias de Segurança

A Base de Dados do Azure para MySQL tira cópias de segurança dos ficheiros de dados e do registo de transações. Esses backups permitem que você restaure um servidor para qualquer point-in-time dentro do período de retenção de backup configurado. O período de retenção de backup padrão é de sete dias. Opcionalmente, você pode configurá-lo até 35 dias. Todas as cópias de segurança são encriptadas através da encriptação AES de 256 bits.

Estes ficheiros de cópia de segurança não são expostos pelo utilizador e não podem ser exportados. Esses backups só podem ser usados para operações de restauração no Banco de Dados do Azure para MySQL. Você pode usar mysqldump para copiar um banco de dados.

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

Tipo e frequência de backup

Servidores de armazenamento básicos

O armazenamento Básico é o armazenamento de back-end que suporta servidores de camada Básicos. Os backups em servidores de armazenamento básicos são baseados em snapshot. Um instantâneo completo do banco de dados é executado diariamente. Não há backups diferenciais executados para servidores de armazenamento básicos e todos os backups de snapshot são apenas backups completos de banco de dados.

As cópias de segurança de registo de transações ocorrem a cada cinco minutos.

Servidores v1 de armazenamento de uso geral (suporta armazenamento de até 4 TB)

O armazenamento de uso geral é o armazenamento de back-end que suporta o servidor de camadas de uso geral e memória otimizada. Para servidores com armazenamento de uso geral de até 4 TB, backups completos ocorrem uma vez por semana. Os backups diferenciais ocorrem duas vezes por dia. As cópias de segurança de registo de transações ocorrem a cada cinco minutos. Os backups em armazenamento de uso geral de até 4 TB não são baseados em snapshot e consomem largura de banda de E/S no momento do backup. Para bancos de dados grandes (> 1 TB) em armazenamento de 4 TB, recomendamos que você considere

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

Servidores v2 de armazenamento de uso geral (suporta armazenamento de até 16 TB)

Em um subconjunto de regiões do Azure, todos os servidores recém-provisionados podem oferecer suporte a armazenamento de uso geral de até 16 TB de armazenamento. Em outras palavras, o armazenamento de até 16 TB é o armazenamento padrão de uso geral para todas as regiões onde é suportado. Os backups nesses servidores de armazenamento de 16 TB são baseados em snapshot. A primeira cópia de segurança de instantâneos é agendada imediatamente após a criação do servidor. As cópias de segurança de instantâneos são tiradas uma vez por dia. As cópias de segurança de registo de transações ocorrem a cada cinco minutos.

Para obter mais informações sobre armazenamento básico e de uso geral, consulte a documentação de armazenamento.

Retenção da cópia de segurança

Os backups são retidos com base na configuração do período de retenção de backup no servidor. Você pode selecionar um período de retenção de 7 a 35 dias. O período de retenção padrão é de 7 dias. Você pode definir o período de retenção durante a criação do servidor ou posteriormente atualizando a configuração de backup usando o portal do Azure ou a CLI do Azure.

O período de retenção de backup controla até onde uma restauração point-in-time pode ser recuperada, uma vez que 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 de uma perspetiva de restauração. Todos os backups necessários para executar uma restauração point-in-time 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 estiver definido como 7 dias, a janela de recuperação será considerada como últimos 7 dias. Nesse cenário, todos os backups necessários para restaurar o servidor nos últimos 7 dias são mantidos. Com uma janela de retenção de backup de sete dias:

  • Os servidores v1 de armazenamento de uso geral (com suporte para armazenamento de até 4 TB) reterão até 2 backups completos de banco de dados, todos os backups diferenciais e backups de log de transações executados desde o primeiro backup completo do banco de dados.
  • Os servidores v2 de armazenamento de uso geral (com suporte para armazenamento de até 16 TB) manterão os instantâneos completos do banco de dados e os backups de log de transações nos últimos 8 dias.

Retenção de longa duração

Atualmente, a retenção de longo prazo de backups além de 35 dias ainda não é suportada nativamente pelo serviço. Você tem a opção de usar mysqldump para fazer backups e armazená-los para retenção de longo prazo. Nossa equipe de suporte blogou um artigo passo a passo para compartilhar como você pode alcançá-lo.

opções de redundância de cópia de segurança

O Banco de Dados do Azure para MySQL oferece a flexibilidade de escolher entre armazenamento de backup localmente redundante ou com redundância geográfica nas camadas de uso geral e otimização de memória. Quando os backups são armazenados em armazenamento de backup com redundância geográfica, eles não são apenas armazenados na região em que o servidor está hospedado, mas também são replicados para um data center emparelhado. Essa redundância geográfica oferece melhor proteção e capacidade de restaurar seu servidor em uma região diferente no caso de um desastre. A camada Basic oferece apenas armazenamento de backup com redundância local.

Nota

Para as seguintes regiões - Índia Central, França Central, Norte dos Emirados Árabes Unidos, África do Sul Norte; O armazenamento de uso geral v2 está em Visualização pública. Se você criar um servidor de origem no armazenamento de uso geral v2 (com suporte para armazenamento de até 16 TB) nas regiões acima mencionadas, não há suporte para habilitar o Backup com Redundância Geográfica.

Mudança do armazenamento de backup com redundância local para armazenamento de backup com redundância geográfica

Só é permitido configurar o armazenamento localmente redundante ou georredundante para cópias de segurança durante a criação do servidor. Assim que o servidor tiver sido aprovisionado, não poderá alterar a opção de redundância do armazenamento de cópias de segurança. Para mover seu armazenamento de backup do armazenamento localmente redundante para o armazenamento com redundância geográfica, criar um novo servidor e migrar os dados usando dump e restauração é a única opção suportada.

Custo de armazenamento de cópias de segurança

A Base de Dados do Azure para MySQL fornece até 100% do armazenamento do servidor aprovisionado como armazenamento de cópias de segurança sem custos adicionais. Qualquer armazenamento de backup adicional usado é cobrado em GB por mês. Por exemplo, se você provisionou um servidor com 250 GB de armazenamento, você tem 250 GB de armazenamento adicional disponível para backups do servidor sem custo adicional. O armazenamento consumido para backups com mais de 250 GB é cobrado de acordo com o modelo de preços.

Você pode usar a métrica de Armazenamento de Backup usada no Azure Monitor disponível por meio do portal do Azure para monitorar o armazenamento de backup consumido por um servidor. A métrica de armazenamento de backup usada representa a soma do armazenamento consumido por todos os backups completos 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 explicada anteriormente. Uma atividade transacional intensa no servidor pode aumentar a utilização do armazenamento de cópias de segurança, independentemente do tamanho total da base de dados. Para armazenamento com redundância geográfica, o uso do armazenamento de backup é duas vezes maior do que o armazenamento com redundância local.

O principal meio de controlar o custo do armazenamento de backup é definir o período de retenção de backup apropriado e escolher as opções corretas de redundância de backup para atender às metas de recuperação desejadas. Você pode selecionar um período de retenção de um intervalo de 7 a 35 dias. Os servidores de uso geral e otimizados para memória podem optar por ter armazenamento com redundância geográfica para backups.

Restauro

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 no servidor. No momento, a restauração não é suportada se o servidor original estiver no estado interrompido.

Existem dois tipos de restauração disponíveis:

  • A restauração point-in-time está disponível com qualquer opção de redundância de backup e cria um novo servidor na mesma região do servidor original, utilizando a combinação de backups completos e de log de transações.
  • A restauração geográfica está disponível somente se você configurou seu servidor para armazenamento com redundância geográfica e permite que você restaure seu servidor para uma região diferente utilizando o backup mais recente feito.

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

  • 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 da 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 para todas as tabelas no banco de dados. Para verificar se as tabelas têm chave primária, você pode usar a seguinte consulta:
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 uma base de dados grande ou muito ativa, o restauro pode demorar várias horas. Se houver uma indisponibilidade prolongada numa região, é possível que seja iniciado um número elevado de pedidos de georrestauro para a recuperação após desastre. Quando existem muitos pedidos, o tempo de recuperação de bases de dados individuais pode aumentar. A maioria dos restauros de bases de dados é concluída em menos de 12 horas.

Importante

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

Restauro para um ponto anterior no tempo

Independentemente da opção de redundância de backup, você pode executar uma restauração em qualquer point-in-time dentro do período de retenção de backup. Um novo servidor é criado na mesma região do Azure que o servidor original. Ele é criado com a configuração do servidor original para a camada de preço, geração de computação, número de vCores, tamanho do armazenamento, período de retenção de backup e opção de redundância de backup.

Nota

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

  • time_zone - Este valor a ser definido como DEFAULT value SYSTEM
  • event_scheduler - O event_scheduler está definido como OFF no servidor restaurado

Você precisará definir esses parâmetros do servidor reconfigurando o parâmetro do servidor

A restauração point-in-time é útil em vários cenários. Por exemplo, quando um usuário exclui dados acidentalmente, descarta uma tabela ou banco de dados importante ou se um aplicativo substitui acidentalmente dados bons por dados incorretos devido a um defeito do aplicativo.

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

Restauro geográfico

Você pode restaurar um servidor para outra região do Azure onde o serviço está disponível se tiver configurado seu servidor para backups com redundância geográfica.

  • Os servidores v1 de armazenamento de uso geral (com suporte para armazenamento de até 4 TB) podem ser restaurados para a região emparelhada geograficamente ou para qualquer região do Azure que ofereça suporte ao serviço Banco de Dados do Azure para MySQL - Servidor Único.
  • Os servidores de armazenamento de uso geral v2 (com suporte para armazenamento de até 16 TB) só podem ser restaurados em regiões do Azure que ofereçam suporte à infraestrutura de servidores de armazenamento de uso geral v2. Reveja os escalões de preço da Base de Dados do Azure para MySQL para obter a lista de regiões suportadas.

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 onde o servidor está hospedado. Se um incidente em grande escala em uma região resultar na indisponibilidade do seu aplicativo de banco de dados, você poderá restaurar um servidor dos backups 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 para uma região diferente. Esse atraso pode ser de até uma hora, portanto, se ocorrer um 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 pode levar mais de 24 horas, dependendo do tamanho dos dados, pois o tempo de cópia de backup de instantâneo completo inicial é muito maior. Os backups de snapshot 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. Se você estiver avaliando restaurações geográficas para definir seu RTO, recomendamos que aguarde e avalie a restauração geográfica somente após 24 horas da criação do servidor para obter melhores estimativas.

Durante o restauro geográfico, as configurações do servidor que podem ser alteradas incluem a geração de computação, vCore, período de retenção e opções de redundância de cópias de segurança. A alteração do escalão de preço (Básico, Fins Gerais ou Otimizado para Memória) ou do tamanho do armazenamento durante o restauro geográfico não é suportada.

O tempo estimado de recuperação depende de vários fatores, incluindo o tamanho da base de dados, o tamanho do registo de transações, a largura de banda da rede e o número total de bases de dados a recuperar na mesma região ao mesmo tempo. O tempo de recuperação é geralmente inferior a 12 horas.

Executar tarefas pós-restauração

Após uma restauração de qualquer mecanismo de recuperação, você deve executar as seguintes tarefas para que seus usuários e aplicativos voltem a funcionar:

  • Se o novo servidor se destinar a substituir o servidor original, redirecione clientes e aplicativos cliente para o novo servidor
  • Verifique se as regras de VNet apropriadas estão em vigor para que os usuários se conectem. Essas regras não são copiadas do servidor original.
  • Verifique se os logins apropriados e as permissões no nível do banco de dados estão em vigor
  • Configurar alertas, conforme adequado

Próximos passos