Recuperar uma base de dados MySQL, PostgreSQL ou MongoDB corrompida em 2026: procedimentos passo a passo

A recuperação de bases de dados representa uma das disciplinas mais delicadas da recuperação de dados. Ao contrário dos ficheiros individuais, em que o desafio é binário (recuperado ou não), uma base de dados corrompida pode parecer intacta no arranque enquanto contém inconsistências silenciosas — índices dessincronizados, restrições violadas, transações aplicadas parcialmente — que só se manifestam semanas depois sob a forma de erros de aplicação ou contas financeiras erradas. Este artigo documenta o procedimento completo de recuperação para MySQL, PostgreSQL e MongoDB, com ferramentas nativas, ferramentas de terceiros especializadas, expectativas de recuperação e limiares para encaminhar para um laboratório profissional.

Três DBMS dominam o segmento open source de consumo e PME em 2026: MySQL/MariaDB, PostgreSQL (em crescimento constante) e MongoDB (o principal document store NoSQL). Cada um adota uma arquitetura de armazenamento radicalmente diferente — InnoDB e os seus ficheiros .ibd, PostgreSQL e o seu base/ com WAL separados, MongoDB e o seu motor WiredTiger com coleções .wt — que exige procedimentos de recuperação específicos. Nenhuma ferramenta generalista de recuperação de ficheiros (EaseUS, PhotoRec, Recuva) é suficiente aqui.

Afiliação transparente. A Save My Disk recebe uma comissão se adquirir uma licença através dos links EaseUS presentes neste artigo. O EaseUS atua apenas ao nível do sistema de ficheiros — para a recuperação dos ficheiros .ibd, base/, .wt que alojam a base de dados. Para a recuperação transacional em si (innodb_force_recovery, pg_resetwal, mongod --repair), citamos exclusivamente ferramentas DBMS nativas ou o Stellar Repair segundo a nossa metodologia pública.

MySQL e MariaDB: innodb_force_recovery e mysqldump forense

O motor de armazenamento InnoDB do MySQL 8.0.x e do MariaDB 11.x armazena os dados em ficheiros .ibd, um por tabela (file-per-table por predefinição desde o MySQL 5.6) ou num tablespace partilhado ibdata1. Índices, restrições de chave estrangeira e triggers residem nos ficheiros .frm (até ao MySQL 5.7) ou no dictionary do InnoDB (desde o MySQL 8.0). O binary log (binlog) regista todas as modificações para replicação e point-in-time recovery.

A corrupção típica do InnoDB traduz-se num crash no arranque com, no ficheiro error.log, uma mensagem InnoDB: Database page corruption on disk ou uma leitura falhada do ficheiro na page X. O procedimento padrão explora o parâmetro innodb_force_recovery, que assume valores inteiros de 0 (modo normal) a 6 (modo forense máximo). Cada incremento desativa uma proteção:

• 1 desativa a verificação de páginas corrompidas (perda mínima)
• 2 desativa o purge thread (pode deixar transações zombie)
• 3 desativa o rollback de transações (as alterações parciais persistem)
• 4 desativa o merge do insert buffer (inconsistências de índices)
• 5 desativa o redo log (perda de transações não em checkpoint)
• 6 desativa a crash recovery no arranque (corrupção grave ignorada)

Os níveis de 1 a 3 resolvem a grande maioria dos casos, com o nível 1 sozinho a cobrir muitos. A partir do nível 3, a exportação imediata através de mysqldump --all-databases --routines --triggers --single-transaction continua a ser o único caminho seguro — qualquer escrita adicional arrisca uma corrupção irreversível.

A ferramenta Stellar Repair for MySQL 7 (lançada em março de 2026, 299 $) oferece uma análise forense offline dos ficheiros .ibd que complementa o innodb_force_recovery nos casos em que o servidor já não arranca de todo. Recupera uma grande parte das linhas a partir de ficheiros .ibd corrompidos com o cabeçalho de página intacto.

PostgreSQL: pg_resetwal, point-in-time recovery e standby

O PostgreSQL 16.x, lançado em setembro de 2023, armazena os seus dados numa estrutura data/base/<dbOID>/ com um ficheiro por tabela identificado pelo OID. Os Write-Ahead Logs (WAL) em pg_wal/ registam cada modificação antes do commit e permitem o point-in-time recovery (PITR). O checkpoint regular esvazia os WAL antigos e sincroniza os ficheiros de dados.

A corrupção do PostgreSQL assume três formas principais. Primeiro cenário: crash durante uma escrita que deixa um WAL incompleto. No reinício, o PostgreSQL reproduz o WAL e encontra um estado consistente. Na maioria dos casos, não é necessária qualquer intervenção manual — o replay automático do WAL do PostgreSQL trata disso.

Segundo cenário: corrupção de uma página de tabela identificada pela mensagem PANIC: corrupted item pointer. O procedimento exige zero_damaged_pages = on no ficheiro postgresql.conf no arranque, o que marca as páginas corrompidas como vazias em vez de abortar. Os dados nessas páginas perdem-se — a opção só permite arrancar para exportar o resto.

Terceiro cenário: impossibilidade de arrancar mesmo com zero_damaged_pages. É o caso em que o pg_resetwal intervém. A documentação postgresql.org insiste: o pg_resetwal é uma operação de último recurso que pode causar a perda de dados não em checkpoint e inconsistências. Execute-o numa CÓPIA da diretoria de dados, nunca em produção.

Para implementações PostgreSQL com standby em streaming replication (configuração recomendada em produção desde o PostgreSQL 12), o procedimento de recuperação torna-se trivial: promova o standby a primary através de pg_ctl promote e depois reconstrua um novo standby a partir do novo primary. Nenhum pg_resetwal necessário, nenhuma perda de dados. É por isso que a maioria dos incidentes PostgreSQL em contextos de produção bem arquitetados se resolve sem qualquer recuperação forense.

MongoDB WiredTiger: --repair, replica set e dump de coleções

O MongoDB 7.0, lançado em agosto de 2023, utiliza exclusivamente o motor de armazenamento WiredTiger (o antigo motor MMAPv1 foi removido desde o MongoDB 4.2). As coleções são armazenadas em ficheiros .wt por coleção, com um journal WiredTiger separado para a durabilidade. Os replica sets duplicam os dados em pelo menos 3 nós com um oplog para sincronização.

A corrupção do WiredTiger manifesta-se tipicamente como um crash no arranque do mongod com a mensagem WT_PANIC: WiredTiger library panic ou Detected unclean shutdown - this should only occur if the storage volume was corrupted. O procedimento --repair executa três operações: verificação de cada página WiredTiger, reconstrução de índices e remoção de documentos corrompidos.

mongod --repair --dbpath /var/lib/mongodb

Este procedimento pode demorar de 20 minutos para uma base de dados de 50 GB a várias horas para uma base de dados multi-TB. A documentação MongoDB Manual Repair afirma que o --repair pode eliminar documentos permanentemente — a cópia completa do dbpath não é negociável antes de iniciar.

Para os replica sets, a estratégia muda radicalmente. O primary corrompido deve ser removido do set (rs.remove("primary:27017")), um secondary saudável promovido (rs.stepDown() no primary problemático força uma eleição) e, depois, o nó corrompido reconstruído através de initial sync. Esta abordagem evita qualquer recurso ao --repair e preserva a consistência transacional ACID do replica set.

Comparação das ferramentas de terceiros para bases de dados corrompidas

Quando as ferramentas nativas (innodb_force_recovery, pg_resetwal, --repair) não bastam, intervêm várias ferramentas de terceiros especializadas. Eis as quatro principais.

Para o PostgreSQL, nenhuma ferramenta de terceiros paga iguala as ferramentas nativas (pg_resetwal, pg_filedump, pg_dirtyread). Os administradores PostgreSQL experientes trabalham exclusivamente com estas ferramentas + uma estratégia robusta de streaming replication.

Laboratório profissional: limiares de encaminhamento e custos em 2026

Quatro situações impõem o encaminhamento para um laboratório especializado em bases de dados em vez de uma tentativa interna. Primeiro: Transparent Data Encryption (TDE) MS SQL Server com chaves OEM perdidas. Segundo: Oracle Database com ASM corrompido, que exige competências certificadas de DBA Oracle. Terceiro: cluster multi-região Cassandra ou ScyllaDB com corrupção do Merkle tree. Quarto: volume físico em falha que impede a clonagem por software da diretoria de dados — encaminhe para um laboratório de hardware para recuperação de SSD/HDD/NVMe antes de qualquer procedimento DBMS.

Os laboratórios especializados em bases de dados em 2026 incluem Ontrack Database Recovery Services (EUA, Reino Unido, Alemanha), DriveSavers Database Specialist Team (EUA), Stellar Data Recovery Database Services (Índia, presença global), Recoveo Database (Polónia) e Kroll Ontrack Forensics Database (forense legal). Preços públicos observados em maio de 2026:

• MySQL ou PostgreSQL de consumo / PME: 1.200 a 3.500 € (diagnóstico fixo + recuperação + restauro)
• Replica set MongoDB WiredTiger: 3.500 a 9.000 € (consoante o volume e o número de shards)
• MS SQL Server empresarial: 5.500 a 16.000 € (MDF/LDF corrompidos, TDE ativo)
• Oracle Database empresarial: 9.000 a 28.000 € (ASM, RAC, RMAN forense)
• Cluster Cassandra / ScyllaDB: 8.000 a 22.000 € (reconstrução do Merkle tree, multi-região)

Consulte o nosso guia BitLocker para as especificidades da encriptação com chaves OEM Microsoft. Para NAS que alojam bases de dados dockerizadas corrompidas, consulte o nosso guia de recuperação RAID.

Estratégia de prevenção 2026: a única verdadeira linha de defesa

A grande maioria dos casos de recuperação de bases de dados teria sido evitada ou resolvida em menos de 30 minutos se três práticas estivessem em vigor. Primeiro: backup lógico diário (mysqldump, pg_dump, mongodump) em armazenamento remoto, testado por um restauro mensal. Segundo: backup físico horário (Percona XtraBackup, pg_basebackup, MongoDB Cloud Backup) com snapshot ZFS ou Btrfs da diretoria de dados. Terceiro: streaming replication ou replica set com pelo menos 2 nós secondary em armazenamento independente.

Para orçamentos limitados, o mínimo vital continua a ser um mysqldump/pg_dump/mongodump diário para armazenamento S3 encriptado + teste de restauro mensal numa instância de staging. Esta estratégia basta para transformar um incidente catastrófico num simples inconveniente de 2 horas.

FAQ — Perguntas frequentes sobre a recuperação de bases de dados

O MySQL InnoDB não arranca: que innodb_force_recovery usar?

Sempre innodb_force_recovery=1 primeiro. Os níveis de 1 a 3 são suficientes na grande maioria dos casos. A partir do 4, exporte imediatamente com mysqldump --all-databases sem escrever.

O PostgreSQL não arranca após um crash: o pg_resetwal é a solução?

Não como primeira opção. O pg_resetwal pode causar a perda de dados committados. Antes de tudo, experimente o pg_basebackup a partir do standby, verifique os arquivos WAL, explore os backups físicos. Se inevitável, numa CÓPIA nunca em produção.

O MongoDB --repair funciona no WiredTiger 7.0.x?

Sim, mas com limites. Pode eliminar permanentemente coleções inacessíveis — faça primeiro o backup completo do dbpath. Para replica sets, parar o primary corrompido e restaurar a partir de um secondary saudável através de initial sync é mais seguro.

Diferença entre a recuperação de uma base de dados e a recuperação clássica de um sistema de ficheiros?

Três diferenças: (1) índices, restrições e triggers internos que só as ferramentas DBMS reconstroem; (2) formatos binários proprietários versionados (.ibd, .wt, base/); (3) transações ACID que exigem binlog, WAL, oplog intactos.

Quanto custa a recuperação profissional de uma base de dados em 2026?

MySQL/PostgreSQL de consumo: 1.200-3.500 €. MongoDB WiredTiger: 3.500-9.000 €. MS SQL Server: 5.500-16.000 €. Oracle empresarial: 9.000-28.000 €. Cluster Cassandra: 8.000-22.000 €. Ferramentas de terceiros: Stellar 299-599 $, EaseUS MS SQL 299 $.

Veredito: prevenção transacional primeiro, recuperação forense em segundo plano

A recuperação de bases de dados em 2026 continua assimétrica: a prevenção (backups testados + standby de replicação + monitorização proativa) custa uma pequena fração do tempo de um DBA e resolve a esmagadora maioria dos incidentes em minutos. A recuperação forense sem prevenção custa entre 1.200 € e 28.000 € consoante o DBMS e a complexidade.

Para MySQL e MariaDB, a combinação Percona XtraBackup diário + binlog ativado + mysqldump --single-transaction semanal basta para cobrir a esmagadora maioria dos cenários. Para PostgreSQL, a streaming replication com 1 standby síncrono e 1 standby assíncrono + pg_basebackup semanal continua a ser o padrão de referência de 2026. Para MongoDB, um replica set com pelo menos 3 nós, backups mongodump diários e MongoDB Cloud Backup mensal é obrigatório.

Quando a recuperação se torna inevitável, a regra absoluta é uma linha: trabalhar sempre numa cópia da diretoria de dados, nunca na produção de origem. Esta simples precaução é o que separa uma recuperação limpa de uma perda total: trabalhar a partir de um clone correto protege os dados, enquanto executar o procedimento diretamente na produção corrompida arrisca perder tudo.