Mantenha o primeiro exercício deliberadamente pequeno
Este exercício cria um banco de dados de notas de brinquedo e um anexo, captura ambos e depois os restaura em um novo banco de dados e diretório. Use uma máquina Linux descartável com servidor PostgreSQL 17 e utilitários cliente correspondentes, Bash e GNU coreutils. Ela não deve conter dados de produção e não deve ter conexão com aplicações de produção, correio de saída ou tarefas agendadas. Use apenas o arquivo criado neste exercício.
Os comandos assumem um papel de banco de dados pré-configurado, não superusuário, chamado restore_lab, com permissão para criar bancos de dados de teste, e um login de sistema operacional com o mesmo nome que possa autenticar localmente. O socket do PostgreSQL é /var/run/postgresql na porta 5432. Peça ao administrador para preparar essa conta no ambiente descartável; este guia não modifica as regras de acesso ao banco de dados. Verifique o endpoint antes de criar qualquer coisa:
psql -h /var/run/postgresql -p 5432 -U restore_lab -d postgres -c '\conninfo' &&
pg_dump --version &&
pg_restore --version
Pare se o host, a conta ou a versão forem inesperados. Mantenha clientes e servidor na mesma versão principal para este primeiro treino. pg_dump não pode fazer dump de um servidor mais novo que sua própria versão principal, e um destino de restauração mais antigo geralmente não é garantidamente compatível. Consulte limites de versão do pg_dump. Execute cada bloco separadamente e pare em um erro. Os && protegem contra a execução de comandos posteriores em um bloco colado após uma falha; nunca continue para o próximo bloco após uma falha na criação do banco de dados ou do diretório.
Crie um registro e seu arquivo correspondente
Os nomes offvps_restore_source e offvps_restore_target devem estar sem uso. Um banco de dados existente é motivo para parar e escolher um novo exercício isolado, não para eliminá-lo. Crie um espaço de trabalho novo no sistema de arquivos e o banco de dados de origem:
umask 077 &&
lab=$(mktemp -d "$PWD/offvps-restore.XXXXXX") &&
mkdir "$lab/source" "$lab/source/uploads" "$lab/bundle" "$lab/restore" &&
createdb -h /var/run/postgresql -p 5432 -U restore_lab \
--template=template0 offvps_restore_source
O espaço de trabalho novo evita sobrescrever um diretório existente. mktemp cria um diretório exclusivo; createdb cria um novo banco de dados a partir do modelo selecionado. Salve estes dois marcadores:
psql -X -v ON_ERROR_STOP=1 -h /var/run/postgresql -p 5432 \
-U restore_lab -d offvps_restore_source \
-c "CREATE TABLE notes (
id integer PRIMARY KEY,
body text NOT NULL,
attachment text NOT NULL
);
INSERT INTO notes VALUES (1, 'restore-marker-01', 'marker.txt');" &&
printf '%s\n' 'restore-marker-01' > "$lab/source/uploads/marker.txt"
O registro diz qual arquivo pertence à nota, e ambos contêm o mesmo marcador. Isso torna visível um anexo ausente ou uma cópia incompatível. -X evita configurações pessoais de inicialização do psql e ON_ERROR_STOP para em um erro SQL; consulte opções de script do psql. Não há aplicação escrevendo neste conjunto de dados de brinquedo.
Capture o banco de dados e os arquivos como um único conjunto de recuperação
pg_dump -h /var/run/postgresql -p 5432 -U restore_lab \
--format=custom --file="$lab/bundle/notes.dump" offvps_restore_source &&
cp -a "$lab/source/uploads" "$lab/bundle/uploads" &&
pg_restore --list "$lab/bundle/notes.dump"
O arquivo em formato personalizado é lido por pg_restore; um dump SQL simples segue um procedimento de restauração diferente. Listar o arquivo ajuda a confirmar que a tabela e as entradas de dados esperadas estão presentes. Um dump consistente do banco de dados não sincroniza automaticamente uploads externos. Para uma aplicação real, use seu procedimento documentado de manutenção ou pausa de escrita para que a árvore de arquivos e o banco de dados descrevam o mesmo ponto no tempo. O exercício de brinquedo já está silencioso.
Registre a versão do banco de dados, a versão da aplicação, o início/fim da captura e o caminho dos arquivos ao lado do pacote. Mantenha credenciais reais separadamente sob controles de acesso apropriados. Um dump por banco de dados não captura papéis globais e tablespaces; um plano de recuperação real deve considerá-los também. O escopo é descrito em Guia de dump SQL do PostgreSQL.
Restaure em novos destinos sem limpar um existente
createdb -h /var/run/postgresql -p 5432 -U restore_lab \
--template=template0 offvps_restore_target &&
pg_restore -h /var/run/postgresql -p 5432 -U restore_lab \
--dbname=offvps_restore_target --no-owner --no-acl \
--single-transaction "$lab/bundle/notes.dump" &&
mkdir "$lab/restore/uploads" &&
cp -a "$lab/bundle/uploads/." "$lab/restore/uploads/"
O banco de dados de destino é criado vazio. A restauração omite intencionalmente --clean, o que poderia remover objetos existentes. --single-transaction faz esta restauração de banco de dados pequeno ter sucesso como uma unidade ou parar sem aplicar suas alterações parciais; não pode ser combinado com tarefas paralelas. --no-owner e --no-acl simplifica a propriedade para este papel de teste, então este treino não valida os papéis ou permissões de produção da aplicação. Consulte pg_restore.
A cópia de arquivo tem como destino o novo diretório de restauração, deixando a origem intacta. O GNU cp -a tenta preservar atributos de arquivo; inspecione a propriedade e o acesso para a conta que executará uma aplicação real. Copiar bytes não é um teste de permissões da aplicação. Consulte opção de arquivo do cp.
Verifique o relacionamento, não apenas os códigos de saída
psql -X -h /var/run/postgresql -p 5432 -U restore_lab \
-d offvps_restore_target -c "SELECT id, body, attachment FROM notes;" &&
cat "$lab/restore/uploads/marker.txt"
Os resultados esperados são uma linha com ID 1, corpo restore-marker-01 e anexo marker.txt, mais um arquivo contendo restore-marker-01. Verifique se a origem ainda contém sua linha e arquivo originais. Para sua aplicação real, também aponte uma instância isolada para o banco de dados restaurado e o diretório de upload, abra registros representativos, busque um anexo e teste as permissões de login pretendidas. Mantenha callbacks, correio e tarefas contidos ao fazer isso.
Anote o que você provou e o que permanece
| Registro | O que capturar |
|---|---|
| Ponto de recuperação | Hora da captura e o registro esperado mais recente |
| Duração da recuperação | Horários de início/fim e etapas manuais |
| Verificações | Linha do banco de dados, conteúdo do anexo e verificações da aplicação |
| Exceções | Papéis, permissões, configuração ou dependências ausentes |
| Próximo treino | Um gatilho como uma mudança de esquema, armazenamento ou implantação |
Os resultados esperados acima são critérios do exercício, não resultados já observados pelo OffVPS. Como o primeiro treino mantém todos os arquivos em uma única máquina, ele não oferece proteção contra a perda dessa máquina. Um plano real precisa de uma cópia protegida em um domínio de falha separado, chaves de descriptografia utilizáveis, retenção e um caminho de recuperação testado. Revise os nomes exatos do banco de dados descartável e do diretório antes da limpeza posterior; mantenha a produção fora desse processo.
Repita o exercício após mudanças importantes e registre falhas com o mesmo cuidado que os sucessos. Um serviço de backup opcional não prova o tempo de recuperação da sua aplicação. Continue com planejar uma tarefa agendada quando estiver pronto para automatizar a captura, mantendo um treino de restauração separado.
Documentação utilizada
Referências primárias para esta página. Consulte a documentação da versão instalada em seu próprio ambiente.