Backup de Volumes Docker em VPS: Guia Prático de Persistência

Volumes Docker são o ponto onde a abstração de container encontra a realidade do disco. Container é descartável — você reconstrói a partir da imagem em minutos. Volume é onde mora o estado real: banco de dados, uploads de usuários, configurações persistentes. Perder um volume é perder dados de produção.

Apesar disso, backup de volumes é a parte mais negligenciada do stack Docker. A maioria das VPS rodando aplicações containerizadas não tem rotina de backup configurada, apenas a falsa segurança de que “está tudo num container”. Quando o disco falha ou alguém roda docker volume prune distraído, a perda é definitiva.

Este tutorial mostra estratégias práticas pra fazer backup de volumes Docker em VPS Linux, cobrindo dados estáticos, bancos de dados, e automação com cron. Tempo estimado de execução: 25-40 minutos pra configurar o primeiro backup e validar a restauração.

Pré-requisitos

Confirme a versão do Docker e liste seus volumes antes de começar:

docker --version
docker volume ls

Identificando volumes e containers afetados

Antes de fazer backup, mapeie quais containers usam cada volume. Backup cego sem entender as dependências causa inconsistência — você pode pegar o arquivo de banco no meio de uma transação se o container estiver gravando.

docker volume ls --format '{{.Name}}'

docker ps -a --filter volume=nome_do_volume --format '{{.Names}}: {{.Image}}'

docker volume inspect nome_do_volume

sudo du -sh /var/lib/docker/volumes/nome_do_volume/_data

Backup de dados estáticos com tar

Dados estáticos — uploads de usuário, configs, assets — podem ser copiados com o container rodando. O risco de inconsistência é baixo porque escritas atômicas (mv, rename) preservam o estado anterior até a operação completar.

A estratégia padrão usa um container temporário Alpine com o volume montado em modo somente-leitura, criando o tarball pra um diretório do host.

sudo mkdir -p /var/backups/docker-volumes
sudo chmod 700 /var/backups/docker-volumes

docker run --rm \
  -v nome_do_volume:/source:ro \
  -v /var/backups/docker-volumes:/backup \
  alpine \
  tar czf /backup/volume-$(date +%Y%m%d-%H%M%S).tar.gz -C /source .

Backup consistente de bancos de dados

Bancos de dados são o caso mais delicado. Copiar os arquivos binários (datadir do MySQL, base/ do PostgreSQL) com o engine rodando resulta em backup corrompido — escritas em andamento, WAL não-flushed, índices inconsistentes. A solução é usar o dump nativo do engine.

docker exec nome_container_mysql \
  sh -c 'mysqldump --single-transaction --quick \
    -u root -p"$MYSQL_ROOT_PASSWORD" --all-databases' \
  | gzip > /var/backups/docker-volumes/mysql-$(date +%Y%m%d-%H%M%S).sql.gz

docker exec nome_container_pg \
  pg_dumpall -U postgres \
  | gzip > /var/backups/docker-volumes/postgres-$(date +%Y%m%d-%H%M%S).sql.gz

docker exec nome_container_mongo \
  mongodump --archive --gzip \
  > /var/backups/docker-volumes/mongo-$(date +%Y%m%d-%H%M%S).archive.gz

Automação com cron

Backup manual não escala — você esquece, ou faz só quando lembra (geralmente quando precisa restaurar). Cron resolve isso. A receita abaixo cria um script encapsulando a rotina e agenda execução diária.

#!/bin/bash
set -euo pipefail

BACKUP_DIR=/var/backups/docker-volumes
TIMESTAMP=$(date +%Y%m%d-%H%M%S)
RETENTION_DAYS=14

# Backup MySQL
docker exec mysql_container \
  sh -c 'mysqldump --single-transaction --quick \
    -u root -p"$MYSQL_ROOT_PASSWORD" --all-databases' \
  | gzip > "$BACKUP_DIR/mysql-$TIMESTAMP.sql.gz"

# Backup volume estatico
docker run --rm \
  -v uploads_volume:/source:ro \
  -v "$BACKUP_DIR":/backup \
  alpine \
  tar czf "/backup/uploads-$TIMESTAMP.tar.gz" -C /source .

# Limpa backups antigos
find "$BACKUP_DIR" -name "*.gz" -mtime +$RETENTION_DAYS -delete

sudo chmod 700 /usr/local/bin/docker-backup.sh
sudo crontab -e

0 3 * * * /usr/local/bin/docker-backup.sh >> /var/log/docker-backup.log 2>&1

Verificação e restauração

Backup que nunca foi testado não é backup — é arquivo. Valide a restauração periodicamente, idealmente em VPS de staging.

Pra restaurar um volume de dados estáticos:

# Cria volume vazio
docker volume create uploads_restored

# Restaura conteudo
docker run --rm \
  -v uploads_restored:/target \
  -v /var/backups/docker-volumes:/backup \
  alpine \
  sh -c 'cd /target && tar xzf /backup/uploads-20260529-030000.tar.gz'

Pra restaurar MySQL:

gunzip -c /var/backups/docker-volumes/mysql-20260529-030000.sql.gz \
  | docker exec -i mysql_container mysql -u root -p"$MYSQL_ROOT_PASSWORD"

Após restauração, valide integridade — pra MySQL, rode CHECK TABLE nas tabelas principais; pra dados de aplicação, suba um container apontando pro volume restaurado e verifique funcionalidade.

Resolução de problemas

”Cannot create container: volume in use”

Aparece quando você tenta deletar ou renomear um volume montado em container ativo. Pare o container primeiro com docker stop antes de manipular o volume. Backup com :ro monta o volume em paralelo sem conflito.

Tarball corrompido durante restauração

Sintoma: tar: Unexpected EOF in archive. Causa comum é disco cheio durante backup — o arquivo foi truncado. Sempre monitore espaço livre (df -h) antes de rodar backup, e adicione verificação no script: tar tzf arquivo.tar.gz > /dev/null && echo OK.

Backup lento mesmo em SSD

Verifique se está sendo escrito no mesmo disco do volume original — competição de I/O reduz throughput pela metade. Backup pra disco separado (block storage adicional ou rede) acelera significativamente. Em VPS Hostini, você pode adicionar volume block separado pelo painel pra dedicar à zona de backup.

Próximos passos

Com backup configurado e validado, considere os próximos níveis de maturidade: implementar backup incremental com restic ou borg pra volumes grandes (reduz tempo e espaço em ~80%), configurar alertas no script pra notificar falha via webhook ou email, e separar backups por janela (diário 14 dias, semanal 8 semanas, mensal 12 meses) pra cobrir cenários diferentes de recuperação.

Se você está colocando isso em produção, uma VPS Hostini já vem com SSD NVMe e opção de volume block adicional dedicado a backup, o que elimina a competição de I/O entre dados ativos e cópia de segurança. Pra workloads críticos, considere também replicação síncrona pra outra região — backup resolve perda de dados, replicação resolve indisponibilidade.