
Volumes e redes: recuperação de dados e diagnóstico de conectividade
Objetivos desta aula
- Diferenciar persistência de backup recuperável
- Produzir e testar um backup lógico do PostgreSQL
- Diagnosticar DNS, porta e autenticação separadamente
- Inspecionar redes sem expor o banco
- Planejar descarte seguro de dados de laboratório
Persistência não é recuperação: um volume mantém os arquivos após recriar o container, mas também mantém uma exclusão acidental. O volume pgdata não oferece, sozinho, histórico nem cópia independente; um backup precisa sobreviver à falha que afetou o original.
Consistência vem antes da cópia. Copiar os arquivos de um PostgreSQL em execução com tar pode gerar um conjunto inconsistente. Para este laboratório, use pg_dump, que produz um backup lógico consistente de um banco enquanto ele continua atendendo.
Escopo importa: pg_dump cobre os objetos de um banco, não todas as roles globais do cluster. Registre versão do PostgreSQL, extensões e requisitos de acesso; sem isso, o arquivo pode existir e ainda assim não ser suficiente para reconstruir o serviço.
Restauração é o teste do backup. Crie um banco vazio separado, restaure com pg_restore --exit-on-error e confira tabelas e registros esperados. Não use o banco original como destino de um exercício, pois uma tentativa de recuperação não deve destruir a fonte.
DNS é uma etapa da conexão, não a conexão inteira. Resolver db confirma que o nome existe na rede, mas não que a porta esteja aberta ou que a senha funcione. Investigue na ordem: rede compartilhada, resolução, prontidão do servidor e autenticação.
O namespace muda o endereço: um container cliente na mesma rede usa db:5432; uma ferramenta no host só acessa uma porta publicada ou um túnel configurado. Publicar a porta apenas para depurar pode abrir uma exposição desnecessária.
Inspeção deve ser direcionada. Use docker network inspect para identificar membros e pg_isready para verificar se o servidor aceita conexões. Essa verificação de prontidão não valida a senha da aplicação; uma consulta autenticada é uma etapa posterior.
Recuperação precisa de metas: defina quanto dado pode ser perdido e quanto tempo o serviço pode ficar indisponível. Execute exercícios periódicos, armazene cópias fora do host e proteja arquivos .dump como dados de produção, não como simples logs.
Na prática
Backup e restauração em banco separado no stack existente
bash
set -euo pipefail
umask 077 # Novos arquivos ficam acessíveis somente ao proprietário.
# Ajuste usuário e banco ao Compose; autenticação deve estar configurada.
docker compose exec -T db pg_dump -U cloudshop -d cloudshop -Fc > cloudshop.dump
# Destino exclusivo para teste: o comando falha se ele já existir.
docker compose exec -T db createdb -U cloudshop cloudshop_restore
# -T evita TTY ao encaminhar o arquivo binário pela entrada padrão.
docker compose exec -T db pg_restore -U cloudshop -d cloudshop_restore --exit-on-error < cloudshop.dump
# Confira tabelas e depois execute consultas de validação de negócio.
docker compose exec -T db psql -U cloudshop -d cloudshop_restore -c '\dt'Investigar rede sem publicar a porta do banco
bash
# Descubra o nome real da rede do projeto antes de usar o cliente temporário.
docker network ls
docker network inspect cloudshop_backend
# O cliente está na mesma rede do banco; não requer -p 5432:5432.
docker run --rm --network cloudshop_backend postgres:16-alpine \
pg_isready -h db -p 5432
# pg_isready não comprova que as credenciais da aplicação funcionam.Por que isso importa
Backups restauráveis reduzem perda de pedidos, enquanto diagnóstico em camadas evita alterar firewall ou credenciais sem necessidade.
Erro comum
Considerar um arquivo de backup válido sem nunca restaurá-lo ou copiar arquivos do banco ativo sem um método consistente.
Dica de produção
Automatize restaurações isoladas, registre a duração e valide dados de negócio, não apenas a existência das tabelas.
Alerta de segurança
Backups podem conter dados pessoais e credenciais de aplicações; use criptografia, acesso mínimo e retenção definida.
Pergunta de entrevista
O banco responde ao pg_isready, mas a API não conecta: quais etapas você investigaria e por quê?
Glossário
- backup lógico
- Exportação dos objetos e dados em formato que permite reconstruir um banco.
- restore
- Processo de reconstruir dados a partir de uma cópia de segurança.
- RPO
- Limite aceitável de perda de dados medido em tempo.
- RTO
- Prazo-alvo para restaurar a operação após uma interrupção.
- namespace de rede
- Isolamento que dá a um container suas próprias interfaces e rotas.
Conexão com o CloudShop
Restaurar um backup do CloudShop em banco separado e documentar a investigação de uma conexão com falha.
Quiz da aula
1. Qual evidência demonstra melhor que o backup é utilizável?
2. O que pg_isready verifica?
3. Por que não copiar com tar os arquivos de um banco ativo sem procedimento próprio?
Minhas anotações
Salvo automaticamente neste navegador.
