Compartilhar via

Backup e restauração no Banco de Dados do Azure para MySQL – Servidor Flexível

  • Artigo

O servidor flexível do Banco de Dados do Azure para MySQL faz backups do servidor automaticamente e os armazena com segurança no armazenamento com redundância local dentro da região. 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.

Visão geral do backup

O Servidor Flexível do Banco de Dados do Azure para MySQL oferece suporte a dois tipos de backups para proporcionar maior flexibilidade na manutenção de backups dos dados essenciais aos negócios.

Backup Automatizado

O servidor flexível do Banco de Dados do Azure para MySQL faz backups instantâneos dos arquivos de dados e os mantêm em um armazenamento com redundância local. O servidor também executa backup de log de transações e os mantêm em armazenamento redundante local. 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. Opcionalmente, você pode configurar o backup do banco de dados de 1 a 35 dias. Todos os backups são criptografados usando a criptografia AES de 256 bits para os dados inativos armazenados.

Backup sob demanda

O Servidor Flexível do Banco de Dados do Azure para MySQL também permite que você acione backups sob demanda da carga de trabalho de produção, além dos backups automatizados feitos pelo serviço, e os armazene de acordo com a política de retenção de backup do servidor. Você pode usar esses backups como um ponto de restauração mais rápido para executar uma restauração pontual para reduzir os tempos de restauração em até 90%. O período de retenção de backup padrão é de sete dias. Opcionalmente, você pode configurar o backup do banco de dados de 1 a 35 dias. Você pode disparar um total de 50 backups sob demanda do portal. Todos os backups são criptografados usando a criptografia AES de 256 bits para os dados inativos armazenados.

Os arquivos de backup não podem ser exportados. Os backups podem ser usados somente para operações de restauração no servidor flexível do Banco de Dados do Azure para MySQL. Você também pode usar o mysqldump de um cliente MySQL para copiar um banco de dados.

Frequência de backup

Os backups em servidores flexíveis são baseados em instantâneos. O primeiro backup de instantâneo é 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. Se um backup agendado falhar, nosso serviço de backup tentará fazer um backup a cada 20 minutos até que ele seja realizado com êxito. Essas falhas de backup podem ocorrer devido às cargas de produção transacionais pesadas na instância do servidor.

Observação

  • Se o servidor enfrentar uma alta carga de transações, gerando arquivos binlog maiores e que crescem rapidamente, o serviço de backup fará vários backups por dia para garantir uma restauração mais confiável e rápida.
  • Para servidores 5.7, transações de execução longa/grandes podem impedir a aquisição de bloqueio no nível da instância global, o que é necessário para o backup diário bem-sucedido. Nesses cenários, os backups diários podem falhar. Para resolver isso, encerre a transação de execução longa ou reinicie o servidor. Para garantir operações mais suaves, é recomendável atualizar seus servidores MySQL 5.7 para a versão 8.0 usando uma atualização de versão principal.

Opções de redundância de backup

O servidor flexível do Banco de Dados do Azure para MySQL armazena várias cópias dos backups para que os dados sejam protegidos contra eventos planejados e não planejados, incluindo falhas de hardware transitórias, interrupções de energia ou rede e desastres naturais de grandes proporções. O servidor flexível do Banco de Dados do Azure para MySQL oferece a flexibilidade de escolher entre o armazenamento de backup com redundância local, com redundância de zona ou com redundância geográfica nas camadas de Uso Básico, Uso Geral e Comercialmente Crítico. Por padrão, o armazenamento de backup do servidor flexível do Banco de Dados do Azure para MySQL conta com redundância local para servidores com alta disponibilidade na mesma zona (HA) ou nenhuma configuração de alta disponibilidade e com redundância de zona para servidores com configuração de HA com redundância de zona.

A redundância de backup garante que o banco de dados atenda às metas de disponibilidade e durabilidade mesmo em caso de falhas e o servidor flexível do Banco de Dados do Azure para MySQL oferece mais três opções aos usuários -

  • Armazenamento de backup com redundância local: quando os backups são armazenados no armazenamento de backup com redundância local, várias cópias de backups são armazenadas no mesmo datacenter. Essa opção protege seus dados contra falhas de unidade e rack do servidor. Além disso, isso fornece pelo menos 99,999999999% (11 noves) de durabilidade de objetos de Backups em um determinado ano. Por padrão, o armazenamento de backup para servidores com HA (alta disponibilidade) da mesma zona ou nenhuma configuração de alta disponibilidade é definida como com redundância local.

  • Armazenamento de backup com redundância de zona: Quando os backups são armazenados em armazenamento de backup com redundância de zona, várias cópias não são apenas armazenadas na zona de disponibilidade em que seu servidor está hospedado, mas também são replicadas para outra zona de disponibilidade na mesma região. Essa opção pode ser usada para cenários que exigem alta disponibilidade ou para restringir a replicação de dados para dentro de um país/região para atender aos requisitos de residência de dados. Além disso, isso fornece pelo menos 99,9999999999% (12 noves) de durabilidade de objetos de Backups em um determinado ano. É possível selecionar a Alta disponibilidade com redundância de zona no tempo de criação do servidor para garantir o armazenamento de backup com redundância de zona. A Alta Disponibilidade de um servidor pode ser desabilitada após a criação, mas o armazenamento de backup permanece com redundância de zona.

  • Armazenamento de backup com redundância geográfica: quando os backups são armazenados no armazenamento de backup com redundância geográfica, várias cópias não são somente armazenados dentro da região em que o servidor está hospedado, mas também replicadas em sua região emparelhada geograficamente. Isso fornece maior proteção e capacidade de restaurar o servidor em uma região diferente em caso de desastre. Além disso, você obtém pelo menos 99,99999999999999% (16 noves) de durabilidade para objetos de backup em um determinado ano. É possível habilitar a opção de redundância geográfica no momento da criação do servidor para garantir um armazenamento de backup com redundância geográfica. Você também pode migrar do armazenamento com redundância local para o armazenamento com redundância geográfica após a criação do servidor. Há suporte para redundância geográfica para servidores hospedados em qualquer uma das regiões emparelhadas do Azure.

Observação

A alta disponibilidade com redundância geográfica para dar suporte à redundância de zonas é apresentada atualmente apenas como uma operação de tempo de criação. No momento, para um servidor de alta disponibilidade com redundância de zona, a redundância geográfica só pode ser habilitada/desabilitada no momento da criação do servidor.

Migrar de outras opções de armazenamento de backup para o armazenamento de backup com redundância geográfica

No entanto, você ainda pode mover o armazenamento de backups existente para um armazenamento com redundância geográfica por meio das seguintes sugestões:

  • Migrar do armazenamento de backup com redundância local para o armazenamento de backup com redundância geográfica: para migrar do armazenamento de backup com redundância local para o armazenamento com redundância geográfica, altere a configuração do servidor Computação + Armazenamento no portal do Azure para habilitar a redundância geográfica para o servidor de origem com redundância local. Os mesmos servidores de HA com Redundância de Zona também podem ser restaurados como um servidor com redundância geográfica de maneira semelhante, pois o armazenamento de backup subjacente é redundante localmente para o mesmo.

  • Mudar do armazenamento de backup com redundância de zona para com redundância geográfica: o servidor flexível do Banco de Dados do Azure para MySQL não dá suporte ao armazenamento com redundância de zona para conversão de armazenamento com redundância geográfica por meio de uma alteração das configurações de Computação + Armazenamento após o provisionamento do servidor. Para mover o armazenamento de backup do armazenamento com redundância de zona para o armazenamento com redundância geográfica, há duas opções: a) Usar recuperação pontual (PITR) para recuperar o servidor com a configuração desejada. b) Crie um novo servidor com a configuração desejada e migre os dados usando despejo e restauração.

Retenção de backup

Os backups são mantidos no servidor com base na configuração do período de retenção de backup. Você pode selecionar um período de retenção de 1 a 35 dias; 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 no portal do Azure.

O período de retenção de backup determina até que data, no passado, a restauração pontual 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 instantâneos do banco de dados e os backups de log de transações serão mantidos para os últimos oito dias (um dia antes da janela).

Custo do armazenamento de backup

O servidor flexível do 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, você terá 250 GB de armazenamento disponível para backups de servidor, sem nenhum custo adicional. Se o uso diário de backup for 25 GB, você poderá ter até 10 dias de armazenamento de backup gratuito. O armazenamento consumido para backups além de 250 GB será cobrado de acordo com o modelo de preços.

Você pode usar a métrica Monitorar o Banco de Dados do Azure para MySQL - Servidor Flexível 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 e backups de log mantidos com base no período de retenção de backup definido para o servidor. 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. O armazenamento de backup usado para um servidor com redundância geográfica é duas vezes maior do que um servidor com redundância local.

O principal meio de controlar o custo de armazenamento de backup é definindo o período de retenção de backup apropriado. Você pode selecionar um período de retenção entre um e 35 dias.

Importante

Os backups de um servidor de banco de dados, definido em uma configuração de alta disponibilidade com redundância de zona, ocorrem no servidor de banco de dados primário, pois a sobrecarga é mínima com backups de instantâneo.

Exibir backups completos disponíveis

A folha Backup e Restauração no portal do Azure fornece uma lista completa dos backups completos disponíveis para você a qualquer momento. Isso inclui backups automatizados, bem como backups sob demanda. É possível usar essa folha para exibir os registros de data e hora de conclusão de todos os backups completos disponíveis dentro do período de retenção do servidor e para executar operações de restauração usando esses backups completos. A lista de backups disponíveis inclui todos os backups completos dentro do período de retenção, um carimbo de data/hora mostrando a conclusão bem-sucedida, um carimbo de data/hora que indica por quanto tempo um backup será retido e uma ação de restauração.

Restaurar

No servidor flexível do Banco de Dados do Azure para MySQL, a realização de uma restauração cria um novo servidor de backup do servidor original. Há dois tipos de restauração disponíveis:

  • 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.
  • Restauração geográfica: só está disponível se você tiver configurado o servidor para armazenamento com redundância geográfica. Ela permite restaurar o servidor para uma região emparelhada geograficamente ou qualquer outra região com suporte do Azure em que o servidor flexível esteja disponível.

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.

Observação

O servidor habilitado para Alta Disponibilidade se tornará um servidor não Alta Disponibilidade (HA) desabilitada após a recuperação para recuperação pontual e restauração geográfica.

Restauração em um momento determinado

No servidor flexível do Banco de Dados do Azure para MySQL, uma recuperação pontual criará um novo servidor a partir dos backups do servidor flexível na mesma região que o servidor de origem. Ele é criado com a configuração do servidor original para a camada 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. Além disso, as marcas e configurações, como rede virtual e firewall, são herdadas do servidor de origem. As camadas de computação e armazenamento do servidor restaurado podem ser alteradas após a conclusão da restauração.

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 – Para servidores MySQL versão 5.7, o parâmetro do servidor event_scheduler é desativado automaticamente quando o backup é iniciado e o parâmetro do servidor event_scheduler é ativado novamente após a conclusão bem-sucedida do backup. No MySQL versão 8.0 para Banco de Dados do Azure para MySQL – Servidor Flexível, event_scheduler permanece inalterado durante os backups. Para garantir operações mais suaves, é recomendável atualizar seus servidores MySQL 5.7 para a versão 8.0 usando uma atualização de versão principal.

A Restauração pontual é útil em vários cenários. Alguns dos casos de uso comuns incluem:

  • Quando um usuário excluir acidentalmente os dados no banco de dados.
  • O usuário remove uma tabela ou um banco de dados importante.
  • O aplicativo do usuário substitui acidentalmente os dados corretos por incorretos devido a um defeito.

Você pode escolher entre o ponto de restauração mais recente, ponto de restauração personalizado e ponto de restauração mais rápido (restauração usando o backup completo) pela Restauração pontual no Banco de Dados do Azure para MySQL - Servidor Flexível com o portal do Azure.

  • Ponto de restauração mais recente: a opção de ponto de restauração mais recente ajuda a restaurar o servidor para o carimbo de data/hora do momento em que a operação de restauração foi disparada. Essa opção é útil para restaurar rapidamente o servidor para o estado mais atualizado.
  • Ponto de recuperação personalizado: essa opção permite que você escolha um ponto dentro do período de retenção definido para este servidor flexível. Essa opção é útil para restaurar o servidor no ponto exato para recuperar-se de um erro do usuário.
  • Ponto de recuperação mais rápido: essa opção permite que os usuários recuperem o servidor no tempo mais rápido possível para um determinado dia, dentro do período de retenção definido para seu servidor flexível. A restauração mais rápida é possível escolhendo o ponto de restauração no momento em que o backup completo é concluído. Essa operação de restauração simplesmente restaura o backup completo do instantâneo e não garante a restauração ou recuperação de logs, fazendo com que ele fique rápido. Recomendamos que você selecione um carimbo de data/hora de backup completo que seja maior do que o ponto de restauração mais antigo no tempo para uma operação de restauração bem-sucedida.

O tempo estimado de recuperação depende de vários fatores, incluindo os tamanhos do banco de dados, o tamanho do backup do log de transações, o tamanho da computação da SKU, assim como a hora da restauração. A recuperação do log de transações é a parte mais longa do processo de restauração. Quando o período de restauração é escolhido mais próximo do agendamento do backup de instantâneo, as operações de restauração são mais rápidas, pois a aplicação do log de transações é mínima. Para estimar o tempo de recuperação preciso do seu servidor, é altamente recomendável testá-lo em seu ambiente, pois ele tem muitas variáveis específicas de ambiente.

Importante

Quando você restaura uma instância do servidor flexível do Banco de Dados do Azure para MySQL, configurada com alta disponibilidade de redundância de zona, o servidor restaurado é configurado na mesma região e zona que o servidor primário e implantado como um único servidor flexível em modo não HA. Confira alta disponibilidade com redundância de zona para servidor flexível.

Importante

É possível recuperar um recurso do servidor flexível do Banco de Dados do Azure para MySQL excluído dentro de cinco dias a partir do momento da exclusão do servidor. Para ver um guia detalhado sobre como restaurar um servidor excluído, consulte as etapas documentadas. Para proteger recursos do servidor contra a exclusão acidental ou alterações inesperadas, após as implantações, os Administradores podem usar bloqueios de gerenciamento.

Restauração geográfica

É possível restaurar um servidor para a região emparelhada geograficamente onde o serviço está disponível se você tiver configurado o servidor para backups com redundância geográfica ou qualquer outra região compatível com o servidor flexível do Banco de Dados do Azure para MySQL onde o servidor flexível esteja disponível. A capacidade de recuperar para qualquer região não emparelhada com suporte do Azure (exceto Brazil South, USGov Virginia e West US 3) é conhecida como "Recuperação Geográfica Universal"

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.

A restauração geográfica também pode ser realizada em um servidor parado que utiliza CLI do Azure. Leia Restauração pontual no Banco de Dados do Azure para MySQL - Servidor Flexível com a CLI do Azure para saber mais sobre a restauração geográfica de um servidor com a CLI do Azure.

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.

Observação

Quando você restaura geograficamente uma instância de servidor flexível do Banco de Dados do Azure para MySQL configurada com alta disponibilidade com redundância de zona, o servidor restaurado é configurado na região emparelhada geograficamente e na mesma zona do servidor primário e implantado como uma única instância de servidor flexível do Banco de Dados do Azure para MySQL em um modo não HA. Confira Alta disponibilidade com redundância de zona para o servidor flexível do Banco de Dados do Azure para MySQL.

Importante

Quando a região primária está inativa, você não pode criar servidores com redundância geográfica na respectiva região emparelhada geograficamente, pois o armazenamento não pode ser provisionado na região primária. É necessário aguardar que a região primária fique ativa para provisionar servidores com redundância geográfica na região emparelhada geograficamente.
Com a região primária abaixo, ainda é possível restaurar geograficamente o servidor de origem para a região emparelhada geograficamente desabilitando a opção de redundância geográfica na Computação + definir as configurações do Servidor de Configuração de Armazenamento na experiência do portal de restauração e restaurar como um servidor com redundância local para garantir a continuidade dos negócios.

Executar tarefas de pós-restauração

Após uma restauração do mecanismo de recuperação a partir do ponto de restauração mais recente ou do ponto de restauração personalizado, você deve executar as tarefas a seguir para que seus usuários e aplicativos voltem a funcionar:

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

Retenção de longo prazo (versão prévia)

Observação

No momento, o recurso de visualização - solução de "Retenção de longo prazo" para a proteção dos servidores flexíveis do Banco de Dados do Azure para MySQL usando o Backup do Azure está pausado. Evite configurar novos backups até segunda ordem. Tenha certeza de que todos os dados de backup existentes estão seguros e disponíveis para restauração.

O Backup do Azure e os serviços do servidor flexível do Banco de Dados do Azure para MySQL criaram uma solução de backup de longo prazo de classe empresarial para instâncias do servidor flexível do Banco de Dados do Azure para MySQL que retêm backups por até 10 anos. É possível usar a retenção de longo prazo de forma independente ou além da solução de backup automatizada oferecida pelo servidor flexível do Banco de Dados do Azure para MySQL, que oferece retenção de até 35 dias. Backups automatizados são backups de instantâneo adequados para recuperações operacionais, especialmente quando você deseja restaurar a partir dos backups mais recentes. Os backups de longo prazo ajudam você a resolver suas necessidades de conformidade e de auditoria. Além da retenção de longo prazo, a solução oferece os seguintes recursos:

  • Backups agendados e sob demanda controlados pelo cliente
  • Gerencie e monitore todas as operações e trabalhos relacionados ao backup em servidores, grupos de recursos, locais, assinaturas e locatários em um único painel chamado Centro de Backup.
  • Backups armazenados em domínios separados de falha e segurança. Se o servidor de origem ou a assinatura estiverem comprometidos, os backups permanecerão seguros no cofre de Backup (em contas de armazenamento gerenciadas do Backup do Azure).

Limitações e considerações

  • Na versão prévia, a restauração do LTR está atualmente disponível como RestoreasFiles nas contas de armazenamento. A funcionalidade RestoreasServer será adicionada no futuro.
  • No momento, não há suporte para criação e gerenciamento de LTR por meio da CLI do Azure.

Para obter mais informações sobre como executar um backup de longo prazo, consulte o guia de instruções

Backup sob demanda e exportação (versão prévia)

O servidor flexível do Banco de Dados do Azure para MySQL agora oferece a capacidade de disparar um backup físico sob demanda do servidor e exportá-lo para uma conta de armazenamento do Azure (Armazenamento de Blobs do Azure). Depois de exportados, esses backups podem ser usados para recuperação de dados, migração e redundância. Esses arquivos de backup físico exportados podem ser usados para restaurar de volta para um servidor MySQL local para ajudar a atender às necessidades de auditoria/conformidade/arquivamento de uma organização. O recurso está atualmente em versão prévia pública e está disponível apenas em regiões de nuvem pública.

Para obter mais informações sobre o backup de exportação, visite o guia de instruções

Perguntas frequentes (FAQs)

  • Como fazer backup do meu servidor?

    Por padrão, o servidor flexível do Banco de Dados do Azure para MySQL permite fazer backups automatizados de todo o servidor (abrangendo todos os banco de dados criados) com um período de retenção padrão de sete dias. Você também pode disparar um backup manual usando o recurso de backup sob demanda. A outra maneira de fazer um backup manualmente é usando ferramentas da comunidade, como mysqldump, conforme documentado aqui, ou mydumper, conforme documentado aqui. Se quiser fazer backup de uma instância de servidor flexível do Banco de Dados do Azure para MySQL em um armazenamento de Blobs, confira o blog da comunidade técnica Backup do servidor flexível do Banco de Dados do Azure para MySQL para um Armazenamento de Blobs.

  • Posso configurar backups automáticos para serem retidos por longo prazo?

    Não, atualmente só damos suporte a um máximo de 35 dias de retenção de backup automático. Você pode fazer backups manuais e usá-los para o requisito de retenção de longo prazo.

  • Quais são as janelas de backup para o meu servidor? Posso personalizá-las?

    O primeiro backup de instantâneo é agendado imediatamente após a criação de um servidor. Os backups de instantâneo são feitos uma vez ao dia. Os backups de log de transações ocorrem a cada cinco minutos. As janelas de backup são gerenciadas de forma inerente pelo Azure e não podem ser personalizadas.

  • Meus backups são criptografados?

    Todos os dados, backups e arquivos temporários do servidor flexível do Banco de Dados do Azure para MySQL criados durante a consulta são criptografados com criptografia AES de 256 bits. A criptografia de armazenamento está sempre ativada e não pode ser desativada.

  • Posso restaurar um ou mais bancos de dados?

    Não há suporte para a restauração de um ou mais bancos de dados ou tabelas. Caso você queira restaurar bancos de dados específicos, execute uma Restauração pontual e, em seguida, extraia as tabelas ou os bancos de dados necessários.

  • Meu servidor permanece disponível durante a janela de backup?

    Sim. Os backups são operações online baseados em instantâneo. A operação de instantâneo leva apenas alguns segundos e não interfere nas cargas de trabalho de produção, garantindo a alta disponibilidade do servidor.

  • Ao configurar a janela de manutenção do servidor, precisamos levar em conta a janela de backup?

    Não, os backups são disparados internamente como parte do serviço gerenciado e não têm nenhuma influência sobre a janela de manutenção gerenciada.

  • Onde meus backups automatizados são armazenados e como gerencio a retenção deles?

    O servidor flexível do 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. Esses arquivos de backup não podem ser exportados. O período de retenção de backup padrão é de sete dias. Opcionalmente, você pode configurar o backup do banco de dados de 1 a 35 dias.

  • Como eu posso validar meus backups?

    A melhor maneira de validar a disponibilidade de backups concluídos com êxito é exibir os backups completos automatizados feitos dentro do período de retenção na folha Backup e Restauração. Se um backup falhar, ele não será listado na lista backups disponíveis e nosso serviço de backup tentará a cada 20 minutos fazer um backup, até que um backup bem-sucedido seja realizado. Essas falhas de backup são devido a cargas de produção transacionais pesadas no servidor.

  • Onde posso ver o uso do backup?

    No portal do Azure, na guia Monitoramento - seção Métricas, você pode encontrar a métrica Monitorar o Banco de Dados do Azure para MySQL - Servidor Flexível, o que pode ajudá-lo a monitorar o uso total do backup.

  • O que acontece com meus backups se eu excluir meu servidor?

    Se você excluir o servidor, todos os backups que pertencem ao servidor também serão excluídos e não poderão ser recuperados. Para proteger recursos do servidor contra a exclusão acidental ou alterações inesperadas, após as implantações, os Administradores podem usar bloqueios de gerenciamento.

  • O que acontece com meus backups quando restauro um servidor?

    Se você restaurar um servidor, ele sempre resultará na criação de um novo servidor líquido que foi restaurado usando os backups do servidor original. O backup antigo do servidor original não é copiado para o servidor recém-restaurado e permanece com o servidor original. No entanto, para o servidor recém-criado, o primeiro backup de instantâneo é agendado imediatamente após a criação de um servidor e o serviço garante que backups automatizados diários sejam feitos e armazenados de acordo com o período de retenção do servidor configurado.

  • Como sou cobrado e pago pelo uso de backups?

    O servidor flexível do 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 é cobrado em GB por mês, de acordo com o modelo de preços. A cobrança de armazenamento de backup também depende do período de retenção de backup selecionado, além da opção de redundância de backup escolhida de forma separada da atividade transacional no servidor que impacta o armazenamento de backup total usado diretamente.

  • Como os backups são retidos nos servidores parados?

    Não são executados backups novos de servidores interrompidos. Todos os backups mais antigos (dentro da janela de retenção) no momento da interrupção do servidor são retidos até que o servidor seja reiniciado. Após isso, a retenção de backup do servidor ativo depende da janela de retenção de backup.

  • Como eu serei cobrado por um servidor interrompido?

    Enquanto a instância do servidor está interrompida, você é cobrado pelo armazenamento provisionado (incluindo o IOPS provisionado) e pelo armazenamento de backup (backups armazenados em sua janela de retenção especificada). O armazenamento de backup gratuito é limitado ao tamanho do banco de dados provisionado e se aplica somente aos servidores ativos.

  • Como meus dados de backup são protegidos?

    O Servidor Flexível do Banco de Dados do Azure para MySQL protege seus dados de backup bloqueando quaisquer operações que possam levar à perda de pontos de recuperação durante o período de retenção configurado. O backup feito durante o período de retenção só pode ser lido para fins de restauração e é excluído após o período de retenção. Além disso, todos os backups no servidor flexível do Banco de Dados do Azure para MySQL são criptografados com a criptografia AES de 256 bits para os dados inativos armazenados.

  • Como uma operação de recuperação pontual (PITR) afeta o uso de IOPS?

    Durante uma operação PITR no Banco de Dados do Azure para MySQL - Servidor Flexível, um novo servidor é criado e os dados são copiados do armazenamento do servidor de origem para o armazenamento do novo servidor. Esse processo resulta em um aumento do uso de IOPS no servidor de origem. Esse aumento no uso de IOPS é uma ocorrência normal e não indica nenhum problema com o servidor de origem ou com a operação PITR. Depois que a operação de PITR for concluída, o uso de IOPS no servidor de origem retornará aos níveis usuais.

  • Como fazer a restauração do meu servidor? O portal do Azure dá suporte à restauração pontual (para todos os servidores), permitindo que os usuários restaurem para o ponto de recuperação mais recente ou personalizado. Para restaurar manualmente o servidor dos backups feitos por meio do mysqldump/myDumper, consulteRecuperar seu banco de dados usando o myLoader.

  • Por que a minha restauração está demorando tanto?

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

    • O tamanho dos bancos de dados. Durante o processo de recuperação, o banco de dados precisa ser hidratado a partir do backup físico mais recente e, portanto, o tempo necessário para a recuperação será proporcional ao tamanho do banco de dados.
    • A porção ativa da atividade de transação que precisa ser reproduzida para a recuperação. A recuperação pode levar mais tempo dependendo da atividade de transação adicional do último ponto de verificação bem-sucedido.
    • A largura de banda de rede se a restauração for para uma região diferente.
    • O número de solicitações simultâneas de restauração que estão 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.

  • Modificar variáveis de banco de dados no nível da sessão afetará a recuperação?

    Modificar variáveis de nível de sessão e executar instruções DML na sessão do cliente MySQL pode afetar a operação PITR (recuperação pontual), pois essas modificações não são registradas no log binário que é usado para operação de backup e restauração. Por exemplo, foreign_key_checks é uma variável de nível de sessão que, se desabilitada para executar uma instrução DML que viola a restrição de chave estrangeira, resultará em falha de PITR (restauração pontual). A única solução alternativa nesse cenário seria selecionar um horário de PITR anterior ao momento em que os foreign_key_checks foram desabilitados. Nossa recomendação é NÃO modificar nenhuma variável de sessão para ter uma operação PITR bem-sucedida.

Conteúdo relacionado