O que fazer quando o backup está corrompido

Sheet happens. Na última aula, a gente também viu o passo a passo pra restaurar completamente o banco de dados depois de um crash. Mas a vida real adora pregar peças. E se o seu backup estiver corrompido? Chegou a hora de entender como lidar com isso.

Onde é melhor colocar o currículo?

Brincadeira. Agora vamos falar de coisas técnicas. Mas lembra: toda piada tem um fundo de verdade :)

Analisando o backup corrompido

Backup corrompido — é tipo aquele arquivo do seu TCC que não abre bem na hora de entregar. Os sintomas são parecidos:

• Erros ao tentar restaurar: quando você roda o pg_restore, pode aparecer erro tipo:

  pg_restore: [archiver] input file does not appear to be a valid archive

• Parte dos dados sumiu ou o arquivo tá com tamanho estranho (tipo, ficou pequeno do nada ou até zerado).
• O arquivo SQL extraído tem dados cortados, símbolos estranhos ou partes vazias.

Backups podem ser corrompidos por vários motivos:

• Interrupção no processo de backup (tipo queda de energia ou desligamento do sistema).
• Transferência errada do arquivo (erro ao copiar pra pendrive ou pela rede).
• Falha de hardware (discos, RAM, problema no RAID).
• Erro na configuração do sistema ou da ferramenta de backup.
• Vírus, malware e, claro, aquele "clique errado" clássico.

Recuperando dados de um backup corrompido

Se o arquivo tá corrompido, não é o fim do mundo. Às vezes dá pra salvar alguma coisa. Bora ver algumas estratégias.

Tentando restaurar com pg_restore

Se o arquivo foi criado com pg_dump no formato custom ou directory, tenta restaurar usando o comando pg_restore com a flag --ignore-errors. Exemplo:

pg_restore --dbname=your_database --ignore-errors backup_file.dump

Essa flag manda a ferramenta ignorar os erros e continuar. Claro, os dados nas partes corrompidas vão se perder, mas pelo menos uma parte pode ser recuperada.

Se funcionar, confere direitinho os dados restaurados no final e anota o que ficou faltando.

Usando dados parciais

Digamos que você tem um backup em formato SQL texto. Abre ele num editor de texto (de preferência um mais top, tipo Visual Studio Code ou Notepad++) pra ver onde ele foi cortado. Se o arquivo tá legível e a maioria dos comandos SQL tá ok:

1. Remove a parte corrompida do arquivo.
2. Executa o resto dos comandos SQL na mão ou com o psql:

psql -U username -d database_name -f partial_backup.sql

Lendo arquivo em formato custom

Se o backup tá no formato custom, dá pra tentar extrair o conteúdo por partes:

pg_restore --list backup_file.dump > file_list.txt

Esse comando gera uma lista de todos os objetos do backup. Depois, você pode tentar restaurar só alguns itens (tipo tabelas ou schemas) com:

pg_restore --dbname=your_database --use-list=file_list.txt backup_file.dump

Editando o file_list.txt, dá pra pular os itens corrompidos na restauração.

Tentando restaurar via logs de arquivo (WAL)

Se você usa backups incrementais ou diferenciais (tipo com pg_basebackup), provavelmente tem logs de arquivo (WAL files). Eles guardam tudo que mudou desde o último backup. Pra recuperar os dados, você pode:

1. Achar o último backup inteiro (tipo, um full backup).
2. Apontar pro PostgreSQL onde estão os arquivos WAL:

   restore_command = 'cp /path/to/wal_directory/%f %p'

3. Rodar a restauração.

Usando ferramentas de terceiros

Às vezes, dá pra minimizar o estrago com utilitários de recuperação de arquivos. Um dos mais conhecidos é o ddrescue. Exemplo:

ddrescue --force backup_file.dump recovered_dump.file

Essa ferramenta tenta recuperar o máximo possível e cria uma nova cópia do arquivo.

Evitando corrupção de backups

Sim, lidar com arquivo corrompido é estressante. Bora pensar em como evitar isso.

Guardar cópias em vários lugares

Em backup, sempre vale a regra "não coloque todos os ovos na mesma cesta". Vale duplicar seus backups:

• No servidor local.
• Na nuvem (Amazon S3, Google Cloud Storage ou até um serviço simples tipo Dropbox).
• Em mídias externas (se você quiser ser super seguro).

Testar a integridade dos backups regularmente

No mundo de TI tem um ditado: "Backup que não foi testado não é backup". Testa seus backups de vez em quando, restaurando eles num servidor de teste. Pra isso:

1. Sobe o backup num servidor de teste.
2. Restaura os dados.
3. Confere se tá tudo certo.

Usar checksums

Quando criar backups, gera checksums dos arquivos (tipo com MD5 ou SHA256):

md5sum backup_file.dump > backup_file.md5

Na hora de restaurar, compara o checksum atual com o original:

md5sum -c backup_file.md5

Assim você descobre antes se o arquivo tá corrompido.

Exemplos de recuperação de backups corrompidos

Bora ver uns casos reais.

Caso 1. Erro ao transferir arquivo

Você transferiu o backup por FTP, mas percebeu que o arquivo ficou menor do que deveria. Você usou pg_dump em formato texto, então:

1. Abriu o arquivo no editor.
2. Removeu a parte corrompida dos dados.
3. Restaurou a parte boa do arquivo com psql.

Caso 2. Perda parcial de dados nos WAL

Seu servidor usava backups incrementais e arquivos WAL. De repente, alguns arquivos sumiram. Mas você conseguiu recuperar os dados com pg_basebackup e os WAL que sobraram, apontando o caminho deles na config de restauração.

Lembra: backup não é só criar cópia, é testar também. Não espera o apocalipse pra descobrir que seu backup não serve pra nada. E se o backup corromper, não pira: o PostgreSQL tem várias formas de recuperar seus dados. O importante é agir rápido e com calma!

E se nada der certo — volta lá no primeiro item dessa aula.