O backup de banco de dados é uma parte crítica do gerenciamento de banco de dados e deve ser cuidadosamente planejado. Agendar um backup não é suficiente, os dados de backup também precisam ser verificados quanto à consistência e integridade. Existem outras considerações, como criptografia e arquivamento externo. Um bom gerenciador de backup teria recursos que levassem em conta todas essas diferentes considerações.
Nesta postagem do blog, veremos como você pode agendar seus backups de banco de dados com o ClusterControl.
Backups de banco de dados usando ClusterControl
O ClusterControl oferece suporte a vários métodos de backup, dependendo do tipo de cluster, conforme resumido na tabela a seguir:
| Tipo de cluster | Método de backup compatível |
|---|---|
| MySQL (Replicação, Galera, Cluster NDB, Replicação de Grupo) |
|
| MongoDB (conjunto de réplicas, cluster fragmentado) |
|
| PostgreSQL (replicação de streaming) |
|
Ao agendar o backup com o ClusterControl, cada um dos métodos de backup é configurável com um conjunto de opções sobre como você deseja que o backup seja executado. Diferentes cargas de trabalho de banco de dados e estratégias de backup exigiriam suporte para diferentes recursos, por exemplo:
- Limitação de IOPS de disco
- Limitação de rede
- Bloqueios de backup
- Criptografia
- Compressão
- Período de retenção
- Verificação
O ClusterControl definirá automaticamente várias opções de backup, seguindo as melhores práticas do fornecedor de banco de dados específico. Por exemplo, se o nó do banco de dados de destino tiver o log binário ativado, ele anexará um sinalizador adicional, --master-data para incluir as coordenadas do log binário (nome do arquivo e posição) do servidor despejado. Se for um nó Galera e o método de backup for xtrabackup, o ClusterControl anexará um sinalizador adicional, --galera-info que contém o estado do nó local no momento do backup.
Planejando um backup
Antes de agendarmos qualquer backup, temos que planejar como deve ser a operação de backup. Responder às seguintes perguntas de exemplo seria útil antes de criar um agendamento de backup:
- Qual método de backup você deseja usar? Alguns métodos de backup não são bloqueantes, mas consomem muitos recursos. Entenda as compensações para não se surpreender com o comportamento do processo na produção.
- Com que frequência você deseja fazer backup de seus bancos de dados? A execução de um backup completo pode ser dolorosa se o intervalo de backup for muito curto. Você provavelmente precisa de uma combinação de backups completos e incrementais.
- Com que rapidez você deseja restaurar seus dados? O backup físico geralmente é muito mais rápido que o backup lógico em termos de tempo de restauração completo. Por outro lado, o backup lógico é geralmente mais rápido para restauração parcial.
- Qual é o tamanho do seu tamanho de dados? Em alguns casos, o backup lógico não é uma boa opção para bancos de dados enormes, e o backup binário é o único caminho a seguir.
- Quanto espaço livre você tem para armazenar seu backup? Backups tendem a consumir muito espaço. Decida se a compactação é necessária e o nível de compactação que você pode pagar. Uma melhor compactação requer maior uso da CPU.
- E se o servidor de backup estiver inativo durante o backup? Deve fazer failover do backup para outro host disponível? Ignorar um backup devido a uma janela de manutenção geralmente não é uma boa ideia.
- Como garantir a integridade do backup criado? Lembre-se, um backup não é um backup se não for restaurável.
- Você confia no armazenamento de backup? A criptografia pode ser uma boa ideia para proteger seus dados.
Geralmente, respondendo a essas perguntas, podemos criar uma estratégia de backup apropriada. A lista de perguntas pode ser maior dependendo da sua política de backup e restauração.
Cobrimos este capítulo em detalhes em nosso whitepaper, The DevOps Guide to Database Backups for MySQL and MariaDB.
Agendando um Backup
Com o ClusterControl, o agendamento é bastante simples. Vá direto para Backup -> Criar Backup -> Agendar Backup e você verá a seguinte caixa de diálogo:
Dependendo do tipo de cluster, as opções podem ser diferentes, conforme mostrado nas capturas de tela a seguir para PostgreSQL e MongoDB:
PostgreSQL 
MongoDB A maioria das opções são autoexplicativas e são abordadas em detalhes no Guia do usuário. Uma vez que o agendamento é criado, você pode editar os backups de configuração, habilitar/desabilitar o backup ou excluir o agendamento na aba "Backups Agendados":
Observe que ao agendar o backup com o ClusterControl, todos os horários devem ser agendados no fuso horário UTC do servidor ClusterControl. A razão por trás disso é eliminar a confusão do tempo de execução do backup. Ao trabalhar com um cluster, os servidores de banco de dados podem ser distribuídos em diferentes fusos horários e diferentes áreas geográficas. O uso de um fuso horário de referência para gerenciar todos eles garantirá que os backups sejam sempre executados no horário correto.
Você pode monitorar o progresso de um backup olhando para Atividade -> Trabalhos quando chegar a hora. Se o trabalho de backup falhar, você verá o erro imediatamente:
O log acima também pode ser acessado na guia Backup em cada entrada de backup:
Verificações e verificações pós-backup
Depois que o trabalho de backup for concluído, isso não significa que sua responsabilidade acabou. Há algumas coisas que precisam ser seguidas. O mais importante é o estado do backup criado. O ClusterControl fornece notificações por e-mail e o notificará sobre o status. Este serviço de notificação é, obviamente, configurável com base na gravidade em Configurações -> Configurações gerais -> Configurações de notificações por email -> Backup:
Entrega significa que o ClusterControl enviará uma notificação por e-mail imediatamente após um alarme para este componente ser acionado. Você também pode configurá-lo como Ignore, ou Digest, onde o ClusterControl envia um resumo diário dos alarmes acionados.
Se o backup for criado com sucesso, é altamente recomendável verificar se o backup pode ser restaurado. Você pode usar o recurso de verificação de backup clicando no botão "Restaurar" do ID de backup escolhido e serão apresentadas duas opções de restauração:
"Restaurar e verificar em host autônomo" requer um host separado, que ainda não faz parte da configuração do banco de dados. O ClusterControl primeiro implantará uma instância MySQL no host de destino, iniciará o serviço, copiará o backup do repositório de backup e iniciará a restauração. Uma vez feito isso, você pode ter a opção de desligar o servidor após a restauração ou deixá-lo em execução para que você possa conduzir uma investigação mais aprofundada no servidor.
A limpeza também é importante para manter apenas os backups úteis em seu armazenamento. Assim, configure a retenção de backup conforme necessário. Por padrão, o ClusterControl limpa os backups com mais de 30 dias. Você também pode personalizar cada um dos agendamentos de backup com diferentes períodos de retenção.
Se o armazenamento de backup estiver se aproximando de algum limite de espaço ou você quiser arquivar seu backup fora de jogo, você pode optar por excluir manualmente o arquivo clicando no ícone da lixeira ou enviá-lo para a nuvem, conforme destacado abaixo:
No momento da escrita, o AWS S3 e o GCP Cloud Storage são compatíveis. As credenciais de nuvem devem ser pré-configuradas em Menu Lateral -> Integrações -> Provedores de Nuvem.
É isso, pessoal. Boa aglomeração!
