Volumes persistentes e snapshots no Dockup

Volumes persistentes e snapshots resolvem problemas diferentes. Um volume mantém os arquivos entre a substituição de containers e os deployments. Um snapshot captura o volume em um determinado momento para que os operadores possam inspecionar, reter ou restaurar esse estado posteriormente.

O filesystem do container pode ser substituído. Tudo o que precisa sobreviver a um deploy — uploads, mídia gerada, índices, artefatos de pacotes ou arquivos gerenciados pela aplicação — precisa de um local persistente definido explicitamente.

Quais dados da aplicação devem ficar no armazenamento persistente?

Use um volume quando a aplicação for responsável por arquivos que não podem ser recriados de forma barata ou segura a partir de outra fonte.

Dados	Volume?	Alternativa melhor quando disponível
Uploads de usuários	Sim	Object storage, se a arquitetura o utilizar
Miniaturas geradas	Talvez	Regerar a partir dos originais
Índice de busca	Talvez	Recriar a partir do banco de dados de origem
Artefatos de build	Normalmente não	Recriar durante o deployment
Logs da aplicação	Normalmente não	Sistema de logs do runtime
Diretório de dados do PostgreSQL	Não como volume da aplicação	PostgreSQL gerenciado
Cache temporário	Não	Redis ou armazenamento efêmero
Banco de dados SQLite local em produção	Arriscado	Banco de dados gerenciado para concorrência e backups

Um volume deve ter um único proprietário e um caminho de montagem bem definido. Dois processos não relacionados gravando no mesmo diretório tornam a recuperação e a análise de permissões mais difíceis.

Antes de adicionar armazenamento, estime o tamanho inicial, a taxa de crescimento, os requisitos de retenção e o objetivo de recuperação. O disco é medido em relação ao saldo do plano por minuto, portanto, capacidade não utilizada e crescimento descontrolado de arquivos têm um custo.

Como criar e inspecionar um volume do Dockup?

Liste os volumes existentes para o serviço exato:

dockup volume list production/web --json

Adicione um volume com nome, caminho absoluto no container e tamanho em gigabytes:

dockup volume add production/web \
  --name uploads \
  --path /app/uploads \
  --size 20 \
  --json

A aplicação deve gravar em /app/uploads. Gravar em /uploads ou em outro diretório local não redireciona os dados automaticamente para a montagem.

Depois do deployment, verifique se a aplicação está gravando no caminho absoluto de montagem declarado, e não no filesystem substituível do container.

Inspecione o uso real do disco usando o ID do volume retornado:

dockup volume usage <volumeId> production/web --json

Compare o uso real com o tamanho alocado e as métricas da aplicação. Gere alertas antes que o filesystem fique cheio; um volume cheio pode causar gravações parciais, falhas em uploads ou crashes da aplicação.

Revise os requisitos de ownership dos arquivos. O usuário do runtime do container deve conseguir ler e gravar no caminho de montagem sem conceder permissões mais amplas do que o necessário.

Como os snapshots de volume protegem os dados?

Um snapshot sob demanda captura o conteúdo do volume:

dockup volume snapshot <volumeId> production/web --json

Liste os snapshots disponíveis:

dockup volume snapshots <volumeId> production/web --json

Os snapshots leem o volume de forma somente leitura e não exigem que a aplicação grave em um diretório especial de snapshot. Eles são úteis antes de uma migração arriscada de arquivos, de uma reescrita em massa de mídia ou de uma alteração na aplicação que transforme dados armazenados.

Um snapshot de volume não é automaticamente consistente com a aplicação. Se a aplicação estiver gravando vários arquivos relacionados, o snapshot poderá capturá-los em momentos ligeiramente diferentes. Para um banco de dados gerenciado, use o sistema de backup do banco de dados gerenciado em vez de criar um snapshot do diretório bruto de dados.

Defina quando a aplicação deverá ser colocada em estado quiescente. Uma breve janela de manutenção ou pausa nas gravações pode ser apropriada antes de um snapshot de alto valor. Registre o ID do snapshot, o motivo e o ponto de restauração esperado.

Como planejar a retenção de snapshots?

Escolha o momento e a retenção dos snapshots com base no requisito de recuperação, e não no hábito. Crie um snapshot sob demanda antes de cada migração arriscada de arquivos, limpeza ou alteração de formato, e registre o ID do snapshot retornado.

dockup volume snapshot <volumeId> production/web --json
dockup volume snapshots <volumeId> production/web --json

Necessidade de recuperação	Prática de snapshots	Limitação
Desfazer uma migração de arquivos	Criar um snapshot imediatamente antes da alteração	Não inclui gravações posteriores
Preservar pontos históricos	Manter pontos de recuperação identificados conforme a política	A retenção precisa ser revisada ativamente
Proteger gravações frequentes	Adicionar um backup no nível da aplicação adequado aos dados	Um snapshot pontual não é proteção contínua
Arquivo regulatório	Usar um workflow de arquivamento dedicado	Snapshots operacionais podem não atender à política

Verifique se os snapshots esperados realmente existem. Uma política de retenção documentada não é evidência de que um ponto de restauração utilizável foi criado.

Como restaurar um snapshot de volume com segurança?

Uma restauração substitui o conteúdo atual do volume e reinicia o container:

dockup volume restore \
  <volumeId> \
  <snapshotId> \
  production/web \
  --json

Esta é uma operação disruptiva que altera o estado. Antes de restaurar:

1. Confirme o serviço, o ID do volume e o ID do snapshot exatos.
2. Explique quais arquivos atuais serão substituídos.
3. Interrompa ou limite novas gravações quando possível.
4. Crie um snapshot recente do estado atual caso ele possa ser necessário.
5. Registre a compatibilidade da aplicação e do schema.
6. Obtenha aprovação explícita para produção.
7. Planeje a verificação pós-restauração.

Depois da restauração, verifique o estado do container e o comportamento da aplicação:

dockup status production/web --json
dockup logs production/web --json

Teste arquivos representativos, permissões, índices e referências da aplicação. Um comando de restauração bem-sucedido prova que o snapshot foi aplicado; não prova que todos os registros da aplicação apontam para um arquivo válido.

O modelo de guardrails de produção para agentes de IA deve tratar a restauração como uma operação condicionada à aprovação, embora seja uma operação de recuperação.

Como os volumes devem se comportar durante o deployment e o rollback?

Um deployment substitui os containers da aplicação enquanto o volume montado permanece. Isso permite que uma nova imagem veja os arquivos existentes, mas cria uma obrigação de compatibilidade.

Uma nova versão da aplicação não deve transformar arquivos armazenados de forma irreversível antes que seu release seja validado. Se ela alterar formatos de arquivo ou estruturas de diretórios, use uma migration retomável e compatível com versões anteriores sempre que possível.

O rollback da aplicação executa novamente um deployment anterior:

dockup deployments production/web -n 20 --json
dockup rollback <deploymentId> production/web --json

O volume não sofre rollback automaticamente junto com a imagem. Uma aplicação antiga pode não conseguir ler arquivos transformados pela nova versão. Coordene o rollback da imagem com a restauração do snapshot somente quando ambos forem necessários e aprovados.

Esta separação é importante:

Ação de recuperação	Altera a imagem?	Altera os dados do volume?
Fazer deploy de uma nova versão	Sim	Não, a menos que a aplicação faça uma migration
Fazer rollback do deployment	Sim	Não
Restaurar um snapshot	Não	Sim
Restaurar e fazer rollback	Sim	Sim

O processo de deployment sem downtime protege a troca do tráfego, não a compatibilidade dos formatos de dados.

O que é um runbook operacional de armazenamento durável?

Atribua um responsável a cada volume de produção. O runbook deve conter:

• Serviço de destino e ID do volume.
• Caminho de montagem e usuário esperado do runtime.
• Tamanho alocado e limite de alerta.
• Descrição dos dados e possibilidade de recriação.
• Agenda e retenção de snapshots.
• Último snapshot verificado.
• Política de aprovação para restauração.
• Etapas de validação da aplicação.
• Observações sobre compatibilidade entre imagem e dados.
• Política de crescimento e exclusão.

Inspecione o uso regularmente:

dockup volume usage <volumeId> production/web --json

CPU, RAM e disco são medidos por minuto. O plano Free oferece um crédito inicial de $10, enquanto o plano Pro recomendado custa $20 por mês e inclui $20 em créditos de uso.

Simulação de restauração de snapshot

Não espere um incidente para descobrir que ninguém sabe qual snapshot escolher. Faça uma simulação controlada em um serviço que não seja de produção ou em uma cópia aprovada:

1. Crie arquivos de teste fáceis de reconhecer.
2. Crie um snapshot.
3. Altere os arquivos.
4. Restaure o snapshot.
5. Verifique o conteúdo e as permissões.
6. Observe a reinicialização do container.
7. Registre a duração e os pontos de falha.

Uma simulação de restauração transforma volumes persistentes e snapshots de um item de checklist em uma capacidade de recuperação testada.

Para o design inicial do serviço, consulte Do repositório Git à produção. Para detalhes dos comandos, use a referência da CLI do Dockup.

Defina objetivos de recuperação para dados de arquivos

O objetivo de ponto de recuperação responde a quanto dos dados recentes a empresa pode perder. O objetivo de tempo de recuperação responde quanto tempo a restauração pode levar. Um snapshot diário com retenção de sete cópias pode atender a um cache interno de mídia, mas não a um produto de uploads de usuários que promete durabilidade quase em tempo real.

Documente os dois valores e teste a duração real da restauração. A velocidade de criação do snapshot, o tamanho dos dados, a reinicialização do container, a validação dos arquivos e a reindexação da aplicação contribuem para o tempo de recuperação.

Controle a exclusão e o crescimento de arquivos

O armazenamento persistente pode ficar cheio porque a aplicação nunca remove arquivos temporários ou substituídos. Adicione uma política de retenção na camada da aplicação e diferencie exclusão lógica de exclusão física imediata. Uma janela curta de recuperação pode justificar o adiamento da remoção permanente.

Antes de executar uma limpeza em massa:

1. Meça o uso atual do volume.
2. Gere uma lista de candidatos à exclusão.
3. Crie um snapshot.
4. Execute a limpeza em lotes limitados.
5. Verifique as referências da aplicação.
6. Confirme a recuperação de espaço esperada.

Isso dá aos volumes persistentes e snapshots uma função preventiva, e não apenas uma função em incidentes.

Verifique o inventário de snapshots

Revise periodicamente os IDs dos snapshots, os horários de criação, a retenção e o último teste de restauração bem-sucedido. Um job configurado sem um snapshot recente e utilizável não é um sistema de recuperação.

Atribua autoridade para restaurações

Defina quem pode aprovar uma restauração em produção e quem executa a validação pós-restauração. Separar aprovação e execução reduz a probabilidade de que a urgência ignore a verificação do destino e do snapshot.

Comece com um deployment verificável

Crie um volume em um ambiente que não seja de produção, faça um snapshot, altere um arquivo de teste e conclua uma simulação de restauração antes de armazenar dados de produção irrecuperáveis.

Comece gratuitamente em app.dockup.ai. O plano Free custa $0 por mês, inclui $10 em créditos iniciais e oferece suporte a um workspace, três bancos de dados e três deployments.

FAQ

Um volume do Dockup sobrevive ao deployment?

Sim. O volume permanece persistente enquanto os containers do serviço são substituídos, desde que a aplicação continue usando o caminho de montagem configurado.

Um snapshot de volume é o backup adequado para o PostgreSQL?

Não. Um snapshot em execução de um diretório de dados de banco de dados pode não ser consistente com as transações. Prefira o sistema de backup do banco de dados gerenciado para bancos de dados gerenciados.

O que acontece quando um snapshot de volume é restaurado?

O conteúdo atual do volume é substituído pelo snapshot selecionado e o container é reiniciado, portanto, a operação deve ser aprovada e verificada.

O Dockup pode agendar snapshots de volume?

Sim. O comando de agendamento de volumes oferece suporte a snapshots diários com uma quantidade de retenção, e o agendamento pode ser desativado explicitamente.

Fazer rollback de uma aplicação também faz rollback do volume?

Não. O histórico de deployments da aplicação e o histórico de snapshots do volume são separados. Coordene ambos somente quando o plano de recuperação exigir.