Proxmox VE pode armazenar VMs e containers em ZFS, LVM-thin, Ceph RBD, NFS, iSCSI, directory storage e outros backends. A SECURITY trabalha por camadas para recuperar dados sem reduzir todo caso a um simples QCOW2, com recuperação remota para todo o Brasil em cenários lógicos compatíveis.
O que é Proxmox VE?
Essa definição evita um erro comum: nem todo disco Proxmox é QCOW2. ZFS normalmente usa zvol/raw, LVM-thin usa thin LV raw e Ceph usa RBD.
Guia completo de recuperação de dados em Proxmox VE
A recuperação Proxmox depende do backend de storage
O Proxmox Storage Manager integra storages de arquivo e bloco. Essa flexibilidade exige precisão em recovery: QCOW2, zvol, thin LV e RBD não são estruturas equivalentes.
Proxmox não possui um único formato de disco. O backend define a forma correta de recuperação.
A melhor abordagem é identificar a camada mais baixa ainda coerente e subir a pilha sem escrever na origem.
ZFS faulted, thin pool inactive, Ceph degraded e QCOW2 inválido
Pool não importa
Vdev ausente, log device ou transaction groups podem estar envolvidos.
Thin pool inactive
Metadata danificada ou pool cheio pode retirar várias VMs.
QCOW2 corrupt
Backing chain, refcounts ou clusters podem estar inconsistentes.
PGs inactive
MONs, OSDs, PGs e RBD precisam ser analisados.
Sem quorum
pmxcfs pode ficar read-only sem perda dos VM disks.
Storage cheio
Guests recebem I/O errors e podem corromper filesystem.
ZFS em Proxmox: zvols, vdevs, uberblocks e import read-only
O backend ZFS do Proxmox usa zvol/raw para VMs e subvol datasets para containers. Snapshots e clones são nativos do backend.
| Ação | Efeito | Recovery |
|---|---|---|
| zpool import | lista pools | inspeção |
| readonly=on -N | importa sem montar/escrever | ótimo primeiro passo |
| -f | força import de pool potencialmente ativo | não descarta por si só |
| -F -n | dry-run rewind | testa sem executar |
| -F | descarta TXGs recentes | pode perder transações |
| -X | extended rewind | medida extrema |
LVM-thin: data LV, metadata LV e várias VMs dependentes do mesmo mapa
O thin pool possui _tdata e _tmeta. A metadata rastreia quais blocos pertencem a cada thin LV.
_tdata
Blocos físicos das VMs.
_tmeta
Mapa de alocação dos thin volumes.
Data% / Meta%
Exhaustion pode gerar I/O errors e inconsistência.
Snapshots
Compartilham blocos e divergem conforme escrita.
lvconvert --repair é um mecanismo oficial que cria metadata reparada e preserva a anterior como ThinPool_metaN quando funciona.
QCOW2: backing files, qemu-img info e repair
QCOW2 é comum em file storage e pode usar backing files. qemu-img info --backing-chain enumera base e children.
Backing chain
base.qcow2 <- snap1.qcow2 <- snap2.qcow2.
qemu-img check
Verifica consistência.
-r leaks
Repara leaks.
-r all
Maior risco de fix incorreto ou corrupção escondida.
Ceph no Proxmox: OSDs, pools, PGs e imagens RBD
RBD é block storage distribuído. As imagens vivem como objetos no RADOS e podem ter snapshots, clones e trash.
MON quorum
Mantém cluster maps e estado.
OSDs
Armazenam objetos e participam de PGs.
RBD snapshots
Point-in-time e crash-consistent sem coordenação guest.
RBD trash
Imagem pode ser restaurada antes de remoção definitiva.
Perda de quorum pode derrubar operações sem apagar os discos das VMs
Proxmox usa quorum para manter estado consistente. Sem quorum, o cluster pode entrar em modo read-only.
pmxcfs
Expõe /etc/pve e distribui configuração.
config.db
Pode ser recuperada em host novo conforme documentação.
Guest configs
VMs em qemu-server e containers em lxc.
Shared storage
Guest config pode ser movida em cenários suportados.
NFS, CIFS, iSCSI, Fibre Channel e directory storage
NFS / CIFS
File storage compartilhado.
iSCSI
Block storage compartilhado.
Fibre Channel
LUN SAN pode ser integrada com LVM.
Directory
Pode conter qcow2/raw, ISOs e backups.
RAID pode estar abaixo do Proxmox, mas RAIDZ e Ceph exigem leitura própria
RAID 1 / 10
Mirror
RAID 5
Paridade P
RAID 6
P + Q
RAIDZ / Ceph
Proteção específica
RAID hardware, RAIDZ e Ceph não devem ser tratados como a mesma geometria. Se há falha física, a camada de mídia vem antes do backend.
Backup validado continua sendo a rota preferencial
Se houver backup íntegro no ponto certo, restore é preferível à recuperação de emergência. Recovery entra quando o backup não existe, está corrompido ou não contém o estado desejado.
Backup independente
Fora do mesmo pool/cluster.
Restore test
Backup precisa ser restaurável.
Snapshots
Não substituem backup externo.
Aplicações
Depois do restore, valide bancos e serviços.
Proxmox, QCOW2, RBD e backups também podem ser alvo
O ataque pode atingir hosts, storages montados, images virtuais e repositórios.
Como funciona a recuperação remota de Proxmox
12 passos quando Proxmox perde VMs, containers ou storage
O que pode agravar uma recuperação Proxmox
zpool -F/-X
Pode descartar transações.
Recriar thin pool
Pode substituir metadata de alocação.
qemu-img -r all no original
Pode escolher fix inadequado.
Remover OSDs por tentativa
Pode reduzir fontes do Ceph.
Reinstalar no mesmo storage
Pode sobrescrever dados úteis.
Assumir quorum = data loss
Cluster read-only pode coexistir com storage íntegro.
Como a SECURITY conduz a recuperação de Proxmox
Caio Bruno F. Garcia, WinHex e RAID Low Level em Proxmox de extrema complexidade
WinHex pode auxiliar inspeção de partition tables, ZFS labels, LVM metadata, QCOW2 headers e RAID físico quando o caso exige análise abaixo das ferramentas Proxmox.
ZFS
Comparar labels e offsets.
LVM
Validar PV/VG/LV e thin pool.
QCOW2/raw
Inspecionar headers e signatures.
RAID físico
Validar disk order, stripe e paridade.
Principais tecnologias encontradas em projetos Proxmox
Vídeos da SECURITY sobre RAID, VMs e banco de dados
O vídeo mostra como storage físico, RAID, VM e aplicação se conectam.
Cenários técnicos de recuperação de Proxmox
ZFS RAIDZ2 não importa
Preservar devices, testar import read-only, clonar membros instáveis e evitar rewind sem dry-run.
LVM-thin metadata corrupt
Preservar _tmeta/_tdata e VG metadata antes de repair.
QCOW2 backing chain quebrada
Mapear backing chain e evitar -r all no único original.
Ceph pool degraded
Preservar cluster maps, OSD/PG state e imagem RBD.
Cluster sem quorum
Recuperar pmxcfs/config e separar falha de cluster de perda dos VM disks.
FAQ sobre recuperação de dados em Proxmox VE
O que é Proxmox VE?
Proxmox VE é uma plataforma de virtualização baseada em Linux que integra KVM para máquinas virtuais e LXC para containers. Seu modelo de storage suporta ZFS, LVM, LVM-thin, Ceph RBD, NFS, CIFS, iSCSI, Fibre Channel via LVM, diretórios locais e outros backends.
O que é recuperação de dados em Proxmox?
É o processo de reconstruir as camadas necessárias para acessar VMs, containers e arquivos quando ZFS, LVM-thin, Ceph, QCOW2, storage compartilhado, cluster ou RAID físico deixam de apresentar os dados corretamente.
Proxmox usa sempre QCOW2?
Não. Em ZFS as VMs normalmente usam zvols raw; em LVM-thin usam thin LVs raw; em Ceph usam RBD; QCOW2 aparece principalmente em storages de arquivo como directory, NFS ou CIFS.
ZFS em Proxmox pode ser recuperado?
Pode existir viabilidade conforme o estado dos vdevs, labels, uberblocks, transaction groups, datasets e zvols. OpenZFS recomenda começar pelas opções menos destrutivas e oferece import read-only para inspeção.
zpool import -F é seguro?
OpenZFS documenta -F como recovery mode que pode descartar transaction groups recentes para retornar a um estado importável. Use -F -n para dry-run antes de qualquer rewind.
zpool import -X é seguro?
Não deve ser primeira tentativa. OpenZFS classifica -X como medida extrema e potencialmente perigosa, pois procura transaction groups mais antigos e pode aceitar estados sem a garantia normal de consistência.
Existe import read-only de ZFS?
Sim. OpenZFS documenta zpool import -o readonly=on -N para importar sem montar datasets e sem escrever no pool.
O que é LVM-thin no Proxmox?
É um backend de block storage com thin provisioning. O thin pool possui um data LV e um metadata LV; as VMs aparecem como thin logical volumes em formato raw.
A metadata do LVM-thin é importante?
Sim. Ela rastreia a relação entre thin LVs e blocos físicos. A documentação LVM alerta que danos pequenos na metadata podem causar perda significativa e que exhaustion pode tornar o pool inconsistente.
lvconvert --repair é sempre destrutivo?
Não. É um mecanismo oficial do LVM. Ele cria uma cópia reparada da metadata usando o pmspare e preserva a metadata anterior como ThinPool_metaN quando o reparo é bem-sucedido. Em recovery, preservar as estruturas originais continua sendo importante.
LVM-thin cheio pode corromper VMs?
Sim. O Proxmox alerta que, se o storage thin fica cheio, guests recebem I/O errors e podem ocorrer inconsistências de filesystem.
QCOW2 corrompido pode ser recuperado?
Pode existir viabilidade. qemu-img consegue inspecionar e verificar consistência de QCOW2. Com -r ele tenta repair, mas -r all possui maior risco de escolher a correção errada ou esconder corrupção.
O que é backing file chain no QCOW2?
QCOW2 pode armazenar apenas diferenças em relação a um backing file. Uma chain base.qcow2 <- snap1.qcow2 <- snap2.qcow2 depende da ordem correta. qemu-img info --backing-chain enumera a cadeia.
qemu-img check -r all é seguro?
É uma operação de repair. QEMU alerta que -r all pode escolher fix inadequado ou ocultar corrupção existente. Em dados únicos, preserve uma cópia antes de reparar.
Ceph em Proxmox pode ser recuperado?
Pode existir viabilidade conforme o estado de MONs, OSDs, pools, PGs e imagens RBD. RBD distribui imagens em objetos e suporta snapshots, clones e trash restore.
Snapshot Ceph é backup?
Não por definição. Ceph documenta snapshots RBD como point-in-time. Sem coordenação com o guest eles são crash-consistent.
Imagem RBD apagada pode ser restaurada?
Ceph oferece trash/deferred delete e rbd trash restore para imagens ainda presentes no trash.
Perder quorum significa perder os dados?
Não. Proxmox usa quorum para manter estado consistente do cluster. Sem quorum, pmxcfs pode ficar read-only e as VMs podem ficar indisponíveis, mas os VM disks podem continuar intactos.
O que é pmxcfs?
É o Proxmox Cluster File System que distribui configurações em /etc/pve. O Proxmox documenta recuperação de config.db em cenários de host perdido.
É possível recuperar configuração de VMs de um nó falhado?
Sim, em cenários suportados. Proxmox documenta recuperação de config.db e guest configs, especialmente quando os disks permanecem em shared storage.
RAID-Z é igual a RAID 5/6?
Não exatamente. RAID-Z usa arquitetura ZFS com copy-on-write, checksums e metadata própria. RAIDZ1 tem uma paridade, RAIDZ2 duas e RAIDZ3 três.
VM deletada pode ser recuperada?
Pode existir viabilidade conforme o backend. Ceph pode manter imagens no trash; file storage pode permitir recuperação se blocos não foram reutilizados; thin/discard/TRIM mudam o cenário.
Container LXC pode ser recuperado?
Pode. Rootfs pode residir em ZFS subvol, LVM-thin, directory ou outros backends. Primeiro recupera-se o storage e depois o rootfs/config do container.
Proxmox Backup Server ajuda?
Sim, se houver backup íntegro e independente. Restore de backup validado é preferível à recuperação de emergência sempre que disponível.
É possível recuperar Proxmox remotamente?
Sim, em muitos casos lógicos. Se os storages estão acessíveis e estáveis, logs, configurações, imagens e volumes podem ser avaliados remotamente.
Preciso levar o servidor inteiro?
Na maioria dos casos lógicos, não. Logs, storage.cfg, config.db, VM configs, imagens/volumes e cópias podem ser suficientes. Falha física normalmente exige apenas as mídias necessárias.
Quanto custa recuperar Proxmox?
O custo depende do backend, número de VMs/containers, volume de dados, ZFS/LVM-thin/Ceph, falhas físicas, cluster e intervenções anteriores.
Quanto tempo leva?
Depende da camada. Uma chain QCOW2 lógica tende a ser mais simples que ZFS com múltiplos vdevs ou Ceph com vários OSDs degradados.
A SECURITY atende Proxmox 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 e recuperação remota para todo o Brasil
Remoto
Logs, storage.cfg, config.db e storages acessíveis podem ser analisados por sessão segura.
Mídias físicas
Se há falha em HDD/SSD/RAID, enviam-se as mídias afetadas.
Servidor completo
Normalmente desnecessário.
Todo o Brasil
Triagem lógica independe 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 Proxmox de alta complexidade, conecta ZFS, LVM-thin, Ceph e QCOW2 às camadas de storage, RAID Low Level e análise hexadecimal com WinHex, além de PC-3000 e Data Extractor quando existe falha física.
Proxmox VE por dentro: ZFS, LVM-thin, Ceph, QCOW2 e cluster
1. Modelo de storage Proxmox
Storages de arquivo e bloco usam plugins e estruturas diferentes.
2. Directory storage
Pode armazenar raw/qcow2 e conteúdos adicionais.
3. NFS e CIFS
Storages de arquivo compartilhados.
4. iSCSI
Block storage compartilhado.
5. Fibre Channel
LUN SAN pode integrar LVM/shared storage.
6. Local ZFS
zvol/raw para VMs e subvol para containers.
7. ZFS snapshots
Snapshots e clones são nativos do backend.
8. Sparse ZFS
Thin provisioning exige capacidade monitorada.
9. Import read-only
readonly=on -N permite inspeção sem mount/escrita.
10. zpool -f
Força import de pool potencialmente ativo; não descarta por si só.
11. zpool -F
Rewind pode descartar TXGs recentes.
12. zpool -X
Extended rewind é extremo.
13. ZFS checkpoints
Podem fornecer um ponto definido de rollback quando existentes.
14. RAIDZ1/2/3
Uma, duas ou três paridades no ecossistema ZFS.
15. LVM-thin backend
Block volumes raw em thin pool local.
16. Thin data LV
_tdata contém blocos das VMs.
17. Thin metadata LV
_tmeta mapeia os thin volumes.
18. Thin pool full
Guests recebem I/O errors e podem corromper filesystem.
19. Metadata exhaustion
Exige check/repair offline.
20. lvconvert --repair
Cria metadata reparada e preserva a anterior quando possível.
21. QCOW2
Copy-on-write com backing files em file storage.
22. qemu-img info
Enumera backing chain sem repair.
23. qemu-img check
Verifica consistência.
24. qemu-img -r
É repair; -r all tem maior risco.
25. Ceph RBD
Block images distribuídas em RADOS.
26. Ceph snapshots
Point-in-time e crash-consistent sem coordenação guest.
27. Ceph trash
Imagens podem ser restauradas antes de remoção definitiva.
28. Ceph MONs
Mantêm cluster maps e quorum.
29. Ceph OSDs/PGs
Objetos são distribuídos conforme pool e CRUSH.
30. Cluster quorum
Sem quorum, operações podem ficar read-only sem data loss.
31. pmxcfs
Distribui /etc/pve e configuração do cluster.
32. config.db
Pode ser recuperada em host novo em cenários suportados.
33. Guest configs
VMs em qemu-server e containers em lxc.
34. Recovering guests
Shared storage pode permitir recuperação de configs de nó falhado.
35. KVM
Executa VMs via QEMU.
36. LXC
Containers usam rootfs em vários backends.
37. Storage full
Overcommit requer monitoramento de capacidade.
38. TRIM/discard
Pode devolver blocos e afetar dados deletados.
39. Backup
Backup independente e testado é preferível.
40. Snapshots não são backup
Dependem do mesmo backend.
41. Ransomware
Pode atingir host, images e backups montados.
42. RAID hardware
Se existe abaixo do Proxmox, precisa ser recuperado primeiro.
43. RAID Low Level
Disk order, stripe, parity e offsets em arrays falhados.
44. PC-3000
Quando HDD/SSD suportado tem falha física/firmware.
45. Sala limpa ISO-5
Quando HDD mecânico exige intervenção.
46. WinHex
Auxilia análise de baixo nível, não substitui ferramentas nativas.
47. Recuperação remota
Casos lógicos estáveis podem ser analisados por sessão segura.
48. Segunda opinião
Toda tentativa anterior precisa ser documentada.
49. Matriz técnica de decisão
| Sintoma | Camada | Prioridade | Evitar |
|---|---|---|---|
| ZFS não importa | vdev/pool | read-only / clone | -F/-X no original |
| LVM-thin inactive | thin metadata | preservar _tmeta/_tdata | recriar pool |
| QCOW2 corrupt | image/chain | copy + check | -r all no original |
| Ceph degraded | MON/OSD/PG/RBD | preservar maps | remover OSDs por tentativa |
| Sem quorum | corosync/pmxcfs | separar cluster de storage | reinstalar storage |
| RAID degraded | físico | diagnosticar/clonar | rebuild repetido |
50. Conclusão técnica
Recuperação Proxmox começa pela identificação do backend e preservação do estado. ZFS, LVM-thin, Ceph e QCOW2 possuem metadados diferentes. Em muitos casos lógicos, o trabalho pode começar remotamente, sem transportar o servidor.
