configurar backup MariaDB Docker com rsync e integridade é criar uma rotina que exporta o banco de dentro do container, valida se o dump é utilizável e sincroniza o arquivo para outro destino com rsync. Para automatizar esse backup com segurança operacional, siga estes passos:
- Identifique o nome do container MariaDB e o banco que será exportado.
- Crie um diretório local exclusivo para dumps e logs do backup.
- Monte um script com mariadb-dump, validação de arquivo e checksum.
- Teste a restauração em um container temporário antes de confiar no backup.
- Use rsync para enviar o dump validado para um destino remoto.
- Agende a execução no cron e acompanhe os logs após cada rodada.
Pré-requisitos para automação de backup MariaDB em Docker
Backup automatizado de MariaDB em Docker depende de acesso ao host onde o container roda, permissões para executar comandos Docker e um destino de cópia que aceite rsync. Antes de escrever o script, confirme se você consegue acessar o servidor por SSH, listar containers, executar comandos dentro do container MariaDB e gravar arquivos em um diretório de backup local.
- Acesso SSH ao host Linux que executa o Docker. Se precisar revisar o acesso, veja Acessando servidores VPS Linux da AviraHost.
- Docker instalado e container MariaDB em execução — seja via docker run direto ou via docker-compose.
- MariaDB 11.8 ou superior no container, quando aplicável ao seu ambiente atual. Verifique a versão mais recente em hub.docker.com/_/mariadb antes de fixar uma tag em produção.
- Cliente rsync instalado no host Linux.
- Usuário com permissão para executar docker exec e gravar em /var/backups ou caminho equivalente.
- Destino remoto acessível por SSH, como usuario@servidor:/caminho/backup.
- Senha do MariaDB disponível como variável de ambiente do container, arquivo de credenciais ou outro método seguro já usado pela sua aplicação.
O exemplo abaixo usa um container chamado mariadb, banco appdb e imagem mariadb:11.8 para o teste de restauração. Ajuste esses nomes antes de rodar em produção. Se você utiliza docker-compose, o nome do container será formado pelo prefixo do projeto mais o nome do serviço definido no arquivo compose.
docker ps
docker exec mariadb mariadb --version
rsync --versionOutput esperado:
lista de containers incluindo mariadb em execução
cliente MariaDB exibindo versão compatível
rsync exibindo versão instaladaPreparar diretórios e confirmar o container MariaDB
Dump do MariaDB em container Docker deve ser salvo fora do container, porque o objetivo é ter um arquivo independente do volume em uso. Ao rodar este comando, você verá se o nome do container está correto e se o host consegue executar comandos dentro dele. Essa etapa evita um erro comum: criar um cron funcional no papel, mas apontando para um container inexistente ou com nome diferente.
- Liste os containers ativos.
- Confirme o nome exato do container MariaDB.
- Teste uma consulta simples dentro do container.
- Crie o diretório local de backup.
- Defina permissões restritas para reduzir exposição dos dumps.
docker ps
docker exec mariadb mariadb -uroot -p"$MARIADB_ROOT_PASSWORD" -e "SELECT 1;"
sudo mkdir -p /var/backups/mariadb-docker
sudo chmod 700 /var/backups/mariadb-docker
sudo touch /var/log/backup-mariadb-docker.log
sudo chmod 600 /var/log/backup-mariadb-docker.logOutput esperado:
container mariadb aparece como ativo
SELECT 1 retorna uma linha com valor 1
comandos de mkdir, chmod e touch não exibem erro em caso de sucessoSe o comando com MARIADB_ROOT_PASSWORD falhar, não continue para o agendamento. Primeiro valide como sua senha é fornecida ao container. Em stacks docker-compose, é comum a senha existir como variável de ambiente definida no arquivo docker-compose.yml ou em um arquivo .env. Ambientes mais rígidos podem usar arquivos de segredo ou outro usuário de backup dedicado. O ponto técnico é o mesmo: o script precisa conseguir executar o dump sem interação manual.
Criar o script de backup MariaDB em container Docker
Script rsync para backup de banco MariaDB precisa falhar cedo quando algo dá errado. Por isso, o exemplo usa set -euo pipefail, grava logs, testa se o dump não ficou vazio, cria checksum e só sincroniza depois da validação básica. O dump lógico é gerado com mariadb-dump dentro do container e redirecionado para um arquivo no host.
Atenção: o script abaixo inclui remoção de dumps locais antigos com find e delete. Ajuste o período de retenção antes de usar, porque essa parte apaga arquivos locais que correspondem ao padrão configurado. A política de retenção padrão no exemplo é de 7 dias; adapte conforme sua necessidade de armazenamento e conformidade.
sudo tee /usr/local/sbin/backup-mariadb-docker.sh >/dev/null <<'EOF'
#!/usr/bin/env bash
set -euo pipefail
CONTAINER="mariadb"
DATABASE="appdb"
BACKUP_DIR="/var/backups/mariadb-docker"
REMOTE="[email protected]:/srv/backups/mariadb"
LOG="/var/log/backup-mariadb-docker.log"
DATE=$(date +%F-%H%M%S)
DUMP="$BACKUP_DIR/$DATABASE-$DATE.sql"
mkdir -p "$BACKUP_DIR"
echo "$(date) iniciando backup do banco $DATABASE" >> "$LOG"
docker exec "$CONTAINER" sh -c "mariadb-dump -uroot -p\"\$MARIADB_ROOT_PASSWORD\" --single-transaction --routines --events --databases $DATABASE" > "$DUMP"
test -s "$DUMP"
head -n 20 "$DUMP" | grep -E "MariaDB dump|Host|Database" >/dev/null
docker run -d --rm --name mariadb-restore-check -e MARIADB_ROOT_PASSWORD=checkpass mariadb:11.8 >/dev/null
sleep 12
docker exec -i mariadb-restore-check mariadb -uroot -pcheckpass < "$DUMP" >/dev/null
docker stop mariadb-restore-check >/dev/null
sha256sum "$DUMP" > "$DUMP.sha256"
rsync -av --partial --checksum "$DUMP" "$DUMP.sha256" "$REMOTE/"
find "$BACKUP_DIR" -type f -name "*.sql" -mtime +7 -delete
find "$BACKUP_DIR" -type f -name "*.sha256" -mtime +7 -delete
echo "$(date) backup concluido com sucesso $DUMP" >> "$LOG"
EOF
sudo chmod 700 /usr/local/sbin/backup-mariadb-docker.shOutput esperado:
sem saída em caso de sucesso na criação do arquivo
script salvo em /usr/local/sbin/backup-mariadb-docker.sh
permissão de execução aplicada apenas ao proprietárioAntes de executar, edite CONTAINER, DATABASE e REMOTE. Se o destino remoto ainda não aceitar conexão por chave SSH, o rsync poderá pedir senha ou falhar no cron. Em produção, prefira uma chave SSH restrita ao destino de backup e valide o login manualmente antes de automatizar.
Validar integridade do dump e testar restauração temporária
Verificação de integridade de backup MariaDB não deve se limitar a conferir se o arquivo existe. Um dump pode existir, ter tamanho maior que zero e ainda assim não restaurar por erro de permissão, senha, versão incompatível ou exportação interrompida. Por isso, o script testa três camadas: arquivo não vazio, cabeçalho reconhecível e restauração em um container temporário MariaDB.
- Execute o script manualmente antes de colocar no cron.
- Confira o log gerado no host.
- Verifique se o arquivo .sql e o .sha256 foram criados.
- Confirme se o container temporário foi encerrado após o teste.
sudo /usr/local/sbin/backup-mariadb-docker.sh
sudo tail -n 20 /var/log/backup-mariadb-docker.log
sudo ls -lh /var/backups/mariadb-docker
docker ps -a | grep mariadb-restore-check || trueOutput esperado:
log com mensagem de inicio e conclusao do backup
arquivo .sql criado com tamanho maior que zero
arquivo .sha256 criado ao lado do dump
nenhum container mariadb-restore-check permanece em execuçãoAo rodar este teste, você verá o ponto exato de falha caso algo esteja incorreto. Se o dump falhar, o script para antes do rsync. Se o arquivo estiver vazio, o comando test -s interrompe a rotina. Se a restauração temporária falhar, o backup não é tratado como confiável. Essa abordagem reduz o risco de descobrir apenas na emergência que o backup sincronizado não podia ser restaurado.
Sincronizar backup MariaDB com rsync e agendar no cron
Backup MariaDB com rsync e cron funciona melhor quando o rsync copia somente arquivos já validados. O rsync não substitui o dump nem garante consistência do banco por conta própria; ele apenas transporta os arquivos gerados. Por isso, a sequência correta é exportar, validar, calcular checksum e então sincronizar.
Teste primeiro a conexão com o destino remoto. Use o mesmo usuário que será executado pelo cron ou garanta que a chave SSH esteja disponível para esse usuário. Se o acesso SSH for instável, revise o diagnóstico em Como solucionar problemas de acesso SSH no VPS Linux: Guia Completo.
ssh [email protected] "mkdir -p /srv/backups/mariadb && echo destino-ok"
rsync -av --dry-run /var/backups/mariadb-docker/ [email protected]:/srv/backups/mariadb/Output esperado:
destino-ok
lista de arquivos que seriam enviados pelo rsync sem copiar de fatoCom o teste remoto funcionando, agende o script. O exemplo abaixo roda todos os dias de madrugada. Use caminhos absolutos porque o ambiente do cron é menor que uma sessão SSH interativa.
sudo crontab -eOutput esperado:
editor do crontab aberto para inserir a linha de agendamento15 2 * * * /usr/local/sbin/backup-mariadb-docker.sh >> /var/log/backup-mariadb-docker.log 2>&1Output esperado:
cron salvo sem erro
proxima execução gravará mensagens em /var/log/backup-mariadb-docker.logDepois da primeira execução automática, não presuma que funcionou. Leia o log, confirme o arquivo no destino remoto e compare o checksum se necessário. Esse cuidado é especialmente importante porque cron não carrega as mesmas variáveis de ambiente de uma sessão interativa.
Restaurar backup MariaDB Docker com segurança
Restauração de dump MariaDB no Docker deve ser ensaiada fora do banco de produção sempre que possível. O objetivo do backup não é apenas criar arquivos, mas garantir que eles possam voltar para um MariaDB funcional. Para validação periódica, use um container temporário, restaure o dump e rode consultas simples no banco restaurado.
Atenção: restaurar um dump em um banco existente pode sobrescrever objetos, recriar tabelas ou alterar dados conforme o conteúdo exportado. Nunca rode a restauração diretamente no container de produção sem janela de manutenção, confirmação do arquivo correto e plano de rollback.
BACKUP_FILE="/var/backups/mariadb-docker/appdb-AAAA-MM-DD-HHMMSS.sql"
docker run -d --rm --name mariadb-restore-manual -e MARIADB_ROOT_PASSWORD=checkpass mariadb:11.8
sleep 12
docker exec -i mariadb-restore-manual mariadb -uroot -pcheckpass < "$BACKUP_FILE"
docker exec mariadb-restore-manual mariadb -uroot -pcheckpass -e "SHOW DATABASES;"
docker stop mariadb-restore-manualOutput esperado:
container temporário iniciado
dump importado sem erro
lista de bancos exibindo o banco restaurado
container temporário encerradoEsse teste manual é útil após mudanças de versão do MariaDB, troca de imagem Docker, alteração de credenciais ou reorganização de volumes. Se a restauração temporária falhar, trate como incidente de backup: corrija o script, gere novo dump e só então considere a rotina saudável.
Problemas comuns e como resolver
Sintoma: o dump MariaDB Docker fica vazio
Causa: o container informado no script pode estar incorreto, a senha do MariaDB pode não estar disponível dentro do container ou o usuário usado no dump não tem permissão para exportar o banco.
Solução: rode manualmente o comando docker exec com SELECT 1 e depois execute o mariadb-dump sem cron. Confirme o nome do container com docker ps, valide a variável de ambiente MARIADB_ROOT_PASSWORD e ajuste o usuário de backup se o root não for usado no seu ambiente.
Sintoma: o rsync funciona no terminal, mas falha no cron
Causa: o cron executa com ambiente reduzido, sem as mesmas variáveis, agente SSH ou caminhos carregados na sessão interativa.
Solução: use caminhos absolutos, configure chave SSH para o usuário que executa o cron e redirecione stdout e stderr para log. Teste o comando com sudo ou com o mesmo usuário do crontab antes de esperar a próxima execução.
Sintoma: a verificação de integridade falha no container temporário
Causa: o dump pode estar incompleto, pode conter instruções incompatíveis com a imagem usada no teste ou pode ter sido gerado sem rotinas e eventos necessários para o seu banco.
Solução: confira o log do script, gere novamente o dump com --routines e --events e teste com a mesma família de versão MariaDB usada em produção. Se o erro aparecer durante importação, leia a linha informada pelo cliente MariaDB e corrija a causa antes de sincronizar novos arquivos.
Sintoma: backups antigos não são removidos
Causa: o padrão do find pode não corresponder aos nomes reais dos arquivos ou o usuário do script pode não ter permissão para apagar no diretório de backup.
Solução: execute o find sem delete primeiro, valide a lista retornada e só depois mantenha a remoção automática. Ajuste mtime conforme sua política de retenção de backups e garanta que dumps e checksums sigam o mesmo padrão de nomenclatura.
Perguntas frequentes sobre backup automatizado de bancos em Docker
Como automatizar backup de MariaDB em Docker com rsync?
Para automatizar backup de MariaDB em Docker com rsync, crie um script bash que execute o dump dentro do container, salve o arquivo em um diretório local, valide o dump e sincronize o resultado para um destino remoto. Depois, agende o script no cron e registre logs para confirmar cada execução.
Como verificar se um backup MariaDB feito no Docker está íntegro?
A verificação de integridade deve confirmar se o dump foi gerado sem erro, se o arquivo não está vazio e se o conteúdo pode ser lido pelo cliente MariaDB. Em ambientes mais rigorosos, o ideal é testar a restauração em um container temporário antes de considerar o backup confiável.
É melhor copiar o volume do MariaDB ou fazer dump do banco no Docker?
Para backup lógico e portável, o dump do MariaDB costuma ser mais seguro do que copiar o volume em uso, porque registra a estrutura e os dados em um arquivo restaurável. Copiar o volume pode ser útil em alguns cenários, mas exige cuidado com consistência, estado do container e risco de arquivos parcialmente gravados.
Posso usar cron para agendar backup de MariaDB em container Docker?
Sim, o cron pode executar um script no host Linux que chama o Docker para gerar o dump dentro do container MariaDB. O ponto importante é usar caminhos absolutos, variáveis de ambiente bem definidas e logs, porque o ambiente do cron é mais limitado que uma sessão SSH interativa.
O rsync substitui o backup do MariaDB?
Não. O rsync apenas sincroniza arquivos entre diretórios ou servidores; ele não garante sozinho que o banco foi exportado de forma consistente. A prática correta é gerar primeiro um dump válido do MariaDB e só depois usar rsync para copiar esse arquivo para outro local como offsite backup.
Conclusão
Uma rotina confiável para MariaDB em Docker precisa combinar dump lógico, validação e cópia remota. O rsync é importante para transportar os arquivos, mas a confiança vem do teste de integridade antes da sincronização.
- Execute o script manualmente e corrija qualquer falha antes de ativar o cron.
- Mantenha logs, checksums e política de retenção de backups compatível com a necessidade do seu banco.
- Teste restauração em container temporário após mudanças de versão, senha, imagem ou estrutura do banco.
Precisa de apoio para estruturar backups em ambientes Docker?
A AviraHost oferece infraestrutura VPS para hospedar aplicações Docker com controle de acesso, armazenamento e rotina de administração alinhada ao seu projeto. Se você quer estruturar backups com mais previsibilidade, escolha um ambiente adequado para containers e bancos de dados.
Conheça os planos de Servidor VPS da AviraHost
