Guia prático de Docker Volumes: 5 exemplos para evitar a perda de dados em contêineres

A última linha exibida no terminal foi: “Database import completed successfully”. Depois de quatro horas de trabalho, eu finalmente havia importado 20 mil registros de teste para um contêiner MySQL. Testei algumas APIs, e tudo funcionou.

Na manhã seguinte, digitei docker ps por hábito para conferir o estado do contêiner. A lista estava vazia. Será que eu havia esquecido de iniciá-lo na noite anterior? Corri para verificar todos os contêineres com docker ps -a. Nada. Então me lembrei: antes de dormir, executei docker system prune -a para liberar espaço em disco.

Pronto. Todos os dados haviam sumido. Vinte mil registros de teste e quatro horas de trabalho reduzidos a zero.

Eu usava Docker havia apenas três semanas. Sabia que os contêineres iniciavam rápido e isolavam bem os ambientes, mas ainda não conhecia seu “calcanhar de Aquiles”: o contêiner em si não é adequado para armazenar dados. Exclua o contêiner e os dados desaparecem; reinicie-o e os arquivos de configuração podem voltar ao estado inicial.

Neste artigo, você vai aprender, por meio de cinco exemplos práticos, a usar Docker Volumes para tirar os dados de dentro do contêiner e impedir que desapareçam junto com ele.

A verdade sobre a perda de dados em contêineres

Por que os dados somem quando o contêiner é excluído?

O Docker usa um sistema de arquivos em camadas. Imagine um bolo com várias camadas: na base ficam as camadas da imagem, que são somente leitura e compartilhadas por todos os contêineres; no topo fica a camada do contêiner, que é gravável e exclusiva de cada contêiner. Arquivos criados, configurações alteradas e dados importados dentro do contêiner são gravados nessa camada superior.

O ponto crucial é este: quando o contêiner é excluído, essa camada gravável também é destruída.

Não acredita? Experimente:

# Inicie um contêiner Alpine e grave um arquivo
docker run -it --name test-container alpine sh
# Execute dentro do contêiner
echo "dados importantes" > /tmp/data.txt
exit

# Exclua o contêiner
docker rm test-container

# Tente recuperar os dados
docker run -it --name test-container alpine sh
cat /tmp/data.txt  # Erro: No such file or directory

Os dados desaparecem sem qualquer aviso.

Na verdade, esse comportamento faz sentido: contêineres foram projetados para aplicações sem estado. Pense no Nginx e em servidores de API. Eles não precisam guardar dados e devem iniciar sempre do mesmo modo. Mas e bancos de dados, Redis e serviços de upload de arquivos? Eles precisam preservar os dados.

A solução oficial do Docker é o Volume: armazenar os dados fora do contêiner e separar completamente o ciclo de vida dos dados do ciclo de vida do contêiner.

O que é um Volume e como ele protege seus dados

Em essência, um Volume é como um disco externo para o Docker

Um Volume funciona como um disco conectado ao contêiner. Em vez de gravar os dados dentro dele, o Docker os grava em um diretório do host e monta esse diretório em um caminho interno do contêiner. O contêiner enxerga /var/lib/mysql, mas os dados reais ficam em /var/lib/docker/volumes/mysql-data/_data no host.

Excluiu o contêiner? Sem problema: os dados continuam no host. Basta iniciar outro contêiner e montar o mesmo Volume para recuperá-los.

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

Começar →Anúncio

O Docker oferece três tipos de montagem, que costumam confundir quem está começando:

Sendo sincero, no começo eu também não entendia a diferença entre Volume e Bind Mount. Ambos pareciam apenas uma forma de “montar um diretório do host”. A diferença ficou clara depois de um problema: usei Bind Mount no diretório de dados do MySQL, apaguei sem querer o diretório no host e o contêiner MySQL parou de funcionar.

Com um Volume, o Docker cuida de tudo. Você não precisa administrar caminhos ou permissões. Quer saber onde os dados estão? Use docker volume inspect. Quer migrá-los? Use os comandos docker volume. É por isso que a documentação recomenda Volume em vez de Bind Mount para esse tipo de dado.

Onde os dados de um Volume ficam de fato?

Em sistemas Linux, todos os Volumes ficam por padrão em:

/var/lib/docker/volumes/<volume-name>/_data/

Quem usa Mac ou Windows não encontrará esse caminho diretamente, pois o Docker Desktop roda em uma máquina virtual. Mesmo assim, é possível consultar os detalhes com docker volume inspect.

5 exemplos para dominar os principais usos de Volumes

Chega de teoria. Estes cinco exemplos vão do básico a situações reais. Faça cada um deles e você entenderá como os Volumes funcionam.

Exemplo 1: crie seu primeiro Volume nomeado

Comece pelo mais simples: crie um Volume vazio.

# Crie um Volume chamado my-data
docker volume create my-data

# Liste todos os Volumes
docker volume ls

# Veja os detalhes do Volume
docker volume inspect my-data

Saída esperada do comando inspect:

[
    {
        "CreatedAt": "2025-12-17T12:00:00Z",
        "Driver": "local",
        "Mountpoint": "/var/lib/docker/volumes/my-data/_data",
        "Name": "my-data"
    }
]

Viu o campo Mountpoint? Esse é o local em que os dados realmente ficam armazenados.

Exemplo 2: persistência de um site estático no Nginx

Cenário: você está desenvolvendo um site estático e precisa reiniciar o contêiner Nginx a cada alteração no código. Porém, após cada reinicialização, imagens enviadas anteriormente e arquivos de log desaparecem.

A solução é montar o diretório /usr/share/nginx/html do Nginx em um Volume.

# Crie um Volume para armazenar o conteúdo do site
docker volume create nginx-html

# Inicie o contêiner Nginx e monte o Volume
docker run -d \
  --name my-nginx \
  -p 8080:80 \
  -v nginx-html:/usr/share/nginx/html \
  nginx:latest

# Entre no contêiner e crie uma página de teste
docker exec my-nginx bash -c 'echo "<h1>Hello Docker Volume!</h1>" > /usr/share/nginx/html/index.html'

# Teste o acesso no navegador em http://localhost:8080 ou pela linha de comando
curl http://localhost:8080

Agora exclua o contêiner:

docker rm -f my-nginx

Inicie outro contêiner montando o mesmo Volume:

docker run -d \
  --name my-nginx-v2 \
  -p 8080:80 \
  -v nginx-html:/usr/share/nginx/html \
  nginx:latest

# Acesse novamente: o conteúdo continua lá
curl http://localhost:8080

Os dados continuam lá. Esse é o poder dos Volumes.

Exemplo 3: persistência de dados do MySQL em um cenário real

Esse é um dos casos de uso mais comuns. Ao executar o MySQL em um contêiner, os dados precisam ser persistentes.

# Crie um Volume dedicado ao MySQL
docker volume create mysql-data

# Inicie o contêiner MySQL
docker run -d \
  --name mysql-demo \
  -e MYSQL_ROOT_PASSWORD=my-secret-pw \
  -e MYSQL_DATABASE=testdb \
  -p 3306:3306 \
  -v mysql-data:/var/lib/mysql \
  mysql:8.0

# Aguarde o MySQL iniciar, por cerca de 10 segundos
sleep 10

# Conecte-se ao MySQL e crie uma tabela de teste
docker exec -it mysql-demo mysql -uroot -pmy-secret-pw testdb -e "
CREATE TABLE users (
  id INT PRIMARY KEY AUTO_INCREMENT,
  name VARCHAR(50)
);
INSERT INTO users (name) VALUES ('Alice'), ('Bob');
"

# Consulte os dados
docker exec -it mysql-demo mysql -uroot -pmy-secret-pw testdb -e "SELECT * FROM users;"

Agora exclua o contêiner para simular uma remoção acidental:

docker rm -f mysql-demo

Inicie outro contêiner MySQL montando o mesmo Volume:

docker run -d \
  --name mysql-demo-v2 \
  -e MYSQL_ROOT_PASSWORD=my-secret-pw \
  -p 3306:3306 \
  -v mysql-data:/var/lib/mysql \
  mysql:8.0

# Aguarde a inicialização
sleep 10

# Consulte os dados: eles continuam lá
docker exec -it mysql-demo-v2 mysql -uroot -pmy-secret-pw testdb -e "SELECT * FROM users;"

Ponto importante: o diretório de dados do MySQL é /var/lib/mysql, e esse é o caminho que deve ser montado. Cada banco usa um caminho diferente: no Redis é /data; no PostgreSQL, /var/lib/postgresql/data.

Exemplo 4: configuração de persistência no Redis

Por padrão, o Redis mantém os dados na memória, mas é possível configurar a persistência em disco com RDB ou AOF.

# Crie um Volume para os dados do Redis
docker volume create redis-data

# Inicie o contêiner Redis e ative a persistência AOF
docker run -d \
  --name redis-demo \
  -p 6379:6379 \
  -v redis-data:/data \
  redis:latest redis-server --appendonly yes
  # --appendonly yes ativa a persistência AOF

# Grave dados de teste
docker exec -it redis-demo redis-cli SET mykey "Hello Redis Volume"

# Leia os dados
docker exec -it redis-demo redis-cli GET mykey

Exclua o contêiner:

docker rm -f redis-demo

Inicie-o novamente:

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

Ganhar 15% off →Anúncio

docker run -d \
  --name redis-demo-v2 \
  -p 6379:6379 \
  -v redis-data:/data \
  redis:latest redis-server --appendonly yes

# Os dados continuam lá
docker exec -it redis-demo-v2 redis-cli GET mykey

Atenção: é necessário usar o parâmetro --appendonly yes. Sem ele, os dados ficam apenas na memória do Redis e ainda serão perdidos após a reinicialização do contêiner.

Exemplo 5: compartilhamento de um Volume entre vários contêineres

Cenário: um contêiner Nginx disponibiliza arquivos estáticos, enquanto outro contêiner de aplicação gera logs. Os dois compartilham o mesmo Volume.

# Crie um Volume compartilhado
docker volume create shared-logs

# Inicie o contêiner da aplicação e grave logs
docker run -d \
  --name app-writer \
  -v shared-logs:/logs \
  alpine sh -c "while true; do echo $(date) >> /logs/app.log; sleep 2; done"

# Inicie o contêiner Nginx para ler os logs
docker run -d \
  --name log-reader \
  -p 8080:80 \
  -v shared-logs:/usr/share/nginx/html:ro \
  nginx:latest
  # :ro faz uma montagem somente leitura e impede que o Nginx altere os logs

# Aguarde alguns segundos para que app-writer grave os logs
sleep 5

# Acesse o log no navegador em http://localhost:8080/app.log
curl http://localhost:8080/app.log

Pontos importantes:

1. Um Volume pode ser montado simultaneamente em vários contêineres.
2. O sufixo :ro ativa o modo somente leitura e aumenta a segurança.
3. Em produção, essa abordagem pode ser usada em uma arquitetura com um contêiner de coleta de logs e outro de aplicação.

Comandos para gerenciar Volumes

Depois dos cinco exemplos, surge a pergunta: como listar, excluir e limpar esses Volumes?

Aqui está uma referência rápida com os principais comandos:

# 1. Crie um Volume
docker volume create <volume-name>

# 2. Liste todos os Volumes
docker volume ls

# 3. Veja os detalhes do Volume, incluindo o caminho de montagem
docker volume inspect <volume-name>

# 4. Exclua um Volume específico
docker volume rm <volume-name>
# Se algum contêiner estiver usando o Volume, o comando retornará um erro

# 5. Exclua todos os Volumes sem uso para liberar espaço em disco
docker volume prune
# Uma confirmação será exibida; digite y para continuar

# 6. Exclua à força todos os Volumes sem uso, sem confirmação
docker volume prune -f

Problema comum: a mensagem “volume is in use” aparece ao excluir um Volume

Isso indica que algum contêiner está usando o Volume. Para resolver:

# Descubra qual contêiner está usando o Volume
docker ps -a --filter volume=<volume-name>

# Primeiro, pare e exclua o contêiner
docker rm -f <container-name>

# Depois, exclua o Volume
docker volume rm <volume-name>

Como verificar o uso de espaço em disco

Quer saber quanto espaço um Volume ocupa? Experimente:

# Linux e Mac
docker volume inspect <volume-name> --format '{{ .Mountpoint }}' | xargs du -sh

# Exemplo de saída: 512M    /var/lib/docker/volumes/mysql-data/_data

Bind Mount vs. Volume: qual usar?

Essa é uma das maiores dúvidas de quem está começando. Eu também misturava os dois no início.

Guarde uma regra simples: use Volume para dados de produção e Bind Mount para código em desenvolvimento.

Veja os casos mais comuns:

Comparação da sintaxe

# Volume, recomendado para dados persistentes
docker run -v my-volume:/data redis:latest

# Bind Mount, recomendado para ambientes de desenvolvimento
docker run -v /Users/me/code:/app node:latest

# Nova sintaxe --mount, mais explícita e recomendada em produção
docker run --mount type=volume,source=my-volume,target=/data redis:latest
docker run --mount type=bind,source=/Users/me/code,target=/app node:latest

Árvore de decisão

Quando surgir uma nova necessidade e você não souber qual opção usar, faça três perguntas:

1. Os dados precisam ser guardados por muito tempo?
   Sim → Volume; não → tmpfs

2. Os dados precisam ser editados diretamente no host?
   Sim → Bind Mount; não → Volume

3. É um ambiente de produção ou desenvolvimento?
   Produção → Volume; desenvolvimento → Bind Mount

Comparação em um caso real

Meu ambiente de desenvolvimento:

# Em desenvolvimento: Bind Mount para o código e Volume para o banco de dados
docker run -d \
  --name dev-app \
  -v $(pwd)/src:/app/src \          # Bind Mount: alterações no código entram em vigor imediatamente
  -v app-uploads:/app/uploads \     # Volume: arquivos enviados pelos usuários
  -v postgres-data:/var/lib/postgresql/data \  # Volume: dados do banco
  my-app:dev

Meu ambiente de produção:

# Em produção: use apenas Volumes
docker run -d \
  --name prod-app \
  -v app-uploads:/app/uploads \
  -v postgres-data:/var/lib/postgresql/data \
  my-app:latest
# O código já está empacotado na imagem e não precisa ser montado

Dúvidas frequentes e boas práticas

FAQ: problemas que enfrentei e como resolvê-los

P1: Os dados de um Volume podem desaparecer?
Não. Desde que você não execute docker volume rm manualmente, os dados continuarão lá. Eles também sobrevivem à reinicialização do host.

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

Começar agora →Anúncio

Mas atenção: docker system prune -a --volumes exclui todos os Volumes sem uso. Use esse comando com cuidado.

P2: O que acontece se o Volume não existir ao iniciar o contêiner?
O Docker o cria automaticamente. Experimente:

# Não é necessário executar docker volume create antes
docker run -d -v auto-created-volume:/data alpine
# O Docker cria automaticamente o Volume auto-created-volume

Ainda assim, recomendo criá-lo manualmente, pois isso deixa mais claro onde os dados estão.

P3: Como fazer backup dos dados de um Volume?
O método recomendado oficialmente é:

# Inicie um contêiner temporário e compacte os dados do Volume
docker run --rm \
  -v mysql-data:/source \
  -v $(pwd):/backup \
  alpine tar -czf /backup/mysql-backup.tar.gz -C /source .

# Para restaurar
docker run --rm \
  -v mysql-data:/target \
  -v $(pwd):/backup \
  alpine tar -xzf /backup/mysql-backup.tar.gz -C /target

P4: É possível migrar um Volume entre hosts diferentes?
Sim, mas o processo é manual:

1. No host original, compacte os dados do Volume usando o método acima.
2. Transfira o arquivo .tar.gz para o novo host.
3. No novo host, crie um Volume e extraia os dados nele.

Uma alternativa mais avançada é usar NFS ou armazenamento em nuvem como Volume Driver.

P5: O que é um Volume anônimo e como limpá-lo?
Quando você não informa um nome, o Docker cria um Volume anônimo:

docker run -d -v /data alpine  # Gera um nome aleatório, como a1b2c3d4...

Volumes anônimos são difíceis de administrar e podem se acumular, ocupando espaço em disco. Para limpá-los:

docker volume prune  # Exclui todos os Volumes sem uso, inclusive os anônimos

Boa prática: use sempre Volumes nomeados.

6 boas práticas essenciais para produção

1. Use sempre Volumes nomeados

   # ✓ Boa prática
   docker run -v mysql-data:/var/lib/mysql mysql:8.0
   
   # ✗ Prática ruim
   docker run -v /var/lib/mysql mysql:8.0  # Volume anônimo

2. Faça backups periódicos dos dados importantes
   Configure uma tarefa agendada para fazer backup diário do Volume do banco de dados. Quem já perdeu dados sabe como é.

3. Use Docker Compose para gerenciar projetos complexos

   # docker-compose.yml
   services:
     db:
       image: mysql:8.0
       volumes:
         - mysql-data:/var/lib/mysql
   
   volumes:
     mysql-data:
       driver: local

4. Em produção, use --mount em vez de -v
   A sintaxe de --mount é mais explícita e produz mensagens mais claras quando algo dá errado:

   docker run --mount type=volume,source=mysql-data,target=/var/lib/mysql mysql:8.0

5. Limpe periodicamente os Volumes sem uso
   Execute uma vez por mês:

   docker volume prune

6. Use Volumes criptografados para dados sensíveis
   Se o Volume contiver senhas ou chaves, considere uma solução de criptografia, como uma partição criptografada com LUKS.

Conclusão

Voltando àquela madrugada do início do artigo: se eu soubesse usar Docker Volumes, teria precisado de apenas uma linha:

docker run -d --name mysql-demo -v mysql-data:/var/lib/mysql mysql:8.0

Os dados não teriam desaparecido com o contêiner. As quatro horas de trabalho e os 20 mil registros de teste estariam seguros no host.

Os contêineres Docker não mantêm estado por natureza. Essa é uma vantagem e, ao mesmo tempo, uma limitação. Os Volumes existem para superar essa limitação: você aproveita a leveza e o isolamento dos contêineres sem abrir mão da persistência dos dados.

Neste artigo, vimos cinco exemplos: a criação do primeiro Volume, a persistência de um site estático no Nginx, cenários reais com MySQL e Redis e, por fim, o compartilhamento de um Volume entre vários contêineres. Esses cinco exemplos cobrem cerca de 90% das necessidades do desenvolvimento cotidiano.

Agora é sua vez. Abra o terminal, crie seu primeiro Volume, inicie um contêiner MySQL e grave alguns dados nele. Depois, exclua o contêiner, inicie outro e veja os dados continuarem lá. Nesse momento, você entenderá de verdade o que significa persistência de dados.

E, se você não quiser passar pelo medo de perder dados de madrugada, salve este artigo. Um dia ele pode evitar um belo problema.