PostgreSQL armazena todos os dados em páginas de 8KB — e entender essa estrutura de páginas é o que torna a recuperação forense possível mesmo sem pg_dump e sem o banco precisar subir. A recuperação forense do PostgreSQL com páginas de 8KB funciona porque cada página tem uma estrutura fixa e bem documentada que permite leitura direta, sem depender do motor do banco. Além disso, esse conhecimento explica por que o pg_resetwal — a ferramenta de “último recurso” do PostgreSQL — frequentemente destrói dados que a forense ainda conseguiria salvar. Por isso, entender a estrutura interna do PostgreSQL é o primeiro passo antes de qualquer ação de recuperação.

A estrutura de páginas do PostgreSQL

O PostgreSQL organiza todos os dados em um cluster — um diretório definido pela variável PGDATA. Dentro desse diretório, cada tabela e índice corresponde a um ou mais arquivos físicos numerados pelo OID (Object Identifier) do objeto.

Cada arquivo de tabela é uma sequência de páginas de 8KB — 8.192 bytes exatos. Além disso, cada página tem uma estrutura interna fixa composta por três partes.

Cabeçalho da página (24 bytes): contém o LSN (Log Sequence Number) da última modificação, flags de status, ponteiros para os dados e o checksum. Por isso, a leitura do cabeçalho permite identificar em qual estado a página está — intacta, corrompida ou zerada — sem precisar do motor do PostgreSQL.

Área de tuplas: contém os registros de dados armazenados na página. Além disso, cada tupla começa com um cabeçalho de tupla que registra informações de visibilidade de transação — xmin e xmax — que a recuperação forense usa para identificar registros válidos versus deletados.

Item array: localizado no final da página, é uma tabela de offsets que aponta para cada tupla dentro da área de dados. Portanto, o item array é o que permite navegar pelos registros de uma página sem ler o arquivo inteiro. Para ver como isso se aplica na prática de recuperação, veja recuperação de banco de dados sem backup.

Por que o pg_resetwal destrói o que a forense recuperaria

Quando o PostgreSQL não sobe com erro de pg_control corrompido, a documentação oficial menciona o pg_resetwal como opção. Contudo, essa ferramenta redefine o WAL e força o cluster a iniciar mesmo com inconsistências — e o custo é alto.

O pg_resetwal zera o estado de visibilidade das transações. Além disso, ele não toca diretamente nas páginas de dados — mas ao reiniciar o cluster após o pg_resetwal, o PostgreSQL considera todos os registros com estado de transação indefinido como invisíveis, tratando-os como se não existissem.

Por isso, um dump feito após o pg_resetwal pode vir vazio ou com apenas uma fração dos dados — mesmo que as páginas físicas estejam intactas nos arquivos de tablespace. A recuperação forense, ao contrário, lê as páginas diretamente e extrai os registros independentemente do estado do WAL.

Como a recuperação forense do PostgreSQL funciona página a página

A Crowdertech não depende do motor do PostgreSQL para acessar os dados. Portanto, bancos que não sobem, que reportam corrupção ou que tiveram o pg_control corrompido são tratados da mesma forma.

Mapeamento via catálogo do sistema: as definições de todas as tabelas — nomes de colunas, tipos de dados, OIDs — ficam nas tabelas do sistema (pg_class, pg_attribute, pg_type) dentro da tablespace pg_default. A Crowdertech lê essas tabelas por forense para reconstruir o esquema sem o banco precisar subir.

Leitura página a página: cada arquivo de tabela é percorrido página a página — 8KB por vez. Além disso, a Crowdertech verifica o checksum de cada página quando disponível e identifica quais páginas estão íntegras, quais estão corrompidas e quais estão zeradas.

Extração de tuplas: os registros são extraídos do item array de cada página íntegra. Por isso, mesmo quando um arquivo tem páginas corrompidas intercaladas com páginas íntegras, a recuperação extrai o máximo possível de cada arquivo. Para casos urgentes, o atendimento da Crowdertech é 24 horas na Vila Olímpia.

Situações em que a recuperação forense é a única opção

pg_control corrompido: o arquivo global/pg_control contém o estado do cluster. Quando corrompe, o PostgreSQL não inicia. Contudo, os dados nas páginas dos tablespaces permanecem intactos — a forense os acessa diretamente.

WAL perdido ou corrompido: os arquivos WAL são necessários para o recovery do PostgreSQL. Quando desaparecem ou corrompem, o banco para na fase de recovery. Além disso, transações já aplicadas às páginas de dados sobrevivem mesmo com o WAL perdido.

Tablespace com páginas corrompidas: o erro invalid page in block X indica que páginas específicas estão corrompidas — não o arquivo inteiro. A forense extrai dados das páginas íntegras e documenta quais registros específicos foram afetados.

Perguntas frequentes

PostgreSQL que não sobe com erro de pg_control tem recuperação sem pg_resetwal? Sim. A Crowdertech reconstrói o estado do cluster por forense sem usar pg_resetwal. Além disso, os dados nas tablespaces ficam intactos e acessíveis pela leitura direta de páginas.

PostgreSQL com erro “invalid page in block” perde todos os dados? Não. O erro indica páginas específicas corrompidas — não o arquivo inteiro. A Crowdertech extrai os dados das páginas íntegras e documenta quais blocos foram afetados.

Quanto tempo leva a recuperação de PostgreSQL por forense? O diagnóstico é entregue em horas. A recuperação completa leva de 24 a 72 horas dependendo do tamanho do banco e do grau de corrupção.

Conclusão

A estrutura de páginas de 8KB do PostgreSQL é o que torna a recuperação forense possível sem pg_dump e sem o banco precisar subir. Além disso, entender essa estrutura explica por que pg_resetwal é perigoso e por que a forense consegue recuperar onde o motor falha. Em resumo, preserve o cluster, não execute pg_resetwal e acione especialistas. A Crowdertech recupera PostgreSQL página a página — (11) 99630-0675.

Fontes: PostgreSQL Documentation · NIST SP 800-86.