O Microsoft SQL Server é o SGBD mais utilizado em ambientes corporativos brasileiros e também um dos mais complexos de recuperar quando corrompido. A corrupção pode ocorrer em múltiplos níveis: corrupção de página de dados (8KB), corrupção do arquivo de log de transações (.LDF), falha do header do arquivo MDF ou corrupção do boot page (página 9).
Quando o banco entra em modo suspect, o SQL Server detectou inconsistência durante o processo de recuperação automática (roll-forward/rollback de transações pendentes) e marcou o banco como inutilizável. O erro típico no Event Log é:
Outros erros críticos do SQL Server que tratamos: Error 824 (corrupção lógica), Error 825 (falha de I/O corrigida por retry), DBCC CHECKDB com erros de alocação, Cannot open database - error 945 e Log file incompatible - error 9003.
ALTER DATABASE SET EMERGENCY + DBCC CHECKDB com REPAIR_ALLOW_DATA_LOSS. Usado como último recurso — pode causar perda de dados mas restaura a acessibilidade.
Leitura direta das páginas de dados (8KB cada) do arquivo MDF sem passar pelo motor do SQL Server. Permite extrair dados mesmo quando o banco não abre.
Quando o LDF está corrompido ou foi deletado, reconstruímos um log mínimo para permitir o attach do MDF. Técnica usada quando DBCC indica log incompatível.
Identificação e restauração de páginas individuais corrompidas a partir de backups parciais, mantendo o restante do banco operacional em produção.
A corrupção em Oracle se manifesta de diferentes formas: corrupção de datafile (os arquivos .dbf que compõem o tablespace), corrupção de redo log (arquivos .log que garantem a durabilidade das transações) e falha do control file (que contém o mapa de todos os arquivos do banco).
Erros típicos de Oracle que recuperamos:
Para Oracle, utilizamos RMAN (Recovery Manager) com técnicas de block media recovery, reconstituição de control file via trace, extração de dados com Data Pump (expdp) em modo de emergência e leitura direta de segmentos de tablespace quando o banco não abre.
O MySQL/MariaDB armazena dados em duas estruturas principais para tabelas InnoDB: o arquivo .frm (definição da tabela — schema) e o arquivo .ibd (dados propriamente ditos no tablespace dedicado). O arquivo ibdata1 contém o dicionário interno do InnoDB, rollback segments e double-write buffer.
Erros comuns que indicam corrupção em MySQL:
Nossa metodologia: configurar innodb_force_recovery=1..6 de forma progressiva, usar mysqlcheck, myisamchk e InnoDB Recovery Toolbox para extração direta de páginas, e reconstruir o schema a partir dos arquivos .frm para importação em nova instância limpa.
O PostgreSQL organiza dados em heap files (arquivos de tabela com páginas de 8KB), complementados pelo Write-Ahead Log (WAL) para garantia de durabilidade. A corrupção do WAL é especialmente crítica pois impede o processo de recovery do servidor.
Erros típicos em PostgreSQL:
Para PostgreSQL utilizamos pg_resetwal (com cautela — zera estatísticas de transação), leitura direta de heap files via pageinspect extension, extração com pg_filedump para análise de páginas corrompidas e reconstrução de catálogo do sistema.
O MongoDB usa o storage engine WiredTiger por padrão (desde v3.2). Os dados são armazenados em arquivos .wt (collections) e .wti (índices), com um arquivo de metadados WiredTiger.wt e logs de journal em WiredTigerLog.0000000001.
Cenários comuns: queda de energia durante write sem journaling habilitado, corrupção do WiredTiger.wt (metadados), inconsistência entre journal e collection files. Utilizamos wt salvage para recuperar collections individuais e extração BSON direta para reconstrução em nova instância.
Diagnóstico gratuito em até 2 horas. Cobrança somente com resultado confirmado. Não tome decisões sem antes falar com um especialista.
Na maioria dos casos, sim. Trabalhamos com uma cópia do arquivo MDF/ibd/dbf sem afetar a instância de produção. Para SQL Server, por exemplo, extraímos os dados diretamente das páginas do MDF corrompido enquanto o servidor original permanece operacional com o que ainda funciona.
Não execute DBCC CHECKDB com REPAIR_ALLOW_DATA_LOSS sem diagnóstico prévio — isso pode causar perda de dados desnecessária. O correto é: 1) Fazer backup do arquivo MDF/LDF como estão; 2) Verificar o Event Log do Windows para o erro exato; 3) Tentar acesso em modo de emergência; 4) Se não resolver, enviar os arquivos para diagnóstico especializado.
Para SQL Server: arquivos .mdf e .ldf. Para Oracle: todos os datafiles .dbf do tablespace afetado + control files. Para MySQL: pasta completa do schema (com .frm e .ibd) + ibdata1. Para PostgreSQL: pasta data/ completa incluindo pg_wal. O diagnóstico identifica quais dados são recuperáveis antes de qualquer cobrança.
Sim. Trabalhamos com arquivos .bak do SQL Server corrompidos, dumps MySQL/PostgreSQL incompletos e backups Oracle RMAN parciais. Em muitos casos, parte das páginas do backup ainda está íntegra e pode ser extraída, resultando em recuperação parcial mas significativa dos dados.
Distribuidora com SQL Server 2019 entrou em modo suspect após interrupção de energia no meio de uma transação de fechamento de estoque. O arquivo MDF de 380GB apresentava corrupção na boot page (página 9) e em 23 páginas de dados adicionais. Solução: reconstrução da boot page, extração direta das páginas íntegras, reimportação em nova instância. 100% dos dados recuperados em 18 horas.
Banco de sistema financeiro com Oracle 19c apresentou ORA-01578 em datafile do tablespace DADOS após falha de storage. O redo log online estava corrompido, impedindo o recovery automático. Utilizamos block media recovery via RMAN com blockrecover para os blocos individuais corrompidos, mantendo os demais tablespaces online durante todo o processo. Downtime zero para os sistemas que usavam outros tablespaces.
Administrador executou limpeza de disco e deletou o ibdata1 de um MySQL 8.0 em produção, acreditando ser um arquivo de log antigo. Sem o ibdata1, nenhuma tabela InnoDB era acessível. Como o servidor Linux não havia sobrescrito o inode do arquivo (ainda em memória pelo processo mysqld), foi possível recuperar o arquivo pelo /proc/{PID}/fd antes de reiniciar o servidor. 100% de recuperação em 2 horas.
| SGBD | Arquivo de Dados | Log de Transações | Tamanho de Página |
|---|---|---|---|
| SQL Server | .mdf / .ndf | .ldf | 8 KB |
| Oracle | .dbf (datafiles) | redo logs .log | 2–32 KB (configurável) |
| MySQL InnoDB | .ibd / ibdata1 | ib_logfile0/1 | 16 KB |
| PostgreSQL | base/{OID}/{relfilenode} | pg_wal/*.wal | 8 KB |
| MongoDB | {collection}.wt | WiredTigerLog.* | 4 KB (WiredTiger) |
| Firebird | .fdb / .gdb | Shadow files | 4–16 KB |
Ambientes de produção modernos usam soluções de HA que adicionam camadas de complexidade à recuperação:
Em Availability Groups, a corrupção pode ocorrer em apenas uma réplica (primária ou secundária). Identificamos qual réplica está íntegra, forçamos o failover para ela e reconstruímos a réplica corrompida. Se ambas estiverem comprometidas, trabalhamos diretamente nos arquivos MDF/LDF.
O Oracle RAC compartilha os mesmos datafiles entre múltiplos nós. Corrupção de datafile em RAC exige coordenação — todos os nós devem ser considerados. Usamos RMAN com catalogue para recuperação coordenada, garantindo consistência entre instâncias.
Em clusters Galera (MariaDB/MySQL), corrupção em um nó pode se propagar para os demais via SST (State Snapshot Transfer) se o nó corrompido for tratado como fonte. Isolamos o nó afetado antes de qualquer operação de recovery.
A replicação por streaming do PostgreSQL pode estar algumas transações atrás do primário. Em caso de corrupção, verificamos o ponto de consistência do standby antes de promovê-lo, evitando promover uma réplica com dados incompletos.
| SGBD | Código de Erro | Descrição | Recuperabilidade |
|---|---|---|---|
| SQL Server | Error 823 | I/O error — CRC mismatch na leitura | Alta |
| SQL Server | Error 824 | Corrupção lógica — página com conteúdo inválido | Alta |
| SQL Server | Error 9003 | Log file incompatível — LSN inválido | Média |
| SQL Server | Error 945 | Database cannot be opened due to inaccessible files | Alta |
| Oracle | ORA-01578 | Oracle data block corrupted (file # X, block # Y) | Alta |
| Oracle | ORA-00600 | Internal error — kernel exception | Média |
| Oracle | ORA-01194 | File needs more recovery to be consistent | Alta |
| MySQL | InnoDB: page corruption | Página InnoDB com checksum inválido | Alta |
| PostgreSQL | invalid page header | Página com header corrompido ou zerado | Alta |
| PostgreSQL | could not locate valid checkpoint | WAL corrompido sem checkpoint válido | Média |
Não é incomum que o backup seja a única cópia dos dados — e ele também estar corrompido. Trabalhamos com:
Arquivos .bak do SQL Server têm formato interno próprio com múltiplos data streams. Corrupção parcial não invalida o arquivo inteiro — extraímos os data streams íntegros e reconstruímos o banco com o que está disponível. Taxa de sucesso: 60–90% dependendo da posição da corrupção.
Dumps gerados por mysqldump ou pg_dump podem ser interrompidos deixando o arquivo incompleto. Identificamos o ponto de corrupção, extraímos os INSERTs válidos e importamos em nova instância, ignorando statements inválidos. Recuperação de 70–95% dos dados na maioria dos casos.
Backupsets do RMAN são compostos por múltiplos backup pieces. Corrupção em um piece não invalida os demais. Usamos o catálogo RMAN para identificar quais pieces estão íntegros e reconstruímos o banco com os datafiles recuperáveis, usando RMAN RESTORE e RECOVER com o que está disponível.
Nobreak com autonomia mínima de 15 minutos para shutdown gracioso. Servidores de BD nunca devem perder energia abruptamente — a causa número 1 de corrupção de página.
DBCC CHECKDB semanal no SQL Server. RMAN VALIDATE em Oracle. mysqlcheck periódico no MySQL. Não basta fazer backup — é preciso verificar que ele é restaurável.
Configure exclusões de antivírus para as pastas de dados do SGBD. Scans em tempo real de arquivos MDF, LDF e ibd causam corrupção por interferência em I/O em momentos críticos.
O diagnóstico é gratuito. O valor do serviço depende do tamanho do banco, complexidade da corrupção e urgência. O orçamento é emitido somente após confirmação de viabilidade de recuperação. A Crowdertech opera no modelo "no data, no charge" — você só paga após validar os dados recuperados.
Sim. O arquivo LDF é o log de transações — sem ele, o SQL Server não consegue realizar o processo de recovery automático. Nossa solução: reconstruímos um arquivo de log mínimo compatível que permite o attach do MDF. Este processo funciona quando o MDF está em estado consistente, mesmo sem o LDF correspondente. Para MDFs que estavam com transações pendentes no momento da falha, extraímos os dados diretamente das páginas.
O SQL Server marca um banco como SUSPECT quando detecta inconsistência durante o processo de recuperação automática ao inicializar. Isso geralmente ocorre após queda de energia, falha de disco ou corrupção do arquivo MDF/LDF. Não execute REPAIR_ALLOW_DATA_LOSS sem diagnóstico prévio. Nossa abordagem correta: imagem forense dos arquivos → diagnóstico de integridade → extração dos dados íntegros → rebuild do banco em nova instância.
Sim, em muitos casos. Em SQL Server, registros deletados permanecem nas páginas de dados até que o espaço seja reutilizado. Lemos as páginas MDF diretamente e extraímos registros marcados como deletados mas ainda presentes. Em Oracle, usamos Flashback Query e análise de undo segments. Em PostgreSQL, os registros deletados ficam como "dead tuples" até o VACUUM — recupramos via leitura direta de heap files. O sucesso depende do tempo decorrido e das operações feitas após a deleção.
Não necessariamente. Primeiro, classifique os erros: erro de alocação (allocation error) é mais grave que erro de consistência (consistency error). Para muitos cenários, é possível trabalhar em uma cópia do MDF sem parar a produção — reconstruímos a cópia, extraímos os dados corrompidos e reimportamos somente as partes problemáticas. A produção só precisa ser parada para a janela de cutover final, que pode ser de 30 minutos a algumas horas.
Sim. Para hospedagem compartilhada, solicitamos ao cliente o arquivo de backup (.sql, .gz) ou os arquivos físicos do MySQL (pasta data/). Em hosting cPanel, os backups automáticos frequentemente contêm cópias dos arquivos InnoDB. Recuperamos a partir do que estiver disponível — seja um dump incompleto ou os arquivos físicos .ibd/.frm exportados do servidor.
Diagnóstico gratuito · Sem downtime · Cobrança somente após resultado
O banco de dados raramente existe isolado — está integrado a sistemas de gestão empresarial que dependem de sua integridade para operar. A Crowdertech tem experiência em recuperação de dados em contexto de ERPs e sistemas críticos:
O Protheus usa DBF (xBase), SQL Server ou Oracle como backend. Em SQL Server, o banco SX (dicionário de dados) e os bancos de empresa (.MDF por CNPJ) precisam estar em sincronismo. Recuperamos MDF de empresa corrompido mantendo o dicionário intacto, preservando a estrutura de campos e tabelas customizadas.
SAP HANA usa storage em memória com persistência em volumes de dados e delta. Corrupção de persistence layer ou falha de volume pode tornar o sistema inacessível. Para SAP R/3 com backend Oracle/SQL Server, aplicamos recuperação diretamente nos datafiles do banco subjacente, com conhecimento da estrutura SAP (schemas SAPSR3, SAPAPJOBS etc.).
ERPs de médio porte como Senior Sistemas, Sankhya e Linx utilizam SQL Server como padrão. Recuperamos os bancos de dados corrompidos e, quando necessário, auxiliamos na reconfiguração da conexão do ERP após o restore em nova instância.
Domínio Contábil, Questor, ContaAzul e sistemas de emissão de NFe utilizam MySQL ou SQL Server. Prazos da Receita Federal (SPED, ECF, ECD) tornam a recuperação urgente. Atendemos com SLA de 24h para casos fiscais críticos com deadline de obrigações acessórias.
Em todos os SGBDs relacionais, os dados são armazenados em páginas (pages) de tamanho fixo — tipicamente 8KB no SQL Server e PostgreSQL, 16KB no MySQL InnoDB. Cada página tem uma estrutura previsível:
A estrutura previsível das páginas é o que torna a recuperação possível mesmo sem o sistema de arquivos funcional. Lemos o arquivo de dados diretamente, localizamos os page headers válidos (pelo magic number e estrutura), extraímos os data rows de cada página íntegra e reconstruímos as tabelas. Páginas corrompidas (checksum inválido) são ignoradas — o restante é recuperado.
RDS gerencia snapshots automáticos por 35 dias. Se o snapshot mais recente ainda está corrompido, trabalhamos com exports do S3 (Parquet) ou solicitamos ao cliente o export direto do RDS via Data Export para S3. Para recuperação de transações perdidas, analisamos os binlogs exportados.
Azure SQL mantém backups automáticos por 7-35 dias com point-in-time restore. Para dados deletados acidentalmente além do período de retenção, trabalhamos com exports BACPAC exportados antes do incidente ou com Temporal Tables se habilitadas.
Cloud SQL exporta para GCS em formato SQL ou CSV. Backups automáticos ficam disponíveis por 7 dias. Para recuperação além da janela de backup, analisamos os binary logs do Cloud SQL quando o log retention está habilitado.
| Ferramenta | SGBD | Uso |
|---|---|---|
| SQL Server Recovery Toolbox | SQL Server | Extração direta de páginas MDF corrompidas |
| ApexSQL Recover | SQL Server | Recuperação de transações do log LDF |
| RMAN + blockrecover | Oracle | Block media recovery granular por bloco |
| ODU (Oracle Data Unloader) | Oracle | Extração de dados sem instância funcional |
| InnoDB Recovery Toolbox | MySQL | Leitura direta de páginas InnoDB .ibd |
| pg_filedump | PostgreSQL | Dump e análise de heap files e índices |
| pageinspect (PG extension) | PostgreSQL | Inspeção de páginas individuais em SQL |
| wt salvage | MongoDB | Recuperação de collections WiredTiger |
Para empresas sujeitas a compliance (SOX, ISO 27001, LGPD, PCI-DSS, BACEN), a recuperação de dados não é suficiente — é necessário documentar o incidente e as medidas adotadas. A Crowdertech emite Laudo Técnico Forense contendo:
O caso mais frequente na Crowdertech — atendemos diariamente sistemas em Firebird
O Firebird é amplamente utilizado no Brasil em sistemas de gestão para pequenas e médias empresas — PDV, ERP, sistemas jurídicos, clínicas médicas e escritórios de contabilidade. Sua popularidade no mercado nacional vem da licença gratuita, baixo consumo de recursos e facilidade de distribuição. O banco inteiro fica em um único arquivo .fdb (Firebird Database) ou .gdb (formato legado do InterBase), o que simplifica o deployment mas também concentra o risco.
Esse modelo de arquivo único é ao mesmo tempo uma vantagem e uma vulnerabilidade: qualquer corrupção no arquivo afeta todas as tabelas. Ao mesmo tempo, permite que nossa equipe trabalhe em uma cópia isolada do .fdb sem necessidade de instância Firebird em execução — o que torna a recuperação mais segura e eficiente.
O arquivo .fdb é organizado em páginas de tamanho fixo — 1KB, 2KB, 4KB, 8KB ou 16KB, definido na criação do banco. As primeiras páginas têm funções críticas:
Corrupção na header page (página 0) ou em estruturas críticas de sistema. O Firebird não consegue abrir o banco. Corrigimos a header e reconstruímos os ponteiros de sistema.
Uma página de dados foi sobrescrita com conteúdo de tipo diferente (ex: blob em posição de index). Identificamos e isolamos as páginas corrompidas, extraindo os dados das páginas válidas.
Transação distribuída incompleta que ficou em estado indeterminado — nem committed nem rolled back. Resolvemos via gfix -commit ou -rollback com análise de qual estado é correto.
Falha de I/O no disco ao tentar ler o arquivo .fdb. Frequentemente indica setor defeituoso no HD. Criamos imagem setor a setor antes de qualquer operação, mapeando os setores ruins.
O security database (security3.fdb no Firebird 3.x) está corrompido ou inacessível. Reconstruímos o security database mantendo os usuários e senhas do banco de dados original.
Erro interno do engine Firebird ao detectar inconsistência grave. Geralmente acompanhado de um código numérico como (183), (294), (305). Cada código indica uma estrutura específica corrompida.
Checksum de página inválido ou ODS (On-Disk Structure) version incompatível. Pode ocorrer ao abrir banco Firebird 2.5 com servidor 3.x sem migração. Identificamos a versão real e aplicamos a conversão correta.
O gbak (ferramenta de backup/restore nativa) encontrou registro com tamanho inválido ao fazer backup. Indica corrupção em data page. Extraímos os dados ignorando os registros corrompidos.
Cópia bit-a-bit do arquivo antes de qualquer intervenção. Se o .fdb está em um HD com setores defeituosos, usamos ddrescue com mapa de setores — preservando o máximo de dados mesmo de HDs degradados. O arquivo original nunca é modificado.
gfix -validate -full -mend banco.fdb para validação completa e gstat -h banco.fdb para estado da header. Identificamos exatamente quais páginas e tabelas estão afetadas antes de qualquer tentativa de recuperação.
gbak -backup -garbage_collect -ignore banco.fdb banco.fbk — o parâmetro -ignore faz o gbak pular registros corrompidos em vez de abortar. Para Firebird 3.x, usamos também -skip_bad_data_pages.
Quando o gbak não consegue processar o banco, lemos diretamente as páginas do arquivo .fdb seguindo a especificação ODS (On-Disk Structure) do Firebird. Extraímos os data records de cada tabela individualmente, reconstruímos em um banco limpo e validamos a integridade referencial.
Restauramos o .fbk em banco novo, reativamos constraints e índices, executamos gfix -sweep -full para limpeza de transações antigas e validamos com o sistema cliente antes da entrega. O banco entregue é um .fdb limpo, abrindo normalmente no servidor Firebird do cliente.
O SGBD corporativo mais atendido — desde SQL Server 2000 até 2022
O Microsoft SQL Server domina o mercado de ERP corporativo no Brasil. Sistemas como TOTVS Protheus, SAP B1, Senior, Sankhya, Linx e dezenas de sistemas verticais usam SQL Server como backend. Isso significa que quando o SQL Server falha, todo o negócio para.
Um banco SQL Server é composto por ao menos dois arquivos físicos:
Contém as tabelas de sistema, o catálogo do banco e as primeiras páginas de dados de cada filegroup. É o arquivo que não pode faltar — sem o MDF o banco não existe. Organizado em páginas de 8KB agrupadas em extensões de 64KB.
Write-Ahead Log (WAL) que registra todas as modificações antes de aplicá-las às páginas de dados. Organizado em VLFs (Virtual Log Files). Quando o LDF está corrompido ou ausente, o SQL Server não consegue concluir o recovery automático (roll-forward e rollback de transações pendentes).
⚠️ Atenção: Nunca execute DBCC CHECKDB WITH REPAIR_ALLOW_DATA_LOSS sem backup do MDF e LDF — isso causa perda permanente de dados. Sempre nos contate antes.
Causa mais comum: interrupção de energia durante checkpoint. O SQL Server detecta que as transações pendentes no LDF não podem ser aplicadas ao MDF. Nossa abordagem: análise do LSN de consistência, reconstrução do LDF mínimo, attach do MDF em modo single user, extração e validação dos dados.
Quando o HD tem setores defeituosos coincidindo com páginas do MDF, o Error 823 aparece nos logs. Criamos imagem com ddrescue mapeando setores legíveis, identificamos as páginas afetadas, recuperamos os dados das páginas íntegras e reconstruímos as tabelas afetadas a partir de outras fontes quando disponíveis.
Reconstruímos um novo LDF com tamanho e configurações compatíveis, forçamos o attach do MDF sem recovery (WITH NORECOVERY), extraímos os dados e reimportamos em banco limpo. Este processo funciona quando o MDF está em estado pós-checkpoint — as transações pendentes são perdidas, mas os dados commitados são 100% recuperados.
Arquivos de backup SQL Server (.bak) são sequências de media headers, backup headers e data streams. Corrupção parcial não invalida o arquivo todo — extraímos os data streams íntegros, reconstruímos o schema a partir dos cabeçalhos e importamos os dados válidos. Recuperamos 60-90% dos dados dependendo da posição da corrupção no arquivo.
Diagnóstico gratuito. Resposta em até 2 horas. Cobrança somente com resultado confirmado. Não tome decisões sem antes falar com um especialista.