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

  • Artigo

Importante

O Banco de Dados do Azure para MariaDB está no caminho da aposentadoria. É altamente recomendável migrar para o Banco de Dados do Azure para MySQL. Para obter mais informações sobre como migrar para o Banco de Dados do Azure para MySQL, consulte O que está acontecendo com o Banco de Dados do Azure para MariaDB?.

O Banco de Dados do Azure para MariaDB cria automaticamente backups de servidor e os armazena em armazenamento com redundância local ou georredundante configurado pelo usuário. 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

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 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.

Esses arquivos de backup não são expostos ao usuário 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 MariaDB. 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 de armazenamento de uso geral com 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 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 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 completa é agendada imediatamente após a criação do servidor. Esse primeiro backup de snapshot completo é mantido como backup básico do servidor. As cópias de segurança de instantâneos subsequentes são apenas cópias de segurança diferenciais.

As cópias de segurança de instantâneos diferenciais ocorrem, pelo menos, uma vez por dia. Os backups diferenciais de snapshot não ocorrem em um cronograma fixo. Os backups de snapshot 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. Num dia, são permitidos, no máximo, seis instantâneos diferenciais.

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

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 sete 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 for definido como sete dias, a janela de recuperação será considerada como últimos sete dias. Nesse cenário, todos os backups necessários para restaurar o servidor nos últimos sete dias são mantidos. Com uma janela de retenção de backup de sete dias:

  • Servidores com armazenamento de até 4 TB reterão até dois 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.
  • 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 nos últimos oito dias.

Retenção das cópias de segurança de longo prazo

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 MariaDB oferece a flexibilidade de escolher entre armazenamento de backup com redundância local 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 armazenados apenas na região em que o servidor está hospedado, mas também são replicados para um data center emparelhado. Este procedimento proporciona uma melhor proteção e capacidade de restaurar o servidor numa região diferente em caso de desastre. A camada Basic oferece apenas armazenamento de backup com redundância local.

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

O Banco de Dados do Azure para MariaDB fornece até 100% do seu armazenamento de servidor provisionado como armazenamento de backup sem custo adicional. Qualquer armazenamento de backup adicional usado é cobrado em GB por mês. Por exemplo, se você provisionou um servidor com 250 GB de armazenamento, terá 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 MariaDB, 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.

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 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 é inferior a 12 horas.

Importante

Os servidores excluídos podem ser restaurados somente 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.

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 que suportam até 4 TB de armazenamento podem ser restaurados para a região emparelhada geograficamente ou para qualquer região que suporte até 16 TB de armazenamento. Para servidores que suportam até 16 TB de armazenamento, os backups geográficos também podem ser restaurados em qualquer região que suporte servidores de 16 TB. Analise os níveis de preços do Banco de Dados do Azure para MariaDB para obter 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 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. Não há suporte para alterar o nível de preço (básico, uso geral ou memória otimizada) ou o tamanho do armazenamento durante a restauração geográfica.

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 é 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