HD Doctor Logo

Proxmox Corrompido: Falhas, Vulnerabilidades e Recuperação

Por Equipe Técnica HD Doctor

Resposta direta

Proxmox corrompido tem três causas dominantes: falha de storage (ZFS ou LVM-thin), corrupção do cluster filesystem em /etc/pve e invasão por vulnerabilidade sem patch. As VMs quase sempre continuam no disco — o que quebrou foi a camada que aponta para elas. Diagnosticar antes de reparar é o que separa 2 horas de trabalho de uma perda definitiva.

O que exatamente corrompe em um Proxmox

Quatro camadas independentes podem falhar, e o sintoma na tela raramente diz qual delas foi. (1) O pmxcfs: /etc/pve não é um diretório normal, é um sistema de arquivos FUSE apoiado no SQLite em /var/lib/pve-cluster/config.db, replicado por Corosync. Perda de quórum ou corrupção desse banco deixa /etc/pve em modo somente leitura e some com as VMs da interface — mesmo com os discos intactos. (2) O storage: ZFS com pool FAULTED, erros de checksum ou falha ao importar; LVM-thin com metadados cheios ou corrompidos ('Check of pool failed'); Ceph com OSDs down e PGs incomplete. (3) O boot: falha ao importar rpool, systemd-boot ou GRUB apontando para dataset errado após atualização. (4) O vetor de segurança: em 1 de setembro de 2026 a Proxmox publicou o advisory PSA-2026-00043-1 (CVE-2023-54391), um bypass de autenticação no libpve-access-control em que o parâmetro tfa-challenge do endpoint /api2/json/access/ticket permite entrar como root@pam sem senha. Afeta as versões 7.0-7 até anteriores a 8.0.4 do pacote — ou seja, Proxmox VE 7.0 a 7.4 e as primeiras instalações 8.0 nunca atualizadas. Há exploração ativa, com ransomware e mineradores, e o pré-requisito é a porta 8006 exposta à internet.

Sintomas comuns e o que cada um significa

  1. 1.
    'cannot import rpool: I/O error' no boot. Pool ZFS não importa por disco com falha, cabo/backplane ruim ou corrupção de metadados. Nunca use -f como primeira tentativa: importe readonly=on e avalie. Com hardware suspeito, imagem antes de qualquer coisa.
  2. 2.
    /etc/pve somente leitura e VMs sumidas da interface. Perda de quórum do Corosync (cluster) ou corrupção do config.db. Os dados das VMs não foram afetados — é a camada de configuração. Recuperável via pmxcfs em modo local.
  3. 3.
    'Check of pool failed (status:1)' em LVM-thin. Metadados thin corrompidos ou cheios. É o cenário que mais se perde por reparo apressado: lvconvert --repair no original reescreve o mapeamento. Copie os metadados e trabalhe com thin_dump antes.
  4. 4.
    ZFS com checksum errors subindo em zpool status. Sinal de disco degradando, RAM sem ECC com defeito ou controladora com problema. Faça backup imediato antes do scrub — scrub em pool já degradado às vezes derruba o que ainda lia.
  5. 5.
    VM não inicia: 'qcow2: Image is corrupt'. Cabeçalho ou tabela L1/L2 danificados, normalmente por queda de energia durante escrita ou storage cheio. qemu-img check -r all pode resolver casos leves — sempre sobre cópia, nunca sobre o disco de produção.
  6. 6.
    Login estranho de root, logs vazios e CPU a 100%. Não é falha, é invasão. Combinação típica do PSA-2026-00043-1: minerador em CPU cheia, logs redirecionados para /dev/null e, em parte dos casos, ransomware em seguida. Isole a máquina da rede sem desligar.

Diagnóstico seguro de um Proxmox corrompido, em 7 passos

Ordem pensada para não destruir o que ainda é recuperável. Se em qualquer passo aparecer sinal de invasão, pare e trate como incidente de segurança, não como falha técnica.

  1. 1

    Pare de reiniciar

    Cada boot de um host com LVM-thin ou ZFS degradado dispara replay de journal e tentativas de reparo automático que consomem metadados antigos. Se o host já não sobe, mais um reboot não vai mudar isso — só reduz o que dá para recuperar.

  2. 2

    Suba em modo rescue e monte tudo read-only

    Boot por live USB (o próprio ISO do Proxmox em Debug Mode serve) e importe o storage sem escrever: zpool import -o readonly=on -N rpool, ou ativação de LVM sem montar. Ver o estado real do storage sem gravar nele é a única forma segura de decidir o que fazer.

  3. 3

    Classifique a falha antes de tocar em qualquer coisa

    Rode o diagnóstico de leitura: zpool import e zpool status -v para ZFS; pvs, vgs, lvs -a e thin_check sobre cópia dos metadados para LVM-thin; ceph -s e ceph osd tree para Ceph; smartctl -a em cada disco. Falha de disco físico, falha lógica e invasão exigem caminhos totalmente diferentes.

  4. 4

    Verifique se houve invasão

    Cheque a versão do pacote com dpkg -l libpve-access-control (abaixo de 8.0.4 = vulnerável ao PSA-2026-00043-1) e procure os indicadores publicados: arquivo /var/lib/systemd/PVE-1, serviço PVE-1.service, arquivos de log transformados em link para /dev/null e conexões de saída para pools de mineração. Revise também /root/.ssh/authorized_keys, crontab e usuários novos em /etc/pve/user.cfg.

  5. 5

    Recupere as configurações das VMs pelo config.db

    Se /etc/pve está vazio ou somente leitura, os arquivos .conf não se perderam: eles vivem dentro de /var/lib/pve-cluster/config.db. Com o serviço parado, pmxcfs -l monta o cluster filesystem em modo local e devolve as definições de cada VM e container, incluindo o mapeamento de discos — informação essencial para reanexar os volumes depois.

  6. 6

    Extraia as VMs antes de tentar consertar o host

    A prioridade é o dado, não o hypervisor. Com o storage montado read-only, copie os discos das VMs para um destino externo e valide cada um com qemu-img check. Só depois, com a cópia segura, vale tentar reparo do pool, dos metadados thin ou do boot — se o reparo falhar, você não perdeu nada.

  7. 7

    Reconstrua já corrigindo o vetor da falha

    Volte em versão suportada (8.x ou superior), tire a interface 8006 da internet, deixe acesso só por VPN ou lista de IPs, habilite TOTP para todas as contas, desabilite login root por SSH e configure backup no PBS com verificação e cópia imutável. Reconstruir sem fechar a porta de entrada é repetir o incidente em semanas.

Perguntas frequentes

Como sei se meu Proxmox está vulnerável ao PSA-2026-00043-1?

Rode dpkg -l libpve-access-control no host. Qualquer versão a partir de 7.0-7 e anterior a 8.0.4 está vulnerável — o que inclui Proxmox VE 7.0 a 7.4 e instalações 8.0 nunca atualizadas. A correção existe desde julho de 2023; o que mudou em setembro de 2026 foi a exploração em massa. Se o host está em versão fim de vida, atualize para uma release suportada e, imediatamente, tire a porta 8006 da internet.

Proxmox corrompido significa VMs perdidas?

Quase nunca. Na maioria dos casos que atendemos, os discos das VMs estavam íntegros e o que quebrou foi a camada de configuração (/etc/pve), os metadados do pool ou o boot. Por isso a ordem importa: extrair as VMs primeiro, reparar o host depois.

Posso rodar qemu-img check -r all para consertar a VM?

Pode, mas nunca no disco original. O -r all reescreve estruturas do QCOW2 e, em imagem com dano maior, consegue piorar o quadro. Faça cópia do arquivo (ou snapshot do dataset) e rode o reparo na cópia.

Perdi o quórum do cluster e /etc/pve ficou read-only. E agora?

Em cluster com nós fora do ar, o pvecm expected 1 devolve a escrita temporariamente no nó sobrevivente — solução de contingência, não de rotina. Se o problema é o config.db corrompido e não o quórum, o caminho é pmxcfs em modo local para extrair as configurações antes de qualquer reconstrução.

Vale reinstalar o Proxmox e importar o pool depois?

Só depois de ter as VMs copiadas para fora e com certeza de que o pool está saudável. Reinstalar com storage degradado é a forma mais comum de transformar falha lógica reparável em caso de laboratório: o instalador toca na tabela de partições e pode reinicializar o pool.

Falha física de disco em ZFS RAIDZ: dá para recuperar?

Sim, e é dos cenários com melhor prognóstico — RAIDZ tolera 1 disco (RAIDZ1) ou 2 (RAIDZ2). O risco está no resilver: com discos do mesmo lote envelhecendo juntos, é comum um segundo falhar durante a reconstrução. Se dois discos já saíram, pare o resilver e trate em laboratório com imagem de cada membro.

A HD Doctor atende Proxmox de qualquer versão e storage?

Sim: Proxmox VE 4.x a 9.x, com ZFS (mirror, RAIDZ, RAIDZ2), LVM-thin, Ceph RBD, NFS, CIFS e directory, além de containers LXC. Em 20+ anos foram 280+ ambientes Proxmox, com 91% de recuperação. Diagnóstico em 24h e NDA antes do envio.

Proxmox fora do ar ou com suspeita de invasão?

Diagnóstico em 24h. Não reinstale e não reinicie antes de falar com um engenheiro.

Próximas leituras