A recuperação de banco de dados pode exigir duas competências ao mesmo tempo: reconstruir o storage que contém os arquivos e validar a consistência no SGBD. A SECURITY trabalha com SQL Server, Oracle, MySQL/MariaDB, PostgreSQL, Firebird, VMs, RAID, NAS e storage corporativo, com atendimento remoto para todo o Brasil em casos lógicos compatíveis.
O que é um banco de dados?
A intenção principal desta página é recuperação de dados de banco de dados. RAID e storage aparecem como camadas inferiores quando são a causa ou parte do problema.
Guia completo de recuperação de dados de banco de dados
Um banco corporativo depende de até seis camadas antes de chegar aos registros
O erro que aparece no SQL Server Management Studio, alert.log do Oracle ou MySQL error log pode ser efeito de uma falha de VM, filesystem, storage ou mídia física.
A recuperação deve identificar a camada mais baixa que ainda entrega dados coerentes antes de reparar o SGBD.
O benchmark acerta ao enfatizar o storage, mas exagera ao afirmar que ele é a causa da esmagadora maioria sem apresentar dados. A SECURITY evita esse percentual implícito: primeiro identificamos a camada da falha. Corrupção estritamente lógica também existe e possui ferramentas nativas importantes.
Suspect, Recovery Pending, ORA-01578, InnoDB crash e PostgreSQL sem iniciar
SUSPECT / RECOVERY_PENDING
Estados SQL Server com causas diferentes. Recovery Pending pode ser erro de recurso e não prova corrupção.
ORA-01578
Oracle detectou block corruption em datafile/block específico.
InnoDB crash loop
Corrupt page, redo/undo, dictionary ou I/O podem impedir startup.
WAL / pg_control
PostgreSQL pode falhar em startup por corrupção de WAL/control files ou data pages.
Firebird validation errors
gfix pode reportar data, index, transaction, BLOB ou database page errors.
Erros intermitentes
Disk cache, driver, controller ou I/O path podem fazer erros aparecerem e desaparecerem.
MDF, NDF, LDF, SUSPECT, RECOVERY_PENDING e DBCC CHECKDB
| Estado / ação | Significado técnico | Prioridade |
|---|---|---|
| RECOVERY_PENDING | erro de recurso durante recovery; banco não necessariamente danificado | checar arquivos, espaço, I/O e logs |
| SUSPECT | startup recovery falhou; primary filegroup pode estar danificado | backup/restore + CHECKDB em cópia |
| EMERGENCY | modo manual read-only de troubleshooting | extração/diagnóstico controlado |
| REPAIR_REBUILD | repairs sem possibilidade de perda segundo Microsoft | usar quando indicado pelo CHECKDB |
| REPAIR_ALLOW_DATA_LOSS | repair que pode remover páginas ou reconstruir log | último recurso quando restore não é possível |
A Microsoft orienta criar cópias físicas dos arquivos antes de repair e sempre tratar a causa do I/O path se os erros forem provocados por hardware, driver, cache ou filesystem. Depois de REPAIR_ALLOW_DATA_LOSS, a base pode ficar fisicamente consistente e ainda logicamente incorreta.
RMAN, datafiles, tablespaces, redo e block media recovery
Oracle diferencia physical block corruption de logical block corruption. RMAN VALIDATE e V$DATABASE_BLOCK_CORRUPTION ajudam a localizar o dano; block media recovery pode reparar blocos específicos quando existem fontes válidas de backup/redo/standby.
Datafiles / DBF
Contêm blocks de tablespaces. Corrupção pode ser localizada ou ampla.
Redo / archived logs
Participam da recuperação das mudanças após o backup.
RMAN VALIDATE
Detecta physical corruption e, com CHECK LOGICAL, também logical corruption detectável.
RECOVER ... BLOCK
Útil quando um conjunto pequeno e conhecido de blocks está corrompido.
Block media recovery não substitui restore de datafile quando o dano é amplo. Também pode falhar se os redo necessários estão ausentes ou corrompidos.
InnoDB corrompido: innodb_force_recovery serve para extrair, não para “consertar tudo”
MySQL 8.4 documenta níveis de innodb_force_recovery de 1 a 6 para situações emergenciais. A orientação é começar em 1 e aumentar somente quando necessário. Valores 4 ou superiores podem corromper permanentemente os data files e devem ser testados em uma cópia física separada.
ibdata / system tablespace
Pode conter estruturas e dados dependendo da configuração.
.ibd
File-per-table tablespaces usados em muitos ambientes InnoDB.
Redo / undo
Crash recovery depende dessas estruturas para consistência transacional.
force recovery
Objetivo é permitir leitura/dump quando o startup normal falha.
PGDATA, WAL, PITR e pg_resetwal: preserve o cluster antes do último recurso
PostgreSQL mantém WAL para crash safety e permite Point-in-Time Recovery quando existe base backup e sequência contínua de WAL arquivado. Isso é diferente de um simple pg_dump, que é backup lógico.
PGDATA
Data directory contém relations, configs e control information.
pg_wal
WAL registra mudanças e pode ser usado para replay/PITR.
PITR
Base backup + WAL pode voltar a um ponto anterior a DROP/DELETE.
pg_resetwal
Último recurso quando WAL/control information impede startup.
A documentação PostgreSQL recomenda, após pg_resetwal em cluster corrompido, iniciar apenas para dump imediato, executar novo initdb e restaurar. A opção --dry-run permite revisar valores antes de alterar.
gfix e gbak: ferramentas oficiais com risco real de perda em mend
A documentação Firebird orienta criar uma cópia do database file antes de recovery. gfix validation identifica problemas; gfix -mend pode ignorar registros corrompidos e levar à perda de dados. Depois, gbak backup/restore pode reconstruir uma base nova a partir do que permanece legível.
FDB
Database file que deve ser preservado antes de qualquer mend.
gfix validate
Detecta e reporta problemas estruturais.
gfix -mend
Pode marcar/ignorar registros corrompidos e perder dados.
gbak
Backup/restore é etapa importante para reconstruir base consistente após recovery.
O banco pode estar saudável internamente e ter perdido apenas a camada de storage
RAID 1 / 10
Mirror
RAID 5
Paridade P
RAID 6
Paridade P + Q
Storage / SAN
Pool/LUN antes do banco
VMware
MDF/DBF/PGDATA podem estar dentro de VMDK sobre VMFS/SAN/RAID.
Hyper-V
VHDX/AVHDX e CSV/ReFS podem ser camadas intermediárias.
NAS / SAN
LUN, pool e filesystem podem falhar sem corrupção original do database file.
RAID Low Level
Ordem, stripe, parity, offsets e metadata importam em arrays complexos.
Quando as mídias estão fisicamente instáveis, a etapa correta pode envolver PC-3000, Data Extractor, DeepSpar e, quando HDD exige procedimento mecânico, sala limpa ISO-5. Depois vem a validação no engine de banco.
Recuperar uma tabela apagada começa pelo backup/log, não por “carving mágico”
O benchmark simplifica DROP TABLE como se a recuperação fosse normalmente uma leitura direta do LDF. O caminho suportado e mais previsível depende do engine e da cadeia de backups/logs.
| Engine | Fonte preferencial | Point-in-time | Observação |
|---|---|---|---|
| SQL Server | full/diff/log backups | Full recovery model com log chain | restore em base alternativa antes do DROP |
| Oracle | RMAN + archived redo | DB/tablespace recovery conforme estratégia | depende de backups e redo |
| MySQL | backup + binary logs | possível com log chain adequada | engine/configuração importam |
| PostgreSQL | base backup + WAL | PITR nativo | cluster-level recovery |
Banco criptografado precisa de recuperação estrutural e validação transacional
Ransomware pode atingir datafiles, logs, backups e VMs. Em arquivos grandes, algumas famílias usam criptografia parcial. Isso pode deixar páginas intactas, mas não garante consistência do database.
SQL Server
MDF/NDF/LDF podem ter regiões intactas e regiões cifradas.
Oracle
DBF/control/redo e backups precisam ser analisados em conjunto.
MySQL/PostgreSQL
Tablespaces, WAL/redo/undo e backups podem oferecer caminhos diferentes.
VMs
VMDK/VHDX pode adicionar uma camada extra antes do database file.
Como funciona a recuperação remota de banco de dados
12 passos quando um banco de dados crítico para de abrir
O que pode agravar uma recuperação de banco de dados
REPAIR_ALLOW_DATA_LOSS no único original
Pode remover páginas e deixar inconsistências lógicas.
innodb_force_recovery 4-6 em produção
MySQL alerta para possível corrupção permanente de data files.
pg_resetwal por tentativa
PostgreSQL classifica como último recurso e recomenda dump imediato depois.
gfix -mend sem cópia
Pode ignorar registros corrompidos e perder dados.
Rebuild RAID cego
Pode piorar o storage que contém todos os database files.
Restore sobre a produção
Pode sobrescrever um estado que ainda tinha dados recuperáveis.
Como a SECURITY conduz a recuperação de dados de banco de dados
Se existe falha física, entram PC-3000, Data Extractor, DeepSpar e, quando necessário, procedimentos em sala limpa ISO-5.
Caio Bruno F. Garcia, WinHex e RAID Low Level em bancos de extrema complexidade
WinHex pode auxiliar inspeção hexadecimal de MDF/NDF/LDF, datafiles Oracle, InnoDB files, PGDATA relations, FDB, LUNs e RAID quando o caso exige análise abaixo das ferramentas do engine.
SQL Server
Localizar pages, headers, allocation patterns e regiões legíveis em cópias.
Oracle / MySQL / PostgreSQL
Correlacionar datafiles/tablespaces e signatures com o storage recuperado.
VM / filesystem
Localizar database files dentro de VMDK/VHDX e volumes danificados.
RAID físico
Validar ordem, stripe, paridade e offsets antes da camada database.
Principais engines e infraestruturas encontradas em projetos de banco de dados
Vídeos da SECURITY sobre RAID, VMs e banco de dados
O vídeo complementa este artigo porque mostra como RAID, VMs e banco de dados podem fazer parte da mesma cadeia de falha.
Cenários técnicos de recuperação de banco de dados
SQL Server SUSPECT sobre RAID 5 degradado
Clonar membros instáveis, reconstruir array em modo controlado, extrair MDF/NDF/LDF e executar CHECKDB/validação em cópia.
Oracle ORA-01578 com corrupção localizada
Identificar blocks/datafiles com RMAN VALIDATE, preservar storage e avaliar block media recovery a partir de backup/redo válido.
MySQL InnoDB crash loop após queda
Preservar datadir, trabalhar em cópia, iniciar force recovery no menor nível possível e exportar tabelas legíveis para nova instância.
PostgreSQL não inicia por WAL/control corruption
Preservar PGDATA/WAL, procurar base backup/PITR e tratar pg_resetwal somente como último recurso sobre cópia, seguido de dump/rebuild.
Firebird FDB corrompido após falha elétrica
Copiar FDB, validar com gfix, documentar erros e usar mend/gbak somente em cópia para reconstruir uma base nova com o máximo de registros legíveis.
FAQ sobre recuperação de dados de banco de dados
O que é um banco de dados?
Banco de dados é uma estrutura organizada para armazenar e consultar informações por meio de um sistema gerenciador, como SQL Server, Oracle, MySQL, MariaDB, PostgreSQL ou Firebird. Os dados dependem de arquivos, logs, memória, filesystem e storage físico; por isso, uma falha pode ocorrer em qualquer camada.
O que é recuperação de dados de banco de dados?
É o processo de preservar e reconstruir as camadas necessárias para voltar a acessar tabelas, registros, arquivos e transações quando o banco fica corrompido, Suspect, Recovery Pending, não inicia, perde datafiles, sofre falha de storage ou precisa ser extraído de uma mídia danificada.
Todo banco de dados inacessível está corrompido?
Não. O problema pode estar no storage, RAID, filesystem, VM, permissões, arquivos ausentes, log, configuração ou recursos do sistema. SQL Server, por exemplo, define Recovery Pending como um erro de recurso durante recovery e informa que o banco não está necessariamente danificado.
Banco SQL Server em SUSPECT significa perda total?
Não. SUSPECT significa que o SQL Server não conseguiu recuperar o banco na inicialização e que pelo menos o primary filegroup pode estar danificado. A causa precisa ser investigada antes de escolher restore, repair ou recuperação especializada.
Qual a diferença entre SUSPECT e RECOVERY PENDING no SQL Server?
Segundo a Microsoft, SUSPECT ocorre quando o banco não consegue ser recuperado durante startup e o primary filegroup pode estar danificado. Recovery Pending indica um erro relacionado a recursos durante recovery; o banco pode não estar danificado, mas arquivos ausentes ou limitações de sistema podem impedir a inicialização.
DBCC CHECKDB recupera banco corrompido?
DBCC CHECKDB verifica a integridade lógica e física e possui opções de repair. A Microsoft recomenda restore de um backup bom como método principal. REPAIR_ALLOW_DATA_LOSS é último recurso e pode remover páginas ou deixar inconsistências lógicas.
REPAIR_ALLOW_DATA_LOSS é seguro?
É uma opção suportada do SQL Server, mas o próprio nome é literal: pode haver perda de dados. A Microsoft recomenda copiar fisicamente MDF, NDF e LDF antes do repair e tratar essa opção como último recurso quando restore não é possível.
Posso apagar o LDF e anexar apenas o MDF?
Não use isso como atalho automático. O transaction log participa da consistência e do recovery. Em situações extremas o SQL Server possui emergency repair que pode reconstruir log, mas a Microsoft alerta que isso pode perder consistência transacional. Preserve MDF/NDF/LDF antes de qualquer tentativa.
MDF e LDF são a mesma coisa?
Não. MDF/NDF são data files do SQL Server; LDF é transaction log. A recuperação pode depender da combinação entre data pages, allocation structures, log chain, backups e recovery model.
É possível recuperar uma tabela apagada com DROP TABLE?
O caminho preferencial é restore para um ponto anterior ao DROP, em uma base alternativa, quando existem backups e transaction log suficientes. No recovery model Full, o SQL Server suporta point-in-time restore com uma cadeia válida de backups de log. Recuperação direta sem backup depende do estado real dos arquivos e não é garantida.
O que é point-in-time recovery no SQL Server?
É restaurar um banco até um horário ou marca anterior ao incidente usando backups compatíveis. No Full recovery model, isso é possível quando a cadeia de backups de log está completa; no Simple, a recuperação normalmente vai até o final de um backup.
Oracle com ORA-01578 pode ser recuperado?
ORA-01578 indica block corruption. Oracle RMAN pode identificar blocos corrompidos e, em cenários compatíveis, executar block media recovery usando backups, redo, flashback logs ou standby. Nem toda corrupção lógica pode ser corrigida por block recovery.
O que é V$DATABASE_BLOCK_CORRUPTION?
É a view Oracle que registra blocos marcados como corrompidos por componentes como RMAN, ANALYZE e queries. Ela ajuda a identificar datafile e block numbers envolvidos em physical ou logical corruption.
RMAN RECOVER BLOCK é indicado para qualquer banco Oracle corrompido?
Não. Block media recovery é mais adequado quando existe um conjunto pequeno e conhecido de blocos corrompidos. Se o dano é amplo ou o datafile inteiro está comprometido, restore/recovery em nível de datafile ou tablespace pode ser mais adequado.
MySQL InnoDB corrompido pode ser recuperado?
Pode existir viabilidade. MySQL oferece innodb_force_recovery para situações emergenciais em que o objetivo é iniciar o InnoDB e extrair tabelas. A documentação recomenda começar no nível 1 e aumentar gradualmente somente quando necessário.
innodb_force_recovery é um repair?
Não exatamente. No MySQL ele permite iniciar InnoDB com operações reduzidas para tentar extrair dados. Valores 4 ou maiores podem corromper permanentemente data files e devem ser testados somente em uma cópia física separada.
O que significa innodb_force_recovery de 1 a 6?
Os níveis progressivamente desabilitam partes do crash recovery e operações internas. Quanto maior o valor, maior o risco e menor a consistência esperada. No MySQL 8.4, valores 4 ou superiores colocam InnoDB read-only e podem causar corrupção permanente.
MariaDB usa o mesmo innodb_force_recovery do MySQL?
MariaDB também oferece recovery modes 1 a 6, mas comportamento e permissões variam conforme versão. A documentação MariaDB enfatiza que recovery mode não repara a corrupção; serve para tentar permitir leitura e dump dos dados.
PostgreSQL com WAL corrompido pode ser recuperado?
Pode existir viabilidade dependendo do PGDATA, pg_control, WAL, base backup e archives. PostgreSQL suporta PITR com base backup + WAL. pg_resetwal existe para casos de WAL/control corruption, mas a documentação o classifica como último recurso.
pg_resetwal é seguro?
Não deve ser usado como primeira tentativa. PostgreSQL alerta que qualquer uso fora de um cluster limpo pode ser perigoso. A opção --dry-run ajuda a inspecionar valores; após um reset em ambiente corrompido, a recomendação é dump imediato, initdb e restore.
PostgreSQL pode voltar a um ponto no tempo?
Sim. Com base backup e sequência contínua de WAL arquivado, PostgreSQL suporta Point-in-Time Recovery e pode parar o replay antes de um erro lógico como DROP, DELETE ou corrupção introduzida em determinado momento.
Firebird corrompido pode ser recuperado?
Pode existir viabilidade. Firebird oferece gfix para validation e mend e gbak para backup/restore. A documentação alerta que gfix -mend pode resultar em perda de dados e recomenda trabalhar primeiro com uma cópia do database file.
gfix -mend é seguro?
É uma ferramenta oficial, mas pode ignorar registros corrompidos e levar à perda silenciosa desses registros em backups posteriores. Por isso, deve ser usado sobre cópia e com validação do resultado.
Falha de storage pode corromper banco de dados?
Sim. Erros de I/O, cache, filesystem, RAID, mídia ou controladora podem impedir leitura e escrita corretas. A Microsoft orienta tratar problemas do I/O path antes de repetir repair/restore quando eles estão causando consistência intermitente.
DBCC CHECKDB em disco fisicamente instável é recomendado?
O primeiro passo deve ser estabilizar o storage quando existem erros físicos ou de I/O. Microsoft orienta resolver problemas de hardware, driver, firmware e I/O path antes de repair/restore. Em mídia instável, preservar/clonar antes de leituras intensivas reduz risco operacional.
Banco dentro de VM pode ser recuperado?
Pode. A recuperação pode exigir RAID ou storage, depois VMFS/VMDK ou VHDX/QCOW2, depois filesystem do guest e finalmente os arquivos do banco. O processo precisa respeitar a ordem das camadas.
SQL Server dentro de VMware ou Hyper-V muda a recuperação?
Sim. MDF/LDF podem estar dentro de VMDK/VHDX que dependem de datastore, SAN ou RAID. Recuperar apenas o database file não resolve se a camada virtual ou física continua inconsistente.
Ransomware em banco de dados pode ser recuperado?
Depende da cobertura da criptografia, backups, logs, snapshots e regiões intactas. Bancos grandes podem ter partial encryption, mas recuperar bytes não garante consistência transacional; a validação precisa ocorrer no próprio engine.
RAID e recuperação de banco de dados são a mesma coisa?
Não. RAID é uma camada de storage. Esta página tem intenção principal em recuperação de dados de banco de dados. RAID Low Level entra quando MDF, DBF, IBD, PGDATA ou outros arquivos estão sobre um array com falha.
Preciso levar o servidor inteiro?
Na maioria dos casos lógicos, não. Logs, cópias dos arquivos de banco, VMs, images de volume ou LUN e backups podem ser suficientes. Se há falha física em HDD/SSD/RAID, normalmente enviam-se apenas as mídias necessárias e informações de ordem/serial.
É possível recuperar banco de dados remotamente?
Sim, em muitos casos lógicos. Se o storage está estável, a análise pode começar remotamente com cópias de MDF/LDF, datafiles Oracle, MySQL data directory, PGDATA, FDB e logs.
Quanto custa recuperar banco de dados?
O custo depende do engine, volume, quantidade de files, corrupção, backups, RAID/storage, VMs, falhas físicas e tentativas anteriores. Não existe preço único sem diagnóstico.
Quanto tempo leva?
Depende da camada da falha. Recriar uma configuração com arquivos íntegros é diferente de reconstruir RAID, recuperar VM, extrair páginas válidas e validar milhões de registros.
A SECURITY atende recuperação de banco de dados em todo o Brasil?
Sim. Casos lógicos compatíveis podem começar por recuperação remota para todo o Brasil. Quando há falha física, a SECURITY orienta o envio das mídias necessárias.
Sem necessidade de levar o equipamento em muitos casos
Remoto
Database files, logs, VMs e backups podem ser analisados por sessão segura.
Mídias físicas
Se HDD/SSD/RAID falha, enviam-se as mídias afetadas.
Servidor completo
Normalmente não é necessário em falha lógica.
Todo o Brasil
Triagem lógica pode começar independentemente da localização.
Alphaville, São Paulo e Campinas quando o caso exige laboratório
Alameda Rio Negro, 1030, Conj. 206
Barueri, SP, CEP 06454-000
(11) 98570-8000
Rua Frei Caneca, 1380, Conj. 11
São Paulo, SP, CEP 01307-002
(11) 98570-8000
Rua José Paulino, 1399, Andar 10
Campinas, SP, CEP 13013-001
(19) 99971-7987
Caio Bruno F. Garcia
Especialista em Recuperação de Dados e liderança técnica e estratégica da SECURITY. Atua desde 2005 e, em projetos de banco de dados de alta complexidade, relaciona database files, VMs e storage às camadas de RAID Low Level e análise hexadecimal com WinHex, além de PC-3000 e Data Extractor quando existe falha física.
Banco de dados por dentro: datafiles, logs, storage e recuperação
1. SGBD
Sistema gerenciador coordena datafiles, logs, cache, recovery e transações.
2. Storage x database
Erro no SGBD pode ser efeito de falha no I/O path.
3. SQL Server MDF
Primary data file.
4. SQL Server NDF
Secondary data files.
5. SQL Server LDF
Transaction log.
6. SQL Server data pages
Páginas são a unidade básica de storage do engine.
7. RECOVERY_PENDING
Erro de recurso durante recovery; banco não necessariamente danificado.
8. SUSPECT
Startup recovery falhou e primary filegroup pode estar danificado.
9. EMERGENCY
Modo manual read-only de troubleshooting.
10. DBCC CHECKDB
Verifica integridade lógica/física e recomenda repair level.
11. REPAIR_REBUILD
Repairs sem possibilidade de perda segundo Microsoft.
12. REPAIR_ALLOW_DATA_LOSS
Último recurso; pode remover páginas e inconsistências permanecem possíveis.
13. SQL point-in-time
Full recovery model + log chain podem voltar a um momento específico.
14. Tail-log backup
Quando possível, ajuda a reduzir perda antes de restore.
15. Oracle datafile
Contém database blocks e tablespaces.
16. Oracle redo
Registra mudanças necessárias para recovery.
17. RMAN VALIDATE
Identifica physical e logical corruption detectável.
18. V$DATABASE_BLOCK_CORRUPTION
Lista blocks marcados como corruptos.
19. RMAN block recovery
Recupera blocks específicos com backup/redo/standby em cenários compatíveis.
20. MySQL InnoDB
Transactional engine com data files, redo e undo.
21. ibdata
System tablespace em configurações InnoDB.
22. .ibd
File-per-table tablespace comum.
23. innodb_force_recovery 1-3
Modos emergenciais progressivos para tentar extrair dados.
24. innodb_force_recovery 4-6
Níveis perigosos que podem corromper data files.
25. MariaDB recovery mode
Serve para permitir leitura; não repara a corrupção.
26. PostgreSQL PGDATA
Data directory do cluster.
27. PostgreSQL WAL
Write-ahead log usado em crash recovery e PITR.
28. PostgreSQL PITR
Base backup + WAL contínuo permitem voltar a um ponto no tempo.
29. pg_resetwal
Último recurso; dry-run disponível; depois dump/rebuild.
30. PostgreSQL timelines
Permitem múltiplos ramos de recuperação PITR.
31. Firebird FDB
Database file que deve ser copiado antes de mend.
32. gfix validate
Verifica corruption e pode alterar housekeeping por padrão.
33. gfix -mend
Pode ignorar registros danificados e provocar perda.
34. gbak
Backup/restore usado para reconstruir uma nova base Firebird.
35. VMware
Database files podem estar em VMDK/VMFS.
36. Hyper-V
Database files podem estar em VHDX/CSV.
37. Proxmox
Database pode depender de ZFS/LVM-thin/Ceph/QCOW2.
38. NAS / SAN
Pool, LUN, filesystem e RAID podem ser a causa inferior.
39. RAID 1/10
Mirror.
40. RAID 5
Paridade P.
41. RAID 6
Dupla paridade P+Q.
42. RAID Low Level
Ordem, stripe, parity, offsets e metadata.
43. PC-3000
Usado quando mídia suportada tem falha física/firmware.
44. Sala limpa ISO-5
Usada em HDD mecânico quando intervenção física é necessária.
45. WinHex
Auxilia análise hexadecimal em cópias, não substitui SGBD.
46. Ransomware
Partial encryption pode deixar regiões intactas, sem garantir consistência.
47. Backup
Restore testado é preferível a repair destrutivo.
48. Remote recovery
Casos lógicos estáveis podem começar remotamente.
49. Second opinion
Documentar tentativas anteriores é essencial.
51. Matriz técnica de decisão
| Sintoma | Camada | Prioridade | Evitar |
|---|---|---|---|
| SQL SUSPECT | database/storage | backup + CHECKDB + I/O health | repair destrutivo no único original |
| ORA-01578 | Oracle block | VALIDATE + backup/redo | ignorar storage instável |
| InnoDB crash | data/redo/undo | copy + recovery mode mínimo | subir direto para 6 |
| PostgreSQL WAL failure | WAL/control | backup/PITR/copy | pg_resetwal por tentativa |
| Firebird corruption | FDB pages | copy + validate | mend no único original |
| RAID/storage degraded | camada física | diagnosticar/clonar | rebuild repetido |
52. Conclusão técnica
Recuperação de banco de dados exige separar corrupção lógica de falha de storage e escolher a ferramenta correta para cada engine. Restore a partir de backup bom é preferível quando existe. Quando não existe, a preservação do original e a reconstrução por camadas aumentam as opções técnicas. Muitos casos lógicos podem começar remotamente em qualquer região do Brasil.
Referências utilizadas para validar este guia
- Microsoft: SQL Server Database States
- Microsoft: DBCC CHECKDB e REPAIR_ALLOW_DATA_LOSS
- Microsoft: troubleshoot consistency errors e I/O path
- Microsoft: Point-in-Time Restore
- Oracle Database 23: Backup and Recovery User's Guide
- Oracle: Block Media Recovery
- MySQL 8.4: Forcing InnoDB Recovery
- MariaDB: InnoDB Recovery Modes
- PostgreSQL 18: pg_resetwal
- PostgreSQL 18: Continuous Archiving and PITR
- Firebird: gfix Database Validation and Recovery
- X-Ways: WinHex
