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

O Banco de Dados do Azure para MariaDB cria backups de servidor automaticamente e os armazena no armazenamento com redundância local ou geográfica 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 MariaDB 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 MariaDB. 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 de armazenamento de uso geral com 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 de armazenamento de uso geral com 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 completo é agendado imediatamente após a criação de um servidor. O primeiro backup de instantâneo completo é mantido como o backup de base do servidor. Os backups de instantâneo subsequentes são apenas backups diferenciais.

Os backups de instantâneo diferenciais ocorrem pelo menos uma vez por dia. Os backups de instantâneo diferenciais não ocorrem em um agendamento fixo. Os backups de instantâneo diferenciais ocorrem a cada 24 horas, a menos que o log de transações (binlog no MariaDB) exceda 50 GB desde o último backup diferencial. Em um dia, são permitidos no máximo seis instantâneos diferenciais.

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

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 sete 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, todos os backups necessários para restaurar o servidor nos últimos sete dias serão mantidos. Com uma janela de retenção de backup de sete dias:

  • Os servidores com armazenamento de até 4 TB manterão até dois backups de banco de dados completos, todos os backups diferenciais e backups de log de transações executados desde o backup de banco de dados completo mais antigo.
  • Os servidores com armazenamento de até 16 TB manterão o instantâneo completo do banco de dados, todos os instantâneos diferenciais e backups de log de transações dos últimos oito dias.

Retenção de longo prazo de backups

A retenção de longo prazo de backups acima de 35 dias no momento ainda não tem suporte nativo 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 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 MariaDB fornece a flexibilidade de escolher entre o armazenamento de backup com redundância local ou 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 data center emparelhado. Isso fornece maior proteção e 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.

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. Depois de o servidor ser provisionado, você não poderá 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 MariaDB 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.

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 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. O tempo de recuperação é menor do que 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.

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 que dão suporte a até 4 TB de armazenamento podem ser restaurados para a região emparelhada geograficamente ou para qualquer região que ofereça suporte a até 16 TB de armazenamento. Para servidores que dão suporte a até 16 TB de armazenamento, os backups geográficos podem ser restaurados em qualquer região que ofereça suporte a servidores de 16 TB também. 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. 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