Backup e migração de volumes Docker: 3 métodos na prática

No ano passado, durante as promoções de novembro, a empresa migrou os servidores da Alibaba Cloud para a Tencent Cloud. Quando meu chefe perguntou o que faríamos com os dados do banco que rodava no Docker, percebemos o tamanho do problema: o contêiner PostgreSQL estava ativo havia mais de seis meses, guardava alguns GB de dados de usuários e nunca tinha passado por um backup.

Naquela noite, procurei freneticamente por métodos de backup para Docker e li inúmeros tutoriais. docker cp, empacotamento com tar, ferramentas como docker-volume-backup… quanto mais eu lia, mais confuso ficava. Todos os métodos pareciam corretos, mas eu não sabia qual escolher nem tinha coragem de testá-los em produção. Meu maior receio era o banco gravar dados no meio do backup e o arquivo resultante ficar corrompido.

Depois de alguns tropeços, entendi melhor o caminho. Fazer backup de dados no Docker não é tão complicado; o essencial é saber em qual cenário cada método funciona melhor. A seguir, explico três métodos comuns, quando usar cada um, como executá-los e quais armadilhas evitar. Assim, você poderá montar um backup confiável para a sua própria aplicação Docker.

Por que o backup de dados no Docker é importante

Como funciona o armazenamento de dados no Docker

Quem está começando com Docker muitas vezes não presta muita atenção ao armazenamento. O contêiner inicia, os dados ficam lá e tudo parece certo. Mas há um detalhe fácil de ignorar: o contêiner em si é temporário.

Se você gravar os dados diretamente no contêiner, poderá perdê-los quando ele for reiniciado ou quando a imagem for atualizada. Por isso, o Docker oferece duas formas de persistência:

• Volume: área de armazenamento gerenciada pelo próprio Docker, com dados salvos em /var/lib/docker/volumes/. É a opção recomendada oficialmente, pois o Docker ajuda a gerenciar permissões e ciclo de vida.
• Bind mount: montagem direta de um diretório do host dentro do contêiner. Se você montar /home/user/data em /data, por exemplo, os arquivos ficam em um local conhecido e podem ser copiados com cp.

Para decidir o que precisa de backup, recomendo incluir:

• Arquivos de banco de dados — diretórios de dados do PostgreSQL, MySQL e MongoDB;
• Arquivos enviados pelos usuários — avatares, documentos e imagens;
• Arquivos de configuração — embora boa parte possa ser recriada, é mais seguro preservar configurações sensíveis;
• Arquivos de log — quando for necessário analisar o histórico.

Situações comuns de perda de dados

Os incidentes de perda de dados que já vi ou conheço costumam se encaixar em alguns cenários.

Excluir um contêiner por engano. É o mais comum. Você pretende remover um contêiner de teste, mas executa docker rm -v e apaga também o volume. O culpado é o parâmetro -v, que remove os volumes anônimos associados. Na primeira vez que usei esse comando, eu também não sabia disso e perdi o banco do ambiente de teste.

Falha de disco. O servidor está em operação há dois ou três anos e, de repente, o SMART acusa um problema. Você corre para trocar o disco. Talvez ainda consiga ler os dados, mas o susto é grande. Com um backup regular, mesmo que o disco pare, basta trocar a unidade e restaurar os dados para o serviço voltar em algumas dezenas de minutos.

Migração de servidor. Foi o caso que contei no início. Seja para mudar de datacenter ou de provedor de nuvem, seja para levar o serviço de um VPS ao Kubernetes, transferir os dados é um problema importante. Sem backup, resta torcer para a conexão não cair no meio do scp.

Há também um caso real: no ano passado, o contêiner de banco de dados da startup de um amigo caiu por um motivo desconhecido. Depois da reinicialização, descobriram que os dados do volume estavam corrompidos e o PostgreSQL não iniciava. O backup mais recente que encontraram era de dois meses antes. Dois meses de pedidos foram perdidos, causando à empresa um prejuízo de centenas de milhares.

Não conto isso para assustar, mas para reforçar que fazer backups periódicos é realmente importante. Depois que os dados somem, nenhuma habilidade técnica consegue recuperá-los do nada.

Três métodos de backup explicados

Método 1: backup com tar (⭐⭐⭐⭐⭐ recomendado)

É o método que mais uso e serve para vários cenários. A ideia central é simples: montar o volume em um contêiner temporário e empacotar os dados com tar.

Comando de backup:

docker run --rm \
  -v postgres_data:/data:ro \
  -v $(pwd):/backup \
  ubuntu tar czf /backup/postgres-backup-20251217.tar.gz -C /data .

Entenda cada parte do comando:

• --rm: remove automaticamente o contêiner ao terminar, sem deixar resíduos;
• -v postgres_data:/data:ro: monta o volume postgres_data em /data; :ro indica acesso somente leitura e reduz o risco de alterações acidentais;
• -v $(pwd):/backup: monta o diretório atual em /backup, onde o arquivo será salvo;
• tar czf: c cria o arquivo, z usa compactação gzip e f define o nome;
• -C /data .: muda para /data e empacota todo o conteúdo; . representa todos os arquivos do diretório atual.

Comando de restauração:

docker run --rm \
  -v postgres_data:/data \
  -v $(pwd):/backup \
  ubuntu tar xzf /backup/postgres-backup-20251217.tar.gz -C /data

Aqui, x indica a extração; os demais parâmetros são semelhantes aos usados no backup.

Quando usar este método?

• Funciona com todos os tipos de volume e é a opção mais genérica;
• Quando for necessário compactar os dados para economizar espaço — a redução pode chegar a 30%–50%;
• Para transferir o backup a outro servidor ou serviço de armazenamento em nuvem.

Cuidados:

Na primeira vez que usei esse método, cometi um erro: fiz o backup de um contêiner MySQL em execução. O comando terminou com sucesso, mas, na restauração, o banco acusou tabelas corrompidas e não iniciou. Só depois entendi que se o banco estiver gravando durante o backup, a cópia poderá capturar um estado inconsistente.

O procedimento mais seguro é:

KiloClaw - OpenClaw gerenciado para empresas: orquestração de agentes IA e roteamento inteligente

Começar →Anúncio

1. Interromper as gravações, parando o contêiner ou bloqueando as tabelas;
2. Executar o backup;
3. Retomar as gravações.

Se não for possível parar o serviço, confirme ao menos que o banco usa journal ou WAL. Dessa forma, mesmo que ocorram gravações durante o backup, o próprio banco poderá se recuperar depois da restauração.

Exemplo prático: backup de dados do PostgreSQL

# 1. Pare o contêiner PostgreSQL, se possível
docker stop my-postgres

# 2. Faça backup do volume
docker run --rm \
  -v postgres_data:/data:ro \
  -v /backup:/backup \
  ubuntu tar czf /backup/pg-$(date +%Y%m%d-%H%M%S).tar.gz -C /data .

# 3. Valide o arquivo de backup
ls -lh /backup/pg-*.tar.gz

# 4. Reinicie o contêiner
docker start my-postgres

Gosto de colocar um timestamp no nome. Assim, basta olhar para saber quando o backup foi criado.

Método 2: comando docker cp (⭐⭐⭐)

Este método é mais direto: em vez de empacotar, ele copia os arquivos. É útil para fazer rapidamente o backup de alguns arquivos de configuração ou de um diretório pequeno.

Etapas do backup:

# 1. Crie um contêiner temporário associado ao volume
docker create -v nginx_config:/data --name temp_backup busybox

# 2. Copie os dados para o host
docker cp temp_backup:/data ./nginx-config-backup

# 3. Remova o contêiner temporário
docker rm temp_backup

Etapas da restauração:

# Suponha que a restauração será feita em um novo contêiner
docker cp ./nginx-config-backup/. my-nginx:/etc/nginx/

Quando usar este método?

• Para copiar apenas alguns arquivos de configuração;
• Quando os arquivos são pequenos, com algumas dezenas de MB;
• Quando você quer examinar o conteúdo sem precisar descompactar.

Desvantagens:

• Não oferece compactação, portanto arquivos grandes ocupam mais espaço;
• A transferência pode ser mais lenta que com tar;
• Pode não preservar perfeitamente todas as permissões e atributos especiais.

Exemplo prático: backup da configuração do Nginx

# Crie um contêiner temporário
docker create -v nginx_config:/config --name nginx_temp busybox

# Copie o arquivo de configuração
docker cp nginx_temp:/config/nginx.conf ./backup/

# Também é possível copiar o diretório inteiro
docker cp nginx_temp:/config/. ./backup/nginx-config/

# Limpe os recursos
docker rm nginx_temp

Costumo usar esse método para configurações. Antes de alterar o Nginx, por exemplo, faço uma cópia com docker cp. Se a mudança quebrar o serviço, consigo restaurar rapidamente.

Método 3: ferramenta docker-volume-backup (⭐⭐⭐⭐ melhor opção para automação)

Os dois métodos anteriores são manuais e servem bem para backups pontuais. Em produção, porém, é melhor ter backups automáticos em horários definidos. É aí que uma ferramenta dedicada ajuda.

Atualmente uso o offen/docker-volume-backup, uma solução de código aberto bastante popular em 2025. Seus principais recursos são:

• backups automáticos agendados por uma expressão cron;
• parada automática do contêiner antes do backup para preservar a consistência;
• vários destinos de armazenamento, como S3, Google Drive, SSH e WebDAV;
• remoção automática de backups antigos.

Exemplo de configuração do Docker Compose:

version: '3.8'

services:
  # Seu serviço de banco de dados
  postgres:
    image: postgres:15
    volumes:
      - db_data:/var/lib/postgresql/data
    labels:
      # Indica que este contêiner deve ser parado durante o backup
      - "docker-volume-backup.stop-during-backup=true"

  # Serviço de backup
  backup:
    image: offen/docker-volume-backup:latest
    environment:
      # Faça o backup todos os dias às 2h
      BACKUP_CRON_EXPRESSION: "0 2 * * *"
      # Nome do arquivo de backup
      BACKUP_FILENAME: "db-backup-%Y%m%d-%H%M%S.tar.gz"
      # Mantenha os backups dos últimos 7 dias
      BACKUP_RETENTION_DAYS: "7"
    volumes:
      # Volume que será copiado, em modo somente leitura
      - db_data:/backup/db_data:ro
      # Local em que os arquivos de backup serão salvos
      - ./backups:/archive
      # O socket do Docker precisa ser montado para que os contêineres possam ser parados
      - /var/run/docker.sock:/var/run/docker.sock:ro

volumes:
  db_data:

Fluxo de execução:

1. Todos os dias às 2h, o contêiner de backup inicia;
2. Ao detectar que o contêiner postgres tem o rótulo stop-during-backup, ele o interrompe automaticamente;
3. O volume db_data é empacotado com tar;
4. O arquivo de backup é salvo no diretório ./backups;
5. O contêiner postgres é iniciado novamente;
6. Os backups com mais de sete dias são removidos.

Quando usar este método?

• Em produção, quando backups automáticos e periódicos são necessários;
• Para enviar os backups a serviços de armazenamento em nuvem, como S3 ou GCS;
• Para gerenciar o backup de vários contêineres.

Cuidados:

Na primeira configuração, preste atenção às permissões. O contêiner de backup precisa conseguir ler /var/run/docker.sock; sem isso, ele não poderá parar outros contêineres.

Além disso, a ferramenta realmente interrompe o serviço por alguns segundos ou dezenas de segundos, dependendo do volume de dados. Se o serviço não puder parar, não use o rótulo stop-during-backup. Nesse caso, porém, será necessário aceitar o risco de obter um estado inconsistente.

Exemplo prático: backup automático do MongoDB

version: '3.8'

services:
  mongodb:
    image: mongo:7
    volumes:
      - mongo_data:/data/db
    labels:
      - "docker-volume-backup.stop-during-backup=true"

  backup:
    image: offen/docker-volume-backup:latest
    environment:
      BACKUP_CRON_EXPRESSION: "0 3 * * *"
      BACKUP_FILENAME: "mongo-%Y%m%d.tar.gz"
      BACKUP_RETENTION_DAYS: "14"
      # Faça backup no AWS S3
      AWS_S3_BUCKET_NAME: "my-backups"
      AWS_ACCESS_KEY_ID: "${AWS_KEY}"
      AWS_SECRET_ACCESS_KEY: "${AWS_SECRET}"
    volumes:
      - mongo_data:/backup/mongo_data:ro
      - /var/run/docker.sock:/var/run/docker.sock:ro

volumes:
  mongo_data:

Essa configuração faz o backup automático do MongoDB todos os dias às 3h e envia o arquivo ao S3, sem manter uma cópia local. Uso esse arranjo há mais de seis meses e ele tem sido estável.

Fluxo completo de migração dos dados

Etapas práticas para migrar um servidor

Depois de conhecer os métodos de backup, vejamos o fluxo completo de uma migração. No ano passado, participei de uma mudança da Alibaba Cloud para a Tencent Cloud, seguindo aproximadamente estas etapas.

1. Preparação — não pule esta etapa

Primeiro, faça um inventário do ambiente atual:

# Liste todos os contêineres
docker ps -a

# Liste todos os volumes
docker volume ls

# Exporte a configuração de cada contêiner; isto é importante
docker inspect my-postgres > postgres-config.json
docker inspect my-nginx > nginx-config.json

# Registre os arquivos docker-compose.yml e .env
cp docker-compose.yml docker-compose.backup.yml
cp .env .env.backup

É essencial guardar esses arquivos de configuração. Na minha primeira migração, esqueci de salvar as variáveis de ambiente. A senha do banco não correspondia no novo servidor, e perdi um bom tempo resolvendo o problema.

2. Backup

Pare todos os serviços e inicie o backup:

# Pare todos os contêineres
docker-compose down

# Faça backup de cada volume
docker run --rm \
  -v postgres_data:/data:ro \
  -v $(pwd)/backups:/backup \
  ubuntu tar czf /backup/postgres_data.tar.gz -C /data .

docker run --rm \
  -v nginx_config:/data:ro \
  -v $(pwd)/backups:/backup \
  ubuntu tar czf /backup/nginx_config.tar.gz -C /data .

# Valide os arquivos de backup
ls -lh backups/
md5sum backups/*.tar.gz > backups/checksums.txt

O md5sum é importante. Se a instabilidade da rede corromper um arquivo durante a transferência, você conseguirá detectar o problema.

3. Migração

Transfira os arquivos de backup para o novo servidor:

# Geralmente uso rsync, que permite retomar a transferência
rsync -avP --partial backups/ user@new-server:/tmp/backups/

# Ou use scp
scp -r backups/ user@new-server:/tmp/backups/

Se o arquivo for muito grande, com dezenas de GB, e a conexão não for estável, vale usar armazenamento de objetos na nuvem como intermediário. Envie primeiro para S3 ou OSS e depois baixe no servidor novo; tende a ser mais rápido e confiável.

Alibaba Cloud - Escolha dos desenvolvedores, 15% de desconto exclusivo em Lighthouse

Ganhar 15% off →Anúncio

Restauração no novo servidor:

# 1. Crie os volumes
docker volume create postgres_data
docker volume create nginx_config

# 2. Restaure os dados
docker run --rm \
  -v postgres_data:/data \
  -v /tmp/backups:/backup \
  ubuntu tar xzf /backup/postgres_data.tar.gz -C /data

docker run --rm \
  -v nginx_config:/data \
  -v /tmp/backups:/backup \
  ubuntu tar xzf /backup/nginx_config.tar.gz -C /data

# 3. Confira os dados restaurados
docker run --rm -v postgres_data:/data ubuntu ls -lh /data

# 4. Inicie os serviços
docker-compose up -d

4. Validação

Depois que os serviços iniciarem, não altere o tráfego imediatamente. Valide primeiro:

# Confira o estado dos contêineres
docker ps

# Veja os logs e confirme que não há erros
docker-compose logs -f

# Teste a conexão com o banco de dados
docker exec -it my-postgres psql -U postgres -c "SELECT COUNT(*) FROM users;"

# Compare os dados dos servidores antigo e novo
# Normalmente escrevo um script para comparar a quantidade de registros das tabelas principais

Somente depois de confirmar que tudo está correto, altere o DNS ou a configuração do balanceador de carga e direcione o tráfego ao novo servidor.

Um problema que enfrentei:

Na migração do ano passado, havia um volume muito grande, com 50 GB. A extração com docker run tar levou quase uma hora. Depois descobri que poderia criar o volume com docker volume create e extrair diretamente no host, em /var/lib/docker/volumes/volume_name/_data, o que é muito mais rápido. Esse método, no entanto, exige cuidado com as permissões.

Cuidados especiais ao fazer backup de bancos de dados

Backup de banco de dados é um assunto cheio de armadilhas e merece uma seção própria.

Por que um backup no nível de arquivos não é confiável o bastante?

Enquanto o banco está em execução, os dados são gravados o tempo todo. O InnoDB do MySQL tem redo log e undo log; o PostgreSQL usa WAL. Esses mecanismos preservam a consistência das transações. Se você empacotar os arquivos diretamente com tar, poderá copiar uma parte deles exatamente quando o banco estiver gravando uma transação, deixando o backup inconsistente.

O pior caso que já vi aconteceu quando alguém fez backup do MySQL durante uma transação grande, com a inserção em lote de milhões de registros. O arquivo parecia normal, mas o MySQL não iniciava depois da restauração e acusava corrupção no tablespace do InnoDB.

A forma correta: backup no nível da aplicação

PostgreSQL:

# Faça backup de um único banco de dados
docker exec my-postgres pg_dump -U postgres mydb > mydb-backup.sql

# Faça backup de todos os bancos de dados
docker exec my-postgres pg_dumpall -U postgres > all-dbs-backup.sql

# Restaure
docker exec -i my-postgres psql -U postgres mydb < mydb-backup.sql

MySQL:

# Faça o backup
docker exec my-mysql mysqldump -u root -p mydb > mydb-backup.sql

# Restaure
docker exec -i my-mysql mysql -u root -p mydb < mydb-backup.sql

MongoDB:

# Faça o backup
docker exec my-mongo mongodump --out=/backup
docker cp my-mongo:/backup ./mongo-backup

# Restaure
docker cp ./mongo-backup my-mongo:/backup
docker exec my-mongo mongorestore /backup

Estratégia com duas camadas de proteção:

Hoje faço backup no nível da aplicação + backup do volume.

• Backup no nível da aplicação, com pg_dump e ferramentas semelhantes: é o principal meio de restauração e preserva a consistência dos dados;
• Backup do volume, empacotado com tar: funciona como plano de recuperação de desastres. Se o backup no nível da aplicação falhar ou estiver corrompido, ainda há uma cópia dos arquivos que pode ser testada.

Essa estratégia ocupa mais espaço, mas é uma proteção importante. A empresa do meu amigo perdeu dados porque tinha apenas o backup do volume, que estava corrompido, e nunca havia criado um backup no nível da aplicação.

Boas práticas e armadilhas a evitar

Como definir uma estratégia de backup

Além de escolher o método, você precisa de uma estratégia coerente. Caso contrário, o backup poderá ser frequente demais e consumir recursos ou raro demais e deixar dados importantes desprotegidos.

Regra 3-2-1, considerada um princípio básico de backup no setor:

• 3 cópias: os dados originais e dois backups;
• 2 tipos de mídia: por exemplo, disco local e nuvem, ou dois discos diferentes;
• 1 cópia externa: ao menos um backup em outra localização geográfica, como proteção contra incêndios e terremotos.

Pode parecer complicado, mas não é tão difícil implementar. Minha estratégia é:

• manter no servidor local os backups diários dos últimos sete dias, como primeira cópia;
• manter no NAS os backups dos últimos 30 dias, em outra mídia;
• manter no S3 os backups mensais dos últimos três meses, em outra localização.

Frequência recomendada:

Padrão para os nomes dos arquivos:

Não subestime o nome. Uma nomenclatura confusa torna a restauração muito mais difícil. Uso este formato:

<nome-do-serviço>-<tipo-de-dado>-<AAAAMMDD>-<HHMMSS>.tar.gz

Exemplos:

myapp-postgres-20251217-020000.tar.gz
myapp-nginx-config-20251217-020000.tar.gz
myapp-uploads-20251217-020000.tar.gz

Ao ordenar os arquivos, eles ficam naturalmente em ordem cronológica, e o momento de cada backup fica claro.

Problemas comuns e soluções

Problema 1: a mensagem volume is in use aparece durante o backup

Esse erro normalmente não ocorre, porque um volume pode ser montado em mais de um contêiner. Se aparecer, as possíveis causas são:

• o contêiner mantém algum bloqueio de arquivo;
• há um problema de montagem no NFS ou em outro armazenamento de rede.

Solução:

Railway - Plataforma de deploy moderna, sem ops complexas, no ar em minutos

Começar agora →Anúncio

# Confira quais contêineres usam este volume
docker ps --filter volume=my_volume

# Se possível, pare esses contêineres
docker stop container_name

# Ou use o parâmetro --volumes-from
docker run --rm --volumes-from=my_container -v $(pwd):/backup ubuntu tar czf /backup/data.tar.gz -C /data .

Problema 2: as permissões dos arquivos ficam incorretas após a restauração

Também já enfrentei isso. Por padrão, o tar preserva as permissões, mas, em uma migração entre sistemas diferentes, como Ubuntu e CentOS, os valores de UID e GID podem não corresponder.

Sintoma: o contêiner não inicia e informa que não tem permissão para ler ou gravar determinados arquivos.

Solução:

# Defina o proprietário durante a restauração
docker run --rm -v my_volume:/data -v $(pwd):/backup ubuntu sh -c "tar xzf /backup/data.tar.gz -C /data && chown -R 999:999 /data"

# 999:999 é o UID do usuário postgres dentro do contêiner PostgreSQL
# O UID muda conforme a imagem; consulte a documentação ou use docker inspect

Problema 3: o arquivo de backup é grande demais e difícil de transferir

Certa vez, fiz backup de um banco MySQL de 50 GB. Mesmo compactado com gzip, o arquivo ainda tinha 30 GB. Transferi-lo pela internet pública era muito lento, e a conexão caía com frequência.

Soluções:

1. Use uma taxa de compactação maior: xz compacta de 20% a 30% mais que gzip, embora seja mais lento.

   tar cJf backup.tar.xz /data  # J indica a compactação xz

2. Divida o arquivo compactado em partes: útil para destinos com limite de tamanho por arquivo.

   tar czf - /data | split -b 1G - backup.tar.gz.
   # Para restaurar: cat backup.tar.gz.* | tar xzf -

3. Use backup incremental: copie apenas os arquivos alterados; isso exige ferramentas compatíveis, como rsync ou um software específico de backup.

Problema 4: o arquivo está corrompido no momento da restauração

É a pior situação: nada parece errado durante o backup, mas o arquivo está corrompido justamente quando você precisa dele.

Medidas preventivas:

# Calcule o checksum assim que o backup terminar
md5sum backup.tar.gz > backup.tar.gz.md5

# Depois da transferência, valide novamente no novo servidor
md5sum -c backup.tar.gz.md5

# Teste a restauração periodicamente; esta é a etapa mais importante
# Todo mês, restaure um backup em um ambiente de teste e confirme que ele funciona

Hoje tenho o hábito de tentar extrair os primeiros arquivos logo após cada backup. Isso ao menos confirma que o arquivo compactado está íntegro.

Automação e monitoramento

O backup manual pode ser confiável, mas as pessoas esquecem. Em produção, é indispensável automatizar.

Agende um script de backup com crontab:

# Crie o script de backup em /opt/scripts/backup-docker-volumes.sh
#!/bin/bash
DATE=$(date +%Y%m%d-%H%M%S)
BACKUP_DIR=/backup

# Faça backup do PostgreSQL
docker run --rm \
  -v postgres_data:/data:ro \
  -v $BACKUP_DIR:/backup \
  ubuntu tar czf /backup/postgres-$DATE.tar.gz -C /data .

# Faça backup da configuração do Nginx
docker run --rm \
  -v nginx_config:/data:ro \
  -v $BACKUP_DIR:/backup \
  ubuntu tar czf /backup/nginx-$DATE.tar.gz -C /data .

# Remova os backups com mais de 7 dias
find $BACKUP_DIR -name "*.tar.gz" -mtime +7 -delete

# Envie uma notificação, se necessário
echo "Backup concluído: $DATE" | mail -s "Relatório de backup do Docker" [email protected]

# Adicione ao crontab
crontab -e

# Execute todos os dias às 2h
0 2 * * * /opt/scripts/backup-docker-volumes.sh >> /var/log/docker-backup.log 2>&1

Monitoramento e alertas:

Automatizar não basta; também é preciso saber se o backup foi concluído. Faço o seguinte:

1. Registro de logs: cada backup registra horário, tamanho do arquivo e MD5;
2. Script de monitoramento: todos os dias, verifico se um novo arquivo de backup foi criado; caso contrário, gero um alerta;
3. Detecção de tamanho anormal: se o arquivo ficar repentinamente muito maior ou menor, com uma variação superior a 50% da média, talvez haja um problema.

Um script simples de monitoramento:

#!/bin/bash
BACKUP_DIR=/backup
EXPECTED_SIZE=100000000  # 100 MB; ajuste conforme o seu ambiente

LATEST_BACKUP=$(ls -t $BACKUP_DIR/postgres-*.tar.gz | head -1)
if [ -z "$LATEST_BACKUP" ]; then
  echo "ERRO: nenhum arquivo de backup foi encontrado!"
  exit 1
fi

# Confira se o arquivo de backup é de hoje
BACKUP_DATE=$(stat -c %Y "$LATEST_BACKUP")
TODAY=$(date +%s)
AGE=$((TODAY - BACKUP_DATE))

if [ $AGE -gt 86400 ]; then
  echo "ERRO: o backup mais recente tem mais de 24 horas!"
  exit 1
fi

# Confira o tamanho do arquivo
SIZE=$(stat -c %s "$LATEST_BACKUP")
if [ $SIZE -lt $(($EXPECTED_SIZE / 2)) ]; then
  echo "AVISO: o arquivo de backup é pequeno demais: $SIZE bytes"
  exit 1
fi

echo "Verificação concluída: $LATEST_BACKUP ($SIZE bytes)"

Esses scripts podem ser integrados ao seu sistema de monitoramento, como Prometheus ou Zabbix, ou simplesmente enviar avisos por e-mail ou WeCom.

Conclusão

Depois de tudo isso, voltamos à pergunta inicial: como fazer backup de dados no Docker?

A resposta é simples: não existe um método universal. O ponto principal é escolher de acordo com o seu cenário.

• Backup pontual e migração rápida: use tar; é genérico e confiável;
• Arquivos pequenos e de configuração: docker cp é suficiente, simples e direto;
• Produção e automação: use docker-volume-backup para reduzir o trabalho manual.

E o mais importante: faça backups e testes de restauração periodicamente. Não espere precisar recuperar os dados para descobrir que o arquivo está corrompido ou que nem sequer pode ser restaurado. Todo mês, uso um ambiente de teste para restaurar o backup mais recente e confirmar que o processo funciona.

Minha sugestão final é fazer hoje mesmo o primeiro backup da sua aplicação Docker. Não precisa ser complicado: experimente o método mais simples, com tar. Ter um arquivo de backup guardado traz bem mais tranquilidade.

Se você encontrar algum problema durante o backup ou conhecer um método melhor, compartilhe nos comentários. A troca de experiências ajuda todo mundo a evitar as mesmas armadilhas.