Verificação de integridade dos dados após restauração

Restaurar um banco não é sempre moleza: parece que deu tudo certo, mas aí aparecem erros nos logs, algumas tabelas somem ou os dados ficam meio estranhos. Por isso é tão importante sempre checar se tá tudo certo depois da restauração.

Às vezes, parte dos dados simplesmente não volta — tipo quando o backup tá corrompido. Pode rolar da estrutura das tabelas ficar zoada: somem foreign keys, desaparecem índices ou aparecem valores bizarros. E mesmo se tudo parecer ok, os logs podem dar aquela dica de que o banco não tá 100% saudável.

Checar a integridade é tipo fazer revisão depois do conserto. Melhor gastar uns minutos conferindo se tá tudo funcionando do que tomar susto depois no production.

Análise dos logs de restauração

Quando você restaura dados usando pg_restore, o PostgreSQL sempre gera um log. O log tem várias infos úteis sobre o processo de restauração, incluindo warnings e erros. Olha um exemplo de comando salvando o log num arquivo:

pg_restore -U username -d database_name backup_file.dump > restore_log.txt 2>&1

Repara no > restore_log.txt 2>&1 — isso manda tanto a saída padrão quanto os erros pro mesmo arquivo.

O que procurar nos logs?

1. Erros. Fica de olho em palavras tipo "ERROR" ou "FATAL". Exemplo:

   ERROR:  relação "students" não existe
   

2. Avisos. Às vezes aparecem avisos "WARNING". Não são críticos, mas vale ler — pode ser sinal de problema:

   WARNING:  não foi possível conceder privilégios para a tabela "grades"
   

3. Inconsistências de dados. Confere se todos os objetos chave voltaram: tabelas, índices, foreign keys.

Checagem rápida com grep

Se o arquivo de log ficou gigante (tipo um "Guerra e Paz" da vida), usa o grep pra buscar palavras-chave:

grep -i "error" restore_log.txt
grep -i "warning" restore_log.txt

Analisando erros dos logs

Bora ver um exemplo real de log:

ERROR:  constraint "fk_student_course" para relação "enrollments" não existe
DETAIL:  Chave (course_id)=(2) não está presente na tabela "courses".

O que esse erro quer dizer? Quer dizer que o PostgreSQL tentou restaurar uma linha na tabela enrollments, mas não existe o course_id correspondente na tabela courses.

Como resolver? Pode ser que os dados da tabela courses foram corrompidos ou não restauraram. Você vai ter que adicionar as linhas que faltam na mão ou tentar restaurar de novo.

Usando checksums pra checar integridade

Se quiser garantir que o arquivo de backup não foi corrompido antes ou depois da restauração, usa checksum.

Checksum é um número pequeno que representa os dados do arquivo. Se mudar um bit, o checksum muda também. Isso ajuda a saber se o arquivo foi alterado.

Pra gerar checksum, usa o md5sum. Exemplo de comando:

md5sum backup_file.dump

O resultado vai ser tipo:

4c9b5f5d31ae2b53e9e3d56dfedc3fe4  backup_file.dump

Comparando checksums

Se você anotou o checksum do arquivo antes, pode comparar com o atual:

md5sum -c checksum.md5

O arquivo checksum.md5 tem que ter a linha com o checksum e o nome do arquivo:

4c9b5f5d31ae2b53e9e3d56dfedc3fe4  backup_file.dump

Se o checksum bater, vai aparecer OK. Se não — o arquivo tá corrompido.

Checando dados no nível do banco

Checksums e logs são massa, mas como saber se os dados mesmo tão ok? Olha aí o que dá pra fazer:

1. Comparar quantidade de linhas

Compara o número de linhas nas tabelas antes e depois da restauração. Tipo:

-- Contando linhas na tabela students
SELECT COUNT(*) FROM students;

Se o número de linhas for diferente, a restauração não foi completa.

2. Checar integridade das chaves

Confere as relações entre tabelas pra garantir que todos os foreign keys tão funcionando:

-- Checando estudantes matriculados em cursos
SELECT *
FROM enrollments e
LEFT JOIN courses c
ON e.course_id = c.course_id
WHERE c.course_id IS NULL;

Se esse select retornar algo, quer dizer que tem linhas em enrollments com cursos que não existem.

3. Comparar dados com o original

Se você tem uma cópia dos dados (tipo um dump de outro banco), pode comparar os selects:

-- Checando dados da tabela courses
SELECT * FROM courses WHERE course_id NOT IN (
  SELECT course_id FROM courses_backup
);

Casos reais de restauração

Um caso da vida real: uma vez o DBA Bob resolveu restaurar dados do backup depois de um crash no servidor. Ele rodou o comando:

pg_restore -U admin -d my_database my_backup.dump

Mas analisando os logs, a restauração deu erro:

ERROR:  não foi possível criar o arquivo "base/16385/pg_internal.init": Sem espaço livre no dispositivo

Isso queria dizer que o disco encheu. Depois de liberar espaço e tentar restaurar de novo, ele viu que nem todas as tabelas voltaram. Ainda bem que, com os checksums gerados antes e o WAL archive configurado, Bob conseguiu restaurar o banco inteiro.

Resumo da checagem de integridade

Pra fechar a checagem de integridade dos dados depois da restauração, faz assim:

1. Confere os logs pra ver se tem erro ou aviso.
2. Usa checksums pra garantir que os arquivos não tão corrompidos.
3. Compara os dados do banco em quantidade de linhas e integridade das relações.
4. Se der ruim, investiga os erros e tenta restaurar de novo.

Agora tu tá pronto pra fazer uma checagem caprichada e garantir que os dados voltaram do jeito que tu queria. Porque o mais importante pra quem cuida de banco de dados é confiar no próprio backup!