Defina perda e indisponibilidade aceitáveis
Anote o ponto de recuperação aceitável mais recente e o tempo alvo para restaurar um serviço útil. Esses são objetivos de aplicação, não um SLA PrivacyNodes. Se perder uma hora de dados for inaceitável, uma cópia diária sozinha não consegue atender a esse objetivo. Escolha um método de backup de banco de dados consistente com sua carga de trabalho e versão.
Obtenha um destino descartável, o artefato da aplicação e credenciais de recuperação autorizadas por meio de armazenamento protegido. Confirme quem aprova a restauração de dados de clientes e como o ambiente de teste impede tráfego externo. Não restaure sobre o banco de dados de produção em execução ou um diretório existente.
Inventarie todo o estado da aplicação
Para a API de relatórios, liste PostgreSQL, uploads, exportações que não podem ser reproduzidas, configuração, referências de chaves de criptografia, DNS e dependências externas. Diferencie um cache descartável de uma fila que contém trabalho de clientes que precisa de reconciliação. Uma imagem de contêiner descreve software, não todo o estado persistente.
| Registro | Seu valor |
|---|---|
| Versão do artefato e da configuração | Identificadores exatos |
| Backup de banco de dados e ponto de recuperação | Arquivo escolhido e timestamp |
| Snapshot de upload e limite de consistência | Snapshot, caminho e plano correspondente |
| Destino descartável | Ambiente verificado e destino vazio |
| Credenciais e aprovador | Apenas referências protegidas |
| Início, conclusão, etapas ausentes | Resultados observados, não estimativas |
Entenda o que o backup inclui
O PostgreSQL documenta dumps lógicos, backups de sistema de arquivos e arquivamento contínuo como estratégias diferentes. Um pg_dump archive cobre um banco de dados; funções e tablespaces de todo o cluster exigem consideração separada. Seu cliente não consegue fazer dump de um servidor de versão principal mais nova. Combine versões de ferramentas e estratégia com o objetivo; copiar um diretório de dados ativo não é automaticamente consistente.
Inspecione um archive antes de restaurar. Selecionar uma tabela com pg_restore não inclui automaticamente todas as suas dependências. Sua --clean opção descarta objetos existentes; uma restauração de transação única não pode ser combinada com jobs paralelos. Revise as opções para o banco de dados de teste vazio especificamente identificado.
Referência técnica: Backup e restauração do PostgreSQL · PostgreSQL pg_dump · PostgreSQL pg_restore.
Verifique a integridade e restaure de forma independente
Verificações de repositório e restaurações funcionais respondem a perguntas diferentes. O comando comum do restic check não lê todos os pacotes de dados armazenados; check --read-data adiciona essas leituras e pode consumir largura de banda substancial. Nenhum dos dois prova que o snapshot contém tudo o que a API precisa.
Selecione um snapshot específico e um novo diretório de destino. Um caminho não qualificado latest em um repositório compartilhado pode selecionar outra carga de trabalho. Uma restauração pode sobrescrever arquivos e uma interrupção pode deixar resultados parciais. Verifique o destino primeiro, mantendo arquivos de produção e o repositório original intactos.
Referência técnica: verificações de repositório do restic · destinos de restauração do restic.
Teste o comportamento restaurado na ordem das dependências
Recrie o ambiente, restaure o banco de dados e os uploads correspondentes e então inicie a API com credenciais de staging. Mantenha os workers pausados até que seu backlog e efeitos colaterais sejam compreendidos. Desative e-mail de produção, chamadas de pagamento e webhooks; use um destino de exportação de teste e nunca consuma a fila de produção.
Use uma conta de teste conhecida para ler um registro, abrir seu upload, verificar restrições de acesso e executar uma pequena nova exportação. Verifique que outra conta de teste não consegue ler seus dados. Compare o ponto de recuperação selecionado com o registro esperado mais recente. Registre o tempo real de restauração após o drill; não escreva um resultado de sucesso inventado com antecedência.
Resolva a propriedade de escrita antes de um cutover real
Durante um incidente, decida qual sistema pode aceitar escritas e como alterações posteriores são reconciliadas. Duas cópias graváveis podem divergir. Um drill documenta essa decisão sem alternar tráfego real. Remova dados descartáveis conforme suas regras de retenção quando o exercício terminar.
Corrija credenciais, dependências e etapas de validação ausentes após cada ensaio. Mantenha o runbook fora do host original e garanta que outro mantenedor autorizado consiga encontrá-lo. A opção de backup selecionável é separada deste processo de aplicação; confirme escopo e procedimentos de restauração em fatos do serviço. Use o registro de versão para a implantação que se segue.
Referências oficiais
A documentação foi revisada para este artigo. Os exemplos são exercícios de planejamento, não comandos testados em um servidor PrivacyNodes. Verifique a documentação da sua versão instalada.