APRENDER. PRATICAR. EVOLUIR.O que muda quando a instância é recriada
Uma correção manual na camada gravável pode sobreviver ao restart da mesma instância e desaparecer quando o contentor é removido e recriado. Para a tornar reproduzível, integra-a no artefacto ou configuração mantidos e valida uma criação nova. Um volume existente tem outro ciclo de vida. Se já contém dados e é montado em /data, obscurece os ficheiros desse caminho na imagem nova. O seed de um volume vazio não é uma migração automática de volumes preenchidos. Regista separadamente a versão da aplicação e a versão ou estrutura do estado persistente.
Persistência precisa de um destino deliberado
O caso fictício guarda o único ficheiro de reconciliação em tmpfs. Antes de parar, é preciso preservar o resultado necessário num destino autorizado e confirmar integridade. O nome do contentor não torna temporário em persistente. A documentação também alerta que tmpfs pode usar swap; não deve ser apresentado como garantia absoluta de ausência de dados em disco. Para volumes anónimos criados com --rm, considera a remoção associada ao contentor. Define previamente quais dados podem desaparecer, quais precisam de retenção e qual identidade permite localizar o recurso certo.
Permissões devem ser revistas por mount
Um root filesystem read-only não impede necessariamente escrita num volume explicitamente gravável. Revê cada destino e o âmbito da proteção. Um bind read-only com submounts exige ainda atenção ao kernel e às opções recursivas: a documentação condiciona readonly recursivo a Linux 5.12 ou posterior. O anfitrião relevante é o do runtime, não apenas o portátil do operador. Noutro cenário, -v cria uma origem ausente como diretório quando a aplicação esperava um ficheiro. Confirma existência, tipo, proprietário e conteúdo antes de aplicar, sem transformar um erro de caminho numa permissão mais ampla.
Capacidade e limpeza com identidade
O crescimento pode estar na camada gravável, nos volumes ou nos logs. Um volume de base de dados estável não exclui os outros consumidores. Se há pressão de capacidade, identifica origem, proprietário e retenção antes de remover recursos. Um volume sem contentor ativo pode continuar reservado para recuperação. Limita crescimento e seleciona ações autorizadas com benefício mensurável, preservando dados e evidência. A mesma precisão aplica-se à CPU: --cpus define um limite, não uma reserva exclusiva de cores. Observa contenção e throttling antes de prometer capacidade funcional a partir de uma configuração.
Checksum, consistência e RPO são critérios distintos
Um arquivo que abre e coincide em checksum demonstra integridade da cópia sob esse critério, não consistência transacional de uma base capturada durante escritas. Escolhe um método suportado pela aplicação e ensaia restauro com resultados verificáveis. No exercício, o último ponto confirmado é 09:42 e a falha ocorre às 09:50. São oito minutos, três acima do RPO aprovado de cinco. Esse cálculo não estima número ou valor das operações. O tempo para arrancar o processo também não reduz a janela de dados que permanece sem recuperação confirmada.
Oficina de reversão com estado incompatível
Uma imagem anterior pode estar disponível e continuar incapaz de ler registos produzidos pela versão nova. Antes de declarar rollback pronto, define como recuperar ou compatibilizar os dados e reconciliar efeitos posteriores. Não elimines um volume misto para obter novas regras de seed quando também contém resultados históricos. Prepara uma passagem com configuração efetiva, estado por serviço, ponto recuperável, resultados funcionais e decisões aceites por responsáveis. Estas fichas são exercícios documentais originais; a disponibilidade de um runtime e um ensaio isolado continuam necessários para validar operacionalmente o procedimento concreto.
Exercício: ponto recuperável 09:42, falha 09:50, RPO aprovado 5 min. Exposição temporal 8 min, desvio 3 min. Um checksum correto não altera essa janela nem comprova consistência da base.
Armadilhas comuns
Tratar seed como migração; guardar o único resultado em tmpfs; assumir que root read-only protege todos os mounts; limpar volumes sem proprietário; confundir checksum, RPO e tempo de arranque.
Tópicos relacionados: Processos e imagens · Dados e mounts · Compose: overrides, dados e aceitação
A recuperação depende da identidade e consistência dos dados, além da imagem e do processo. Preserva o estado necessário e valida o resultado antes de encerrar a intervenção.
Referência: Volumes · Docker Engine Linux containers, BuildKit and Compose; official documentation consulted 2026-09-30; version-dependent behavior explicitly scoped