Backup e restaurar no Base de Dados do Azure para MySQL Servidor Flexível

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

Base de Dados do Azure para MySQL Servidor Flexível, cria automaticamente cópias de segurança do servidor e armazena-as de forma segura em 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 Flexible Server retira cópias de segurança instantâneas dos ficheiros de dados e armazena-os num armazenamento redundante local. O servidor também realiza registos de transações de backup e também os armazena em armazenamento redundante local. Estas cópias de segurança permitem restaurar um servidor em qualquer ponto no tempo dentro do período de retenção de backup configurado. O período de retenção de backup predefinido é de sete dias. Pode configurar opcionalmente a cópia de segurança da base de dados de 1 a 35 dias. Todas as cópias de segurança são encriptadas utilizando encriptação AES de 256 bits para os dados armazenados em repouso.

Estes ficheiros de reserva não podem ser exportados. As cópias de segurança só podem ser utilizadas para operações de restauro no servidor Flexível. Também pode utilizar o mysqldump de um cliente MySQL para copiar uma base de dados.

Frequência de cópia de segurança

As cópias de segurança nos servidores flexíveis são baseadas em instantâneos. A primeira cópia de segurança instantânea é programada imediatamente após a criação de um servidor. As cópias de segurança instantâneas são tomadas diariamente uma vez. As cópias de segurança de registo de transações ocorrem a cada cinco minutos. Se uma cópia de segurança programada falhar, o nosso serviço de backup tenta a cada 20 minutos fazer uma cópia de segurança até que seja tomada uma cópia de segurança bem sucedida. Estas falhas de backup podem ocorrer devido a pesadas cargas de produção transacional na instância do servidor.

Backup opções de redundância

Base de Dados do Azure para MySQL armazena várias cópias das suas cópias de segurança para que os seus dados seja protegido contra eventos planeados e não planeados, incluindo falhas de hardware transitórios, falhas de rede ou de energia e desastres naturais maciços. Base de Dados do Azure para MySQL proporciona a flexibilidade para escolher entre o armazenamento de backup local redundante, redundante ou geo-redundante nos níveis Básico, Fins Gerais e Crítico para a Empresa. Por padrão, Base de Dados do Azure para MySQL armazenamento de backup do servidor é localmente redundante para servidores com alta disponibilidade de zona (HA) ou nenhuma configuração de alta disponibilidade, e zona redundante para servidores com configuração HA redundante de zona.

Backup redundância garante que a sua base de dados cumpre os seus objetivos de disponibilidade e durabilidade mesmo face a falhas e Base de Dados do Azure para MySQL alarga três opções aos utilizadores -

  • Armazenamento de backup localmente redundante : Quando as cópias de segurança são armazenadas no armazenamento de backups localmente redundantes, várias cópias de cópias de cópias de segurança são armazenadas no mesmo centro de dados. Esta opção protege os seus dados contra as falhas de suporte do servidor e de acionamento. Também isto fornece pelo menos 99.9999999999999999999999 (11 9's) de objetos backups durante um determinado ano. Por padrão, o armazenamento de backup para servidores com alta disponibilidade de zona (HA) ou nenhuma configuração de alta disponibilidade é definido para localmente redundante.

  • Armazenamento de backup redundante de zona : Quando as cópias de segurança são armazenadas no armazenamento de backup redundante de zona, várias cópias não são apenas armazenadas dentro da zona de disponibilidade em que o seu servidor está hospedado, mas também são replicadas para outra zona de disponibilidade na mesma região. Esta opção pode ser alavancada para cenários que exijam elevada disponibilidade ou para restringir a replicação de dados a um país/região para satisfazer os requisitos de residência de dados. Também isto fornece pelo menos 99.99999999999999999999999999 (12 9's) de objetos backups ao longo de um ano. Pode-se selecionar Zone-Redundant opção de Alta Disponibilidade no servidor criar tempo para garantir o armazenamento de backup redundante em zonas. A Alta Disponibilidade para um servidor pode ser desativada, no entanto, o armazenamento de backup continuará a ser redundante na zona.

  • Armazenamento de backup geo-redundante : Quando as cópias de segurança são armazenadas no armazenamento de backups geo-redundantes, várias cópias não são apenas armazenadas na região em que o seu servidor está hospedado, mas também são replicadas na sua região geo-emparelhada. Este procedimento proporciona uma melhor proteção e capacidade de restaurar o servidor numa região diferente em caso de desastre. Também isto fornece pelo menos 99.9999999999999999999999999999999999 (16 9's) de objetos backups ao longo de um determinado ano. Pode-se ativar Geo-Redundancy opção no servidor criar tempo para garantir o armazenamento de backup geo-redundante. Além disso, pode passar de armazenamento localmente redundante para criar servidor de posts de armazenamento geo-redundantes. A georredundância é suportada para servidores alojados em qualquer uma das regiões emparelhadas do Azure.

Nota

A alta disponibilidade redundante para apoiar a redundância da zona é atualmente emergida apenas como uma operação de tempo de criação. Atualmente, para um servidor de alta disponibilidade redundante de zona, a geo-redundância só pode ser ativada/desativada no servidor criar tempo.

Passando de outras opções de armazenamento de backup para armazenamento de backup geo-redundante

Pode mover o armazenamento de backups existente para armazenamento geo-redundante utilizando as seguintes formas sugeridas:

  • Passando de armazenamento de backup localmente redundante para geo-redundante - De forma a mover o seu armazenamento de backup de armazenamento localmente redundante para armazenamento geo-redundante, pode alterar a configuração do servidor Compute + Armazenamento a partir de portal do Azure para permitir a redundância geo-redundância para o servidor de fonte localmente redundante. Os servidores HA redundantes da mesma zona também podem ser restaurados como um servidor geo-redundante de forma semelhante à que o armazenamento de backup subjacente é localmente redundante para o mesmo.

  • Passando de uma zona redundante para um armazenamento de backup geo-redundante - Base de Dados do Azure para MySQL não suporta o armazenamento redundante de zona para conversão de armazenamento geo-redundante através do Compute + Armazenamento alterações de definições ou operação de restauro pontual. Para mover o armazenamento de backup do armazenamento redundante da zona para o armazenamento geo-redundante, criar um novo servidor e migrar os dados usando o despejo e restaurar é a única opção suportada.

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

As cópias de segurança são mantidas com base na definição do período de retenção de backup no servidor. Pode selecionar um período de retenção de 1 a 35 dias com um período de retenção predefinido de sete dias. Pode definir o período de retenção durante a criação do servidor ou mais tarde atualizando a configuração de backup utilizando portal do Azure.

O período de retenção de backups regula até onde pode ser realizada uma operação de restauro pontual, uma vez que é baseada em cópias de segurança 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 restauro. Todas as cópias de segurança necessárias para a restauração pontual dentro do período de retenção de backup são mantidas no armazenamento de backup. Por exemplo - se o período de retenção de backup estiver definido para sete dias, a janela de recuperação é considerada dura sete dias. Neste cenário, todas as cópias de segurança necessárias para restaurar o servidor nos últimos sete dias são mantidas. Com uma janela de retenção de backup de sete dias, as imagens de base de dados e cópias de segurança do registo de transações são armazenadas nos últimos oito dias (1 dia antes da janela).

Backup custo de armazenamento

O servidor flexível fornece até 100% do armazenamento do servidor a provisionado como armazenamento de backup sem custos adicionais. Qualquer armazenamento adicional de backup utilizado é cobrado em GB por mês. Por exemplo, se tiver provisionado um servidor com 250 GB de armazenamento, tem 250 GB de armazenamento disponível para cópias de segurança do servidor sem custo adicional. Se o uso diário de backup for de 25GB, então pode ter até 10 dias de armazenamento gratuito de backup. Armazenamento consumidos por backups mais de 250 GB é cobrado de acordo com o preço modelo.

Pode utilizar a métrica Backup Armazenamento utilizada no Azure Monitor disponível no portal do Azure para monitorizar o armazenamento de cópia de segurança consumido por um servidor. A métrica Backup Armazenamento utilizada representa a soma de armazenamento consumida por todas as cópias de segurança da base de dados e cópias de segurança de registo mantidas 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. Backup armazenamento usado para um servidor geo-redundante é o dobro do de um servidor redundante localmente.

O principal meio de controlar o custo de armazenamento de backup é estabelecendo o período de retenção de backup apropriado. Pode selecionar um período de retenção entre 1 a 35 dias.

Importante

As cópias de segurança de um servidor de base de dados configurados numa configuração de alta disponibilidade redundante de zonas acontecem a partir do servidor de base de dados primário, uma vez que a sobrecarga é mínima com cópias de segurança instantâneas.

Ver cópias de segurança completas disponíveis

A lâmina Backup e Restaurar no portal do Azure lista as cópias de segurança automáticas tiradas diariamente uma vez. Pode-se utilizar esta lâmina para visualizar os prazos de conclusão para todas as cópias de segurança completas disponíveis dentro do período de retenção do servidor e para executar operações de restauro utilizando estes backups completos. A lista de backups disponíveis inclui todos os backups automatizados completos dentro do período de retenção, um timetamp que mostra a conclusão bem sucedida, um timetamp indicando quanto tempo uma cópia de segurança será mantida, e uma ação de restauro.

Restauro

Em Base de Dados do Azure para MySQL, executar uma restauração cria um novo servidor a partir das cópias de segurança do servidor original. Existem dois tipos de restauro disponíveis:

  • Restauro pontual: está disponível com a opção de redundância de backup e cria um novo servidor na mesma região que o seu servidor original.
  • Geo-restauro: só está disponível se configurar o seu servidor para armazenamento geo-redundante e permitir-lhe restaurar o seu servidor na região geo-emparelhada. O restauro geográfico para outras regiões não é atualmente suportado.

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

  • O tamanho das bases de dados
  • O número de registos de transações envolvidos
  • A quantidade de atividade que precisa de ser repetida para recuperar ao ponto de restauração
  • 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 alvo
  • A presença da chave primária nas tabelas da base de dados. Para uma recuperação mais rápida, considere adicionar a chave primária para todas as tabelas da sua base de dados.

Nota

O servidor ativado por Alta Disponibilidade tornar-se-á servidor não-HA (Desativado de Alta Disponibilidade) após a restauração do ponto no tempo e restauro de Geo-restauro.

Restauro para um ponto anterior no tempo

Em Base de Dados do Azure para MySQL Servidor Flexível, executar uma restauração pontual cria um novo servidor a partir das cópias de segurança do servidor flexível na mesma região que o servidor de origem. É criado com a configuração do servidor original para o nível de computação, número de vCores, tamanho de 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. As definições de computação e armazenamento do servidor restaurado podem ser alteradas após a conclusão da restauração.

Nota

Existem dois parâmetros de servidor que são reiniciados para valores predefinidos (e não são copiados do servidor primário) após a operação de restauro

  • time_zone - Este valor para definir para DEFAULT Value SYSTEM
  • event_scheduler - O event_scheduler está definido para OFF no servidor restaurado

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

  • Quando um utilizador elimina acidentalmente os dados na base de dados
  • O utilizador deixa cair uma tabela ou base de dados importante
  • A aplicação do utilizador substitui acidentalmente bons dados com dados ruins devido a um defeito de aplicação.

Pode escolher entre o último ponto de restauro, o ponto de restauração personalizado e o ponto de restauro mais rápido (restaurar com cópia de segurança total) através portal do Azure.

  • Último ponto de restauro: A última opção ponto de restauro ajuda-o a restaurar o servidor no timetamp quando a operação de restauro foi desencadeada. Esta opção é útil para restaurar rapidamente o servidor para o estado mais atualizado.
  • Ponto de restauração personalizado: Isto permitir-lhe-á escolher qualquer ponto no tempo dentro do período de retenção definido para este servidor flexível. Esta opção é útil para restaurar o servidor no momento exato para recuperar de um erro do utilizador.
  • Ponto de restauro mais rápido: Esta opção permite que os utilizadores restaurem o servidor no tempo mais rápido possível durante um determinado dia dentro do período de retenção definido para o seu servidor flexível. A restauração mais rápida é possível escolhendo o ponto de restauro no tempo em que a cópia de segurança completa é completa. Esta operação de restauro simplesmente restaura a cópia de segurança total do instantâneo e não justifica a restauração ou recuperação de troncos, o que o torna rápido. Recomendamos que selecione um relógio de segurança completo que seja maior do que o ponto de restauro mais antigo a tempo para uma operação de restauro bem sucedida.

O tempo estimado de recuperação depende de vários fatores, incluindo os tamanhos da base de dados, o tamanho da cópia de segurança do registo de transações, o tamanho do cálculo do SKU e a hora da restauração também. A recuperação do registo de transações é a parte mais demorada do processo de restauro. Se o tempo de restauro for escolhido mais perto do calendário de backup snapshot, as operações de restauro são mais rápidas, uma vez que a aplicação de registo de transações é mínima. Para estimar o tempo de recuperação exato para o seu servidor, recomendamos vivamente testá-lo no seu ambiente, uma vez que tem demasiadas variáveis específicas do ambiente.

Importante

Se estiver a restaurar um servidor flexível configurado com uma zona redundante de alta disponibilidade, o servidor restaurado será configurado na mesma região e zona que o seu servidor primário, e implantado como um único servidor flexível num modo não HA. Consulte a zona redundante alta disponibilidade para servidor flexível.

Importante

Pode recuperar um recurso de servidor flexível MySQL eliminado no prazo de 5 dias a partir do momento da eliminação do servidor. Para obter um guia detalhado sobre como restaurar um servidor eliminado, consulte os passos documentados. Para proteger os recursos do servidor após a implementação de eliminação acidental ou alterações inesperadas, os administradores podem alavancar os bloqueios de gestão.

Georrestauro

Pode restaurar um servidor na região geo-emparelhada onde o serviço está disponível se tiver configurado o seu servidor para cópias de segurança geo redundantes. O restauro geográfico para outras regiões não é atualmente suportado.

O geo-restauro é a opção de recuperação padrão quando o seu servidor está indisponível devido a um incidente na região onde o servidor está hospedado. Se um incidente em larga escala numa região resultar na indisponibilidade da sua aplicação de base de dados, pode restaurar um servidor das cópias de segurança geo-redundantes para um servidor em qualquer outra região. Geo-restauração utiliza a cópia de segurança mais recente do servidor. Há um atraso entre quando um backup é tomado e quando é replicado para diferentes regiões. Este atraso pode ser de até uma hora, por isso, se ocorrer uma catástrofe, pode haver até uma hora de perda de dados.

Durante o geo-restauro, as configurações do servidor que podem ser alteradas incluem apenas a configuração de segurança (regras de firewall e definições de rede virtual). A alteração de outras configurações do servidor, tais como o nível de cálculo, armazenamento ou preços (Básico, Fins Gerais ou Crítico para a Empresa) durante a geo-restauração não é suportado.

O geo-restauro também pode ser realizado num servidor parado que alavanca Azure CLI. Leia Restaurar Base de Dados do Azure para MySQL - Servidor Flexível com CLI Azure para saber mais sobre a restauração de um servidor com O Azure CLI.

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 estiver a restaurar um servidor flexível configurado com alta disponibilidade redundante de zona, o servidor restaurado será configurado na região geo emparelhada e na mesma zona do seu servidor primário, e implantado como um único servidor flexível num modo não HA. Consulte a zona redundante alta disponibilidade para servidor flexível.

Importante

Quando a região primária está em baixo, não se pode criar servidores geo-redundantes na respetiva região geoconsepartada, uma vez que o armazenamento não pode ser alotivo na região primária. É preciso esperar que a região primária esteja à altura da provisão de servidores geo-redundantes na região geo-emparelhada. Com a região primária para baixo ainda se pode restaurar o servidor de origem para a região geo-emparelhada, desativando a opção de geo-redundância nas definições do Compute + Armazenamento Configure Server na experiência do portal de restauração e restauro como um servidor localmente redundante para garantir a continuidade do negócio.

Executar tarefas pós-restauro

Após uma restauração a partir do último ponto de restauração ou mecanismo de recuperação de pontos de restauração personalizado , deve executar as seguintes tarefas para que os seus utilizadores e aplicações voltem a funcionar:

  • Se o novo servidor pretende substituir o servidor original, redirecione clientes e aplicações de clientes para o novo servidor.
  • Certifique-se de que existem regras adequadas de firewall ao nível do servidor e de rede virtual para que os utilizadores se conectem.
  • Certifique-se de que estão em vigor os logins adequados e as permissões de nível de base de dados.
  • Configure alertas, conforme adequado.

Perguntas frequentes (Perguntas Frequentes)

  • Como devo proceder para o meu servidor? Por padrão, Base de Dados do Azure para MySQL permite cópias de segurança automatizadas de todo o seu servidor (abrangendo todas as bases de dados criadas) com um período de retenção de 7 dias predefinido. A única maneira de fazer uma cópia de segurança manualmente é usando ferramentas comunitárias como o mysqldump, como documentado aqui ou o mydumper, como documentado aqui. Se você deseja fazer backup Base de Dados do Azure para MySQL para um armazenamento Blob, consulte o nosso blog da comunidade tecnológica Backup Base de Dados do Azure para MySQL para um Armazenamento Blob.

  • Posso configurar cópias de segurança automáticas para serem mantidas a longo prazo? Não, atualmente só suportamos um máximo de 35 dias de retenção automática de backup. Pode pegar em cópias de segurança manuais e usá-la para requisitos de retenção a longo prazo.

  • Quais são as janelas de reserva do meu servidor? Posso personalizá-lo? A primeira cópia de segurança instantânea é programada imediatamente após a criação de um servidor. As cópias de segurança instantâneas são tomadas diariamente uma vez. As cópias de segurança de registo de transações ocorrem a cada cinco minutos. Backup janelas são geridas inerentemente pela Azure e não podem ser personalizadas.

  • As minhas cópias de segurança são encriptadas? Todos os dados, cópias de segurança e ficheiros temporários da Base de Dados do Azure para MySQL criados durante a execução da consulta são encriptados com a encriptação AES 256-bit. A encriptação do armazenamento está sempre ativada e não pode ser desativada.

  • Posso restaurar uma única/poucas bases de dados? Restaurar uma ou única/poucas bases de dados ou tabelas não é suportado. Caso pretenda restaurar bases de dados específicas, efetue um Ponto de Restauração do Tempo e, em seguida, extraia a tabela ou a base de dados necessárias.

  • O meu servidor está disponível durante a janela de reserva? Sim. As cópias de segurança são operações online e são baseadas em instantâneos. A operação instantânea demora apenas alguns segundos e não interfere com as cargas de trabalho de produção que garantem uma elevada disponibilidade do servidor.

  • Ao configurar a janela de manutenção do servidor, temos de prestar contas à janela de reserva? Não, as cópias de segurança são ativadas internamente como parte do serviço gerido e não têm qualquer influência na Janela de Manutenção Gerida.

  • Onde estão os meus reforços automatizados e como é que eu consigo a retenção deles? A Base de Dados do Azure para MySQL cria automaticamente cópias de segurança do servidor e guarda-as no armazenamento localmente redundante ou georredundante configurado pelo utilizador. Estes ficheiros de cópia de segurança não podem ser exportados. O período de retenção de backup predefinido é de sete dias. Pode configurar opcionalmente a cópia de segurança da base de dados de 1 a 35 dias.

  • Como posso validar os meus reforços? A melhor forma de validar a disponibilidade de cópias de segurança concluídas com sucesso é visualizar as cópias de segurança automatizadas completas tomadas dentro do período de retenção na lâmina Backup e Restaurar. Se uma cópia de segurança falhar, não será listada na lista de backups disponíveis e o nosso serviço de backup tentará a cada 20 minutos fazer uma cópia de segurança até que seja feita uma cópia de segurança bem sucedida. Estas falhas de backup devem-se a pesadas cargas de produção transacional no servidor.

  • Onde posso ver o uso de reserva? Na portal do Azure, no separador Monitor - Métricas, pode encontrar a métrica Backup Armazenamento Usada que pode ajudá-lo a monitorizar o uso total de 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 são eliminadas e não podem ser recuperadas. Para proteger os recursos do servidor, a implantação de posts, de eliminação acidental ou alterações inesperadas, os administradores podem alavancar os bloqueios de gestão.

  • Como vou ser cobrado e cobrado pelo meu uso de reforços? O servidor flexível fornece até 100% do armazenamento do servidor a provisionado como armazenamento de backup sem custos adicionais. Qualquer armazenamento adicional de backup utilizado é cobrado em GB por mês de acordo com o preço modelo. Backup a faturação de armazenamento também é regida pelo período de retenção de backup selecionado e a opção de redundância de backup escolhida para além da atividade transacional no servidor que impacta o armazenamento total de backup utilizado diretamente.

  • Como são retidas cópias de segurança para servidores parados? Não são realizadas cópias de segurança novas para servidores parados. Todas as cópias de segurança mais antigas (dentro da janela de retenção) no momento de parar o servidor são mantidas até que o servidor seja reiniciado, que a retenção de backup para o servidor ativo é regida pela sua janela de retenção de backup.

  • Como vou ser cobrado por cópias de segurança para um servidor parado? Enquanto a sua instância do servidor é interrompida, é cobrado para armazenamento provisionado (incluindo IOPS Provisioned) e armazenamento de cópia de segurança (cópias de segurança armazenadas dentro da sua janela de retenção especificada). O armazenamento gratuito de backup está limitado ao tamanho da sua base de dados a provisionada e aplica-se apenas a servidores ativos.

  • Como devo proceder para restaurar o meu servidor? portal do Azure suporta o Point In Time Restore (para todos os servidores) permitindo que os utilizadores restaurá o ponto de restauro mais recente ou personalizado. Para restaurar manualmente o seu servidor a partir das cópias de segurança tomadas pelo mysqldump/myDumper leia Restaurar a sua base de dados usando o 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 das bases de dados. Como parte do processo de recuperação, a base de dados precisa de ser hidratada a partir da última cópia de segurança física e, por conseguinte, o tempo de recuperação será proporcional ao tamanho da base de dados.
    • A parte ativa da atividade de transação que precisa de ser reproduzida para recuperar. A recuperação pode demorar mais tempo dependendo da atividade de transação adicional 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 alvo
    • A presença da chave primária nas tabelas da base de dados. Para uma recuperação mais rápida, considere adicionar a chave primária para todas as tabelas da sua base de dados.

Passos seguintes