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

  • Artigo

APLICA-SE A: Banco de Dados do Azure para MySQL - Servidor Flexível

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

Descrição geral da Cópia de Segurança

O servidor flexível do Banco de Dados do Azure para MySQL dá suporte a dois tipos de backups para fornecer uma flexibilidade aprimorada para manter backups dos dados críticos para os negócios.

Cópia de segurança automatizada

O servidor flexível do Banco de Dados do Azure para MySQL faz backups instantâneos dos arquivos de dados e os armazena em um armazenamento redundante local. O servidor também executa o backup de logs de transações e também os armazena em armazenamento redundante local. 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 configurar o backup do banco de dados de 1 a 35 dias. Todas as cópias de segurança são encriptadas com encriptação AES de 256 bits para os dados armazenados em inatividade.

Backup sob demanda

O servidor flexível do Banco de Dados do Azure para MySQL também permite acionar backups sob demanda da carga de trabalho de produção, além dos backups automatizados feitos pelo serviço e armazená-los em alinhamento 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 point-in-time 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 acionar um total de 50 backups sob demanda do portal. Todas as cópias de segurança são encriptadas com encriptação AES de 256 bits para os dados armazenados em inatividade.

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

Frequência de cópia de segurança

Os backups em servidores flexíveis 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. Se uma cópia de segurança agendada falhar, o nosso serviço de cópia de segurança tenta a cada 20 minutos tirar uma cópia de segurança até ter êxito. Essas falhas de backup podem ocorrer devido a cargas de produção transacionais pesadas na instância do servidor.

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

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

A redundância de backup garante que seu 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 estende três opções aos usuários -

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

  • 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 armazenadas apenas na zona de disponibilidade na qual o servidor está hospedado, mas também são replicadas para outra zona de disponibilidade na mesma região. Essa opção pode ser aproveitada para cenários que exigem alta disponibilidade ou para restringir a replicação de dados 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 9's) de durabilidade de objetos Backups ao longo de um determinado ano. Pode-se selecionar a opção Alta disponibilidade com redundância de zona no momento da criação do servidor para garantir o armazenamento de backup com redundância de zona. A alta disponibilidade de um servidor pode ser desativada após a criação, mas o armazenamento de backup permanece redundante na zona.

  • Armazenamento de backup com redundância geográfica: quando os backups são armazenados em armazenamento de backup com redundância geográfica, várias cópias não são armazenadas apenas na região em que o servidor está hospedado, mas também são replicadas para sua região emparelhada geograficamente. Este procedimento proporciona uma melhor proteção e capacidade de restaurar o servidor numa região diferente em caso de desastre. Além disso, isso fornece pelo menos 99,9999999999999% (16 9's) de durabilidade dos objetos Backups ao longo de um determinado ano. Pode-se ativar a opção de redundância geográfica no momento da criação do servidor para garantir o armazenamento de backup com redundância geográfica. Além disso, você pode passar do armazenamento com redundância local para a criação de um servidor de postagem de armazenamento com redundância geográfica. A georredundância é suportada para servidores alojados em qualquer uma das regiões emparelhadas do Azure.

Nota

A Alta Disponibilidade com redundância de zona para suportar redundância de zona é apresentada atualmente apenas como uma operação de tempo de criação. Atualmente, 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.

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

Você pode mover o armazenamento de backups existente para o armazenamento com redundância geográfica usando as seguintes maneiras sugeridas:

  • Mudar do armazenamento de backup localmente redundante para o armazenamento com redundância geográfica - Para mover seu armazenamento de backup do armazenamento localmente redundante para o armazenamento com redundância geográfica, você pode alterar a configuração do servidor de Computação + Armazenamento do portal do Azure para habilitar a redundância geográfica para o servidor de origem localmente redundante. Os servidores HA redundantes da mesma zona também podem ser restaurados como um servidor com redundância geográfica de forma semelhante, pois o armazenamento de backup subjacente é localmente redundante para o mesmo.

  • Mudar do armazenamento de backup com redundância de zona para o armazenamento de backup com redundância geográfica - o servidor flexível do Banco de Dados do Azure para MySQL não oferece suporte ao armazenamento com redundância de zona para conversão de armazenamento com redundância geográfica por meio da alteração das configurações de Computação + Armazenamento depois que o servidor é provisionado. Para mover seu armazenamento de backup do armazenamento com redundância de zona para o armazenamento com redundância geográfica, há duas opções: a) Use o PITR (restauração point-in-time) para restaurar o servidor com a configuração desejada. b) Criar um novo servidor com a configuração desejada e migrar os dados usando dump e restauração.

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 1 a 35 dias com um 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.

O período de retenção de backup controla até onde uma operação de restauração point-in-time pode ser executada, uma vez que ela 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 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, instantâneos de banco de dados e backups de log de transações são armazenados nos últimos oito dias (1 dia antes da janela).

Custo de armazenamento de cópias de segurança

O banco de dados do Azure para servidor flexível MySQL 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, tem 250 GB de armazenamento disponíveis para backups do servidor sem custo adicional. Se o uso diário de backup for de 25 GB, você poderá ter até 10 dias de armazenamento de backup gratuito. 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 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 de armazenamento de backup usada representa a soma do armazenamento consumido por todos os backups de banco de dados e backups de log retidos com base no período de retenção de backup definido para o servidor. 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. 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. Pode selecionar um período de retenção entre 1 a 35 dias.

Importante

Os backups de um servidor de banco de dados configurado em uma configuração de alta disponibilidade redundante de zona acontecem a partir do servidor de banco de dados primário, pois a sobrecarga é mínima com backups de instantâneo.

Ver 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ê em qualquer momento. Isso inclui backups automatizados, bem como backups sob demanda. Pode-se usar essa folha para exibir os carimbos de data/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 indicando por quanto tempo um backup será mantido e uma ação de restauração.

Restauro

No Banco de Dados do Azure para servidor flexível MySQL, executar uma restauração cria um novo servidor a partir dos backups do servidor original. Existem dois tipos de restauração disponíveis:

  • 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.
  • Restauração geográfica: está disponível somente se você configurou seu servidor para armazenamento com redundância geográfica e permite restaurar seu servidor para uma região emparelhada geograficamente ou qualquer outra região com suporte do Azure onde o servidor flexível esteja disponível.

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.

Nota

Um servidor habilitado para Alta Disponibilidade se tornará não-HA (Alta Disponibilidade desabilitada) após a restauração para restauração point-in-time e restauração geográfica.

Restauro para um ponto anterior no tempo

No Banco de Dados do Azure para servidor flexível MySQL, executar uma restauração point-in-time cria um novo servidor a partir dos backups do servidor flexível na mesma região do 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, tags e configurações, como rede virtual e firewall, são herdadas do servidor de origem. A camada de computação e armazenamento, a configuração e as definições de segurança do servidor restaurado podem ser alteradas após a conclusão da restauração.

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 está definido como o valor do SISTEMA PREDEFINIDO
  • event_scheduler – o event_scheduler está definido como DESATIVADO no servidor restaurado

A restauração point-in-time é útil em vários cenários. Alguns dos casos de uso que são comuns incluem -

  • Quando um usuário exclui acidentalmente dados no banco de dados
  • O usuário descarta uma tabela ou banco de dados importante
  • O aplicativo do usuário substitui acidentalmente dados bons por dados incorretos devido a um defeito do aplicativo.

Você pode escolher entre o ponto de restauração mais recente, o ponto de restauração personalizado e o ponto de restauração mais rápido (restauração usando backup completo) por meio do portal do Azure.

  • Ponto de restauração mais recente: a opção de ponto de restauração mais recente ajuda você a restaurar o servidor para o carimbo de data/hora quando a operação de restauração foi acionada. Esta opção é útil para restaurar rapidamente o servidor para o estado mais atualizado.
  • Ponto de restauração personalizado: Esta opção permite que você escolha qualquer ponto no tempo dentro do período de retenção definido para este servidor. Esta opção é útil para restaurar o servidor no momento exato para recuperar de um erro do usuário.
  • Ponto de restauração mais rápido: esta opção permite que os usuários restaurem o servidor no tempo mais rápido possível para um determinado dia dentro do período de retenção definido para seu servidor. A restauração mais rápida é possível escolhendo o point-in-time de restauração no qual o backup completo é concluído. Essa operação de restauração simplesmente restaura o backup completo do snapshot e não garante a restauração ou recuperação de logs, o que o torna rápido. Recomendamos que você selecione um carimbo de data/hora de backup completo que seja maior do que o ponto no tempo de restauração mais antigo 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 e o tempo da restauração também. A recuperação do log de transações é a parte mais demorada do processo de restauração. Se o tempo de restauração for escolhido mais próximo do agendamento de backup de snapshot, as operações de restauração serão mais rápidas, já que o aplicativo de log de transações é mínimo. Para estimar o tempo de recuperação preciso para seu servidor, é altamente recomendável testá-lo em seu ambiente, pois ele tem muitas variáveis específicas do ambiente.

Importante

Se você estiver restaurando uma instância de servidor flexível do Banco de Dados do Azure para MySQL configurada com alta disponibilidade redundante de zona, o servidor restaurado será configurado na mesma região e zona do servidor primário e implantado como um único servidor em um modo não HA. Consulte Alta disponibilidade redundante de zona para servidor flexível.

Importante

Você pode recuperar um recurso de servidor flexível do Banco de Dados do Azure para MySQL excluído dentro de 5 dias a partir do momento da exclusão do servidor. Para obter um guia detalhado sobre como restaurar um servidor excluído, 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 geográfico

Você pode restaurar um servidor para sua região emparelhada geograficamente onde o serviço está disponível se tiver configurado seu servidor para backups com redundância geográfica ou qualquer outra região com suporte do Azure onde o servidor flexível do Banco de Dados do Azure para MySQL esteja disponível. Capacidade de restaurar para qualquer região com suporte do Azure não emparelhada (exceto Brazil South, USGov Virginia e West US 3) é conhecida como "Restauraçã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 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.

A restauração geográfica também pode ser executada em um servidor interrompido aproveitando a CLI do Azure. Leia Restaurar o Banco de Dados do Azure para servidor flexível MySQL com a CLI do Azure para saber mais sobre como restaurar geograficamente um servidor com a CLI do Azure.

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.

Nota

Se você estiver restaurando geograficamente uma instância de servidor flexível do Banco de Dados do Azure para MySQL configurada com alta disponibilidade redundante de zona, o servidor restaurado será 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. Consulte a alta disponibilidade redundante de zona para o servidor flexível do Banco de Dados do Azure para MySQL.

Importante

Quando a região primária está inativa, não é possível criar servidores com redundância geográfica na respetiva região emparelhada geograficamente porque o armazenamento não pode ser provisionado na região primária. Você deve aguardar que a região primária esteja pronta para provisionar servidores com redundância geográfica na região emparelhada geograficamente. Com a região primária inativa, você ainda pode restaurar geograficamente o servidor de origem para a região emparelhada geograficamente desativando a opção de redundância geográfica nas configurações de Computação + Armazenamento Configurar Servidor na experiência do portal de restauração e restaurar como um servidor localmente redundante para garantir a continuidade dos negócios.

Executar tarefas pós-restauração

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

  • Se o novo servidor quiser substituir o servidor original, redirecione os clientes e as aplicações cliente para o novo servidor.
  • Verifique se o firewall no nível do servidor e as regras de rede virtual apropriadas estão em vigor para que os usuários se conectem.
  • Verifique se os logins apropriados e as permissões no nível do banco de dados estão em vigor.
  • Configure alertas, conforme adequado.

Retenção a longo prazo (pré-visualização)

Os serviços de servidor flexível Backup do Azure e Banco de Dados do Azure para MySQL criaram uma solução de backup de longo prazo de classe empresarial para instâncias de servidor flexíveis do Banco de Dados do Azure para MySQL que retém backups por até 10 anos. Você pode usar a retenção de longo prazo de forma independente ou além da solução de backup automatizado oferecida pelo Banco de Dados do Azure para o servidor flexível MySQL, que oferece retenção de até 35 dias. Os backups automatizados são backups instantâneos adequados para recuperações operacionais, especialmente quando você deseja restaurar a partir dos backups mais recentes. Os backups de longo prazo ajudam você com suas necessidades de conformidade e auditoria. Além da retenção a 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 a partir de um único painel chamado Centro de Backup.
  • Cópias de segurança armazenadas num domínio de segurança e falha separado. Se o servidor de origem ou a assinatura for comprometido, os backups permanecerão seguros no cofre de Backup (nas contas de armazenamento gerenciado do Backup do Azure).

Limitações e considerações

  • Na visualização, a restauração LTR está atualmente disponível como RestoreasFiles para contas de armazenamento. A capacidade RestoreasServer será adicionada no futuro.

  • Atualmente, o backup LTR não é suportado para servidores habilitados para HA. Esta capacidade será adicionada no futuro.

  • Atualmente, não há suporte para a criação e o gerenciamento de LTR por meio da CLI do Azure.

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

Backup e exportação sob demanda (visualização)

O Servidor Flexível do Banco de Dados do Azure para MySQL agora oferece a capacidade de acionar um backup físico sob demanda no momento 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, migração e redundância de dados. Esses arquivos de backup físicos exportados podem ser usados para restaurar para um servidor MySQL local para ajudar a atender às necessidades de auditoria/conformidade/arquivamento de uma organização. O recurso está atualmente em visualização pública e disponível apenas em regiões de nuvem pública.

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

Perguntas mais frequentes (FAQs)

  • Como faço backup do meu servidor?

    Por padrão, o Banco de Dados do Azure para servidor flexível MySQL permite backups automatizados de todo o servidor (abrangendo todos os bancos de dados criados) com um período de retenção padrão de 7 dias. Você também pode acionar 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 você deseja fazer backup de uma instância de servidor flexível do Banco de Dados do Azure para MySQL em um armazenamento de Blob, consulte nosso blog da comunidade de tecnologia Backup do Banco de Dados do Azure para servidor flexível MySQL para um Armazenamento de Blob.

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

    Não, atualmente suportamos apenas um máximo de 35 dias de retenção automatizada de backup. Você pode fazer backups manuais e usá-los para requisitos de retenção de longo prazo.

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

    A primeira cópia de segurança de instantâneos é agendada imediatamente após a criação do servidor. Os backups instantâneos são feitos uma vez por dia. As cópias de segurança de registo de transações ocorrem a cada cinco minutos. As janelas de backup são inerentemente gerenciadas pelo Azure e não podem ser personalizadas.

  • As minhas cópias de segurança são encriptadas?

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

  • Posso restaurar uma(s) única(s) base(s) de dados/alguma(s)?

    Não há suporte para a restauração de um único ou poucos bancos de dados ou tabelas. Caso deseje restaurar bancos de dados específicos, execute uma Restauração Point in Time e, em seguida, extraia a(s) tabela(s) ou banco(s) de dados necessários.

  • O meu servidor está disponível durante a janela de backup?

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

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

    Não, os backups são acionados internamente como parte do serviço gerenciado e não têm nenhuma relação com a Janela de Manutenção Gerenciada.

  • Onde são armazenados os meus backups automatizados e como faço para gerenciar sua retenção?

    O servidor flexível do Banco de Dados do Azure para MySQL cria automaticamente backups de servidor e os armazena em armazenamento localmente redundante configurado pelo usuário ou em armazenamento com redundância geográfica. Estes ficheiros de cópia de segurança 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 posso validar meus backups?

    A melhor maneira de validar a disponibilidade de backups concluídos com êxito é visualizar os backups totalmente 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 de backups disponíveis, e o serviço de backup tentará a cada 20 minutos fazer um backup até que um backup bem-sucedido seja feito. Essas falhas de backup são devidas a cargas pesadas de produção transacional 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 Armazenamento de Backup Usado , que pode ajudá-lo a monitorar o uso total do backup.

  • O que acontece com as minhas cópias de segurança se eliminar o meu servidor?

    Se eliminar o servidor, todas as cópias de segurança que pertencem ao servidor também serão eliminadas e não poderão ser recuperadas. Para proteger os recursos do servidor após a implantação contra exclusão acidental ou alterações inesperadas, os administradores podem usar bloqueios de gerenciamento.

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

    Se você restaurar um servidor, isso sempre resultará na criação de um novo servidor de rede 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 conforme o período de retenção do servidor configurado.

  • Como sou cobrado e cobrado pelo uso de backups?

    O servidor flexível do Banco de Dados do Azure para MySQL fornece até 100% do seu armazenamento de servidor provisionado como armazenamento de backup sem custo adicional. Mais armazenamento de backup usado é cobrado em GB por mês, de acordo com o modelo de preços. O faturamento do armazenamento de backup também é regido pelo período de retenção de backup selecionado e pela opção de redundância de backup escolhida, além da atividade transacional no servidor, que afeta o armazenamento total de backup usado diretamente.

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

    Nenhum novo backup é executado para 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 qual retenção de backup para o servidor ativo é regida por sua janela de retenção de backup.

  • Como serei cobrado pelos backups de um servidor parado?

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

  • Como meus dados de backup são protegidos?

    O banco de dados do Azure para o servidor MySQL Flexible 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. Os backups feitos durante o período de retenção só podem ser lidos para fins de restauração e são excluídos após o período de retenção. Além disso, todos os backups no Banco de Dados do Azure para o servidor flexível MySQL são criptografados usando criptografia AES de 256 bits para os dados armazenados em repouso.

  • Como uma operação de restauração point-in-time (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 maior 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 a operação PITR. Quando a operação PITR estiver concluída, o uso de IOPS no servidor de origem retornará aos seus níveis habituais.

  • Como restauro o meu servidor? O portal do Azure dá suporte à Restauração Point In Time para todos os servidores, permitindo que os usuários restaurem para pontos de restauração mais recentes ou personalizados. Para restaurar manualmente seu servidor a partir dos backups feitos por mysqldump/myDumper, consulte Restaurar seu banco de dados usando myLoader.

  • Porque é que o meu restauro está a demorar tanto tempo?

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

    • O tamanho dos bancos de dados. Como parte do processo de recuperação, o banco de dados precisa ser hidratado a partir do último backup físico e, portanto, o tempo necessário para recuperar será proporcional ao tamanho do banco de dados.
    • A parte ativa da atividade de transação que precisa ser repetida para se recuperar. A recuperação pode levar mais tempo, dependendo da atividade de transação adicionada do último ponto de verificação bem-sucedido.
    • A largura de banda da rede, se o restauro for para uma região diferente.
    • O número de pedidos de restauro simultâneos que estão a ser processados na região de destino.
    • A presença de chaves primárias nas tabelas no banco de dados. Para uma recuperação mais rápida, considere adicionar chaves primárias para todas as tabelas no banco de dados.

  • A modificação de variáveis de banco de dados no nível de sessão afetará a restauração?

    Modificar variáveis de nível de sessão e executar instruções DML em uma sessão de cliente MySQL pode afetar a operação PITR (restauração point-in-time), pois essas modificações não são registradas no log binário usado para operação de backup e restauração. Por exemplo, foreign_key_checks são uma dessas variáveis de nível de sessão, que se desabilitadas para executar uma instrução DML que viola a restrição de chave estrangeira resulta em falha PITR (restauração point-in-time). A única solução alternativa em tal cenário seria selecionar um tempo PITR antes do momento em que foreign_key_checks foram desativados. Nossa recomendação é NÃO modificar nenhuma variável de sessão para uma operação PITR bem-sucedida.

Próximos passos