Recuperar Banco de Dados Corrompido ou Inacessível?

A virtualização transformou a infraestrutura de TI corporativa — e com ela, a complexidade dos cenários de recuperação de banco de dados. Em ambientes modernos, é raro encontrar um SQL Server, Oracle ou MySQL instalado diretamente em hardware físico. A grande maioria dos bancos de dados corporativos opera dentro de máquinas virtuais — Windows Server ou Linux rodando como guest em hosts VMware ESXi, Hyper-V ou Proxmox, com seus arquivos de dados armazenados em discos virtuais que por sua vez residem em volumes RAID físicos.

Quando o storage físico subjacente falha nesse cenário, a perda não é apenas de arquivos — são servidores inteiros que desaparecem. E a recuperação não é apenas de um banco de dados — é de toda a camada de infraestrutura que o sustentava.

Por que ambientes virtualizados são mais complexos de recuperar

Um banco de dados instalado diretamente em um servidor físico tem uma cadeia de dependência simples: disco físico → sistema de arquivos → arquivos do banco. Quando o disco falha, o problema está nessa única camada.

Um banco de dados em ambiente virtualizado tem uma cadeia significativamente mais longa: discos físicos do host → array RAID → sistema de arquivos do hipervisor (VMFS, NTFS ou EXT4) → arquivo de disco virtual (.VMDK, .VHDX ou .qcow2) → sistema de arquivos interno da VM (NTFS ou EXT4) → arquivos do banco de dados. Uma falha em qualquer camada dessa cadeia pode tornar o banco inacessível — e identificar em qual camada a corrupção ocorreu é o primeiro passo obrigatório antes de qualquer tentativa de recuperação.

VMware ESXi — VMFS e os Arquivos .VMDK

O VMware ESXi armazena as máquinas virtuais em datastores formatados com VMFS — Virtual Machine File System — um sistema de arquivos proprietário da VMware otimizado para acesso concorrente de múltiplos hosts. Dentro do datastore, cada VM é representada por um conjunto de arquivos, sendo o mais importante o arquivo .VMDK — o disco virtual que contém o sistema operacional e os dados da máquina.

Quando o storage físico do host ESXi falha, o VMFS pode ficar inconsistente — com a tabela de alocação de blocos corrompida ou com entradas de metadados inválidas. O resultado é um datastore que o ESXi não consegue montar, ou VMs que aparecem no inventário do vCenter mas não inicializam. Os arquivos .VMDK podem estar fisicamente intactos dentro do datastore — mas inacessíveis porque o VMFS não consegue localizá-los.

A recuperação envolve reconstruir o array RAID físico, reconstituir o VMFS a partir das estruturas remanescentes, localizar e extrair os arquivos .VMDK e montar o disco virtual em ambiente forense para acessar o sistema de arquivos interno da VM e os arquivos do banco de dados. Todo o processo é realizado sobre imagens clonadas em modo somente leitura — sem modificar o storage original em nenhum momento.

Hyper-V — VHDX e a Cadeia de Snapshots

O Hyper-V armazena as máquinas virtuais em arquivos .VHD ou .VHDX — discos virtuais de formato proprietário da Microsoft que podem ser montados diretamente no Windows para acesso ao conteúdo interno. Em ambientes com snapshots ativos, cada VM pode ter uma cadeia de arquivos de diferenciação — avhd ou .avhdx — que registram as alterações feitas após cada snapshot.

Quando o storage Hyper-V falha com snapshots não consolidados, a situação se torna particularmente complexa: para acessar o estado atual da VM, é necessário reconstituir toda a cadeia de snapshots na ordem correta — aplicando cada arquivo de diferenciação sobre o disco base em sequência. Uma cadeia de snapshots interrompida por corrupção de storage pode deixar a VM em estado inconsistente mesmo que os arquivos individuais estejam fisicamente presentes.

A recuperação de bancos de dados em Hyper-V começa pela extração do .VHDX principal e de todos os arquivos de diferenciação associados, seguida pela reconstituição da cadeia em ambiente forense e pela análise do sistema de arquivos interno para localizar e extrair os arquivos do banco de dados com integridade preservada.

Proxmox — qcow2, ZFS e LVM

O Proxmox VE é a plataforma de virtualização open source mais utilizada em empresas brasileiras de médio porte — especialmente em ambientes que migraram de VMware por questões de custo. Ele suporta múltiplos formatos de armazenamento: qcow2 para discos virtuais QEMU/KVM, ZFS para pools de armazenamento de alto desempenho, e LVM para volumes de bloco tradicionais.

O formato qcow2 tem uma característica que o torna particularmente vulnerável: ele armazena metadados internos de alocação no próprio arquivo, e uma corrupção nesses metadados pode tornar todo o disco virtual inacessível mesmo que a maior parte dos dados esteja fisicamente intacta. Em Proxmox com ZFS, a recuperação de pools FAULTED segue a mesma abordagem descrita na seção de storages NAS — análise dos uberblocks para identificar a versão mais recente íntegra do pool antes de tentar qualquer montagem.

A recuperação de bancos de dados em ambientes Proxmox começa pelo storage físico — seja ele ZFS, LVM ou um array RAID convencional — seguida pela extração do arquivo qcow2 e pela análise forense do sistema de arquivos interno para localizar os arquivos do banco de dados. Em todos os casos, o diagnóstico gratuito identifica em qual camada da cadeia a corrupção ocorreu e qual é o caminho mais seguro para a recuperação com o menor risco de perda adicional.

A regra universal para bancos de dados em ambientes virtualizados

Independentemente do hipervisor, do formato de disco virtual ou do sistema de banco de dados, existe uma regra que se aplica universalmente: nunca tente inicializar a VM após uma falha de storage sem antes clonar o storage físico em modo somente leitura. Cada tentativa de boot da VM força o hipervisor a realizar operações de escrita no storage — atualizando logs, gravando estados de memória e modificando metadados — que podem sobrescrever exatamente as estruturas necessárias para a recuperação do banco de dados. A velocidade correta em uma emergência de storage virtualizado não é a velocidade de agir — é a velocidade de parar e buscar avaliação especializada antes de qualquer intervenção.