fbrescue

internal Firebird consistency check (decompression overran buffer (179))

A mensagem completa costuma ser internal Firebird consistency check (decompression overran buffer (179), file: sqz.cpp line: ...), em uma consulta, no gbak ou no gfix -v.

O que significa

O Firebird guarda cada registro comprimido com uma codificação simples de repetições (run-length). Quando ele descomprime um registro e o resultado não cabe no layout do registro, os bytes gravados estão danificados: por um disco com defeito, uma cópia malfeita, uma queda no meio de uma gravação ou uma página sobrescrita com outra coisa. O motor interrompe o comando que tocou no registro, então um SELECT ou um backup dessa tabela falha sempre no mesmo ponto. Os outros registros da tabela geralmente estão bons.

Primeiro: faça uma cópia e trabalhe só na cópia

Pare o servidor Firebird ou, no mínimo, garanta que nada esteja conectado ao banco. Depois copie o arquivo, junto com o arquivo .delta ao lado dele, se houver (um bloqueio do nbackup), e os arquivos secundários de um banco multiarquivo. Uma cópia feita enquanto o servidor grava no arquivo fica inconsistente, e toda tentativa de reparo altera o arquivo em que é executada. Se o próprio disco está falhando, copie o arquivo para outro disco antes de qualquer coisa.

Depois: tente as ferramentas do próprio Firebird

Elas vêm com toda instalação do Firebird e muitas vezes recuperam o banco inteiro: índices, triggers, usuários e tudo mais. Na cópia:

gfix -v -full -n copia.fdb              # valida, só relata
gfix -mend -full -ignore copia.fdb      # faz o gbak pular registros danificados
gbak -b -v -ig -g copia.fdb copia.fbk   # backup: sem checksums, sem coleta de lixo
gbak -c -v copia.fbk restaurado.fdb     # restaura em um banco novo

Acrescente -user SYSDBA -password ... conforme o seu servidor exigir. Se o gbak -b terminar, o banco restaurado é o resultado: confira a quantidade de linhas das tabelas importantes. O gfix -mend descarta os registros que não consegue ler, então compare com o original antes de confiar na cópia restaurada.

O gfix -mend é a resposta do motor justamente para este erro: ele marca o registro danificado para que o próximo backup o pule.

Se o gbak ainda falhar: extraia os dados com o fbrescue

O fbrescue é uma ferramenta gratuita e de código aberto (licença MIT) para bancos Firebird 2.5–5.0. Ele lê o arquivo do banco diretamente, sem o motor do Firebird, e exporta todas as linhas que consegue ler. Não para no primeiro registro ou página danificada e nunca grava no arquivo. Baixe o executável para o seu sistema em Releases: Windows, Linux, macOS; não precisa instalar nada.

fbrescue scan copia.fdb                                # o que está danificado, por tabela
fbrescue export copia.fdb --out resgate --format sql   # schema.sql + INSERTs por tabela

Também existem --format csv e --format jsonl. As linhas que não puderam ser lidas ficam listadas em resgate/_errors.jsonl, com a página e o motivo, e o código de saída é 2 quando algo ficou de fora. Para carregar o resultado em um banco novo:

isql -ch UTF8 -i resgate/schema.sql novo.fdb
isql -ch UTF8 -i resgate/CLIENTES.sql novo.fdb  # e assim por diante, para cada tabela

Se o texto sair ilegível, o banco provavelmente guarda texto em CHARACTER SET NONE: informe a codificação real, em geral --charset WIN1252 ou --charset ISO8859_1 em programas brasileiros.

Se quiser ajuda, abra uma issue e anexe a saída de fbrescue report copia.fdb: ela descreve o dano sem nenhum dos seus dados, e com os nomes de tabelas e colunas trocados por números. Pode escrever em português.

Neste erro o fbrescue lê todos os registros da tabela, lista em _errors.jsonl os que não descomprimem, com página e linha, e exporta o resto. Um registro que continua em outra página (registros maiores que uma página) só se perde se um dos seus pedaços estiver danificado.

Veja também