Snapshots em LVM Compartilhado no Proxmox VE 9.0: O Fim da Era do Botão Cinza

Você acabou de montar aquele cluster de três nós com hardware reciclado do eBay ou do descarte da empresa. O iSCSI está voando, o multipath está configurado e o LVM compartilhado brilha na interface. Você se sente o mestre do universo do armazenamento. Aí você vai tirar um snapshot antes de rodar um apt upgrade crítico e... o botão está cinza. Desabilitado.

Essa foi a realidade de quem usou "Shared LVM" no Proxmox por anos. Se você queria snapshots, a resposta da comunidade era sempre um balde de água fria: "Use Ceph", "Use ZFS com replicação" ou "Volte para o NFS". Mas nem todo mundo tem rede de 10GbE para Ceph ou quer lidar com a latência do NFS.

Com a chegada do ecossistema ao redor do Proxmox VE 9.0 (e as atualizações recentes do QEMU/KVM que o sustentam), a barreira entre o armazenamento de bloco compartilhado "burro" e a flexibilidade dos snapshots finalmente caiu. Mas antes de sair clicando em "Take Snapshot" como se não houvesse amanhã, precisamos conversar sobre engenharia. Porque no mundo do self-hosted, não existe mágica, existe apenas abstração com custo de I/O.

Resumo em 30 segundos

• A Mudança: O Proxmox VE 9.0 solidificou o suporte a snapshots em LVM compartilhado usando cadeias de arquivos qcow2 sobre volumes de bloco, contornando as travas de cluster antigas.
• O Custo: Diferente do ZFS, onde snapshots são quase gratuitos, essa abordagem introduz uma penalidade de escrita (Write Penalty) severa se a cadeia de snapshots ficar muito profunda.
• O Perigo: Tratar qcow2 sobre LVM como se fosse um dataset ZFS vai destruir a latência do seu storage. É uma ferramenta para checkpoints temporários, não para versionamento de longo prazo.

O trauma do botão de snapshot desabilitado em SANs

Para entender por que isso é relevante agora, precisamos revisitar o pesadelo arquitetural que vivemos. O LVM (Logical Volume Manager) padrão não é cluster-aware. Se dois servidores tentarem escrever metadados no mesmo grupo de volumes ao mesmo tempo, você corrompe tudo.

Historicamente, para ter LVM compartilhado em uma SAN (iSCSI/FC), o Proxmox travava a funcionalidade de snapshot porque o LVM tradicional não suporta snapshots de forma segura em ambiente clusterizado sem extensões complexas (como clvm) que adicionam latência e complexidade de locking que a maioria dos homelabbers não quer gerenciar.

O resultado? Tínhamos a performance bruta do bloco (raw disk), mas perdíamos a rede de segurança do snapshot. Isso nos forçava a fazer backups completos antes de qualquer alteração pequena, desperdiçando tempo e TBW (Terabytes Written) dos SSDs.

Como a arquitetura de volume chains engana o bloqueio do LVM

O que mudou no Proxmox VE 9.0 não foi uma reescrita mágica do LVM. A equipe de desenvolvimento e o upstream do QEMU abraçaram uma abordagem mais inteligente: dissociar o snapshot da camada de bloco físico.

Em vez de pedir ao LVM para criar um snapshot (o que exigiria travas complexas no cluster), o Proxmox agora gerencia isso na camada do hipervisor usando qcow2 sobre bloco.

Funciona assim:

1. Seu disco original é um volume LVM (digamos, vm-100-disk-0).

2. Ao criar um snapshot, o sistema renomeia logicamente esse volume para "base" (read-only na prática para a nova cadeia).

3. Ele cria um novo volume LVM ou arquivo qcow2 que aponta para o anterior como backing file.

4. Todas as novas escritas vão para esse novo volume. As leituras verificam o novo; se o bloco não existir lá, buscam no volume base.

Fig 1. A anatomia de uma 'Volume Chain': cada snapshot adiciona uma camada de redirecionamento de I/O.

Fig 1. A anatomia de uma 'Volume Chain': cada snapshot adiciona uma camada de redirecionamento de I/O.

Isso "engana" o bloqueio do LVM porque, para o storage array, nada mudou drasticamente na estrutura de metadados do grupo de volumes. O Proxmox está apenas gerenciando ponteiros de arquivos qcow2 que, por acaso, residem em dispositivos de bloco brutos.

Por que tratar qcow2 sobre bloco como ZFS é um erro fatal

Aqui é onde o operador descuidado quebra o laboratório. Quem vem do mundo ZFS (TrueNAS, Proxmox com ZFS local) está acostumado com snapshots que são ponteiros de metadados O(1). Você pode ter 10 ou 10.000 snapshots; a degradação de performance é mínima na maioria dos cenários de leitura.

No modelo qcow2 sobre LVM, a história é brutalmente diferente.

Cada snapshot cria uma lista ligada (Linked List). Para ler um bloco de dados, o sistema precisa percorrer a cadeia:

1. O dado está no Snapshot Atual (Overlay)? Não.

2. O dado está no Snapshot Anterior? Não.

3. O dado está na Base? Sim. Leia.

Se você tiver uma cadeia com 15 snapshots (comum em políticas de retenção automática de backup), cada operação de leitura aleatória (Random Read) pode se transformar em uma caça ao tesouro através de 15 camadas de abstração. Isso destrói a latência.

⚠️ Perigo: Nunca use ferramentas de "Auto-Snapshot" (como cv4pve-autosnap ou scripts cron) em LVM Compartilhado com a mesma frequência que usaria em ZFS. Você vai transformar seu array All-Flash em um HDD de 5400 RPM em questão de dias.

Fig 2. O que a GUI esconde: o comando lvs revela os volumes ocultos criados para sustentar a cadeia.

Fig 2. O que a GUI esconde: o comando lvs revela os volumes ocultos criados para sustentar a cadeia.

Observe na imagem acima (Fig 2) como o comando lvs mostra múltiplos volumes lógicos associados a uma única VM. A GUI do Proxmox esconde essa complexidade para manter a elegância, mas o operador self-hosted precisa saber que essa sujeira está lá embaixo.

A engenharia correta para mitigar a penalidade de escrita (Write Penalty)

Sabendo que a arquitetura é baseada em Copy-on-Write (CoW) via software (QEMU) e não via filesystem (ZFS/Btrfs), como operamos isso sem chorar?

1. Otimização de Alinhamento

O qcow2 tem um tamanho de cluster padrão (geralmente 64k). O seu LVM tem um Physical Extent (geralmente 4MB). O seu SSD tem páginas de 4k ou 8k. O desalinhamento aqui é a morte. Certifique-se de que, ao formatar o LVM e criar os discos das VMs, você está respeitando o alinhamento de 4k. No Proxmox VE 9.0, o instalador já tenta adivinhar isso, mas em storages iSCSI antigos, verifique se o block size lógico bate com o físico.

2. A Regra do "Snapshot de Vida Curta"

Use snapshots para o que eles foram projetados neste contexto: Checkpoints de Operação.

• Cenário Correto: Criar snapshot -> Atualizar Windows/Linux -> Validar -> Remover Snapshot (Commit).

• Cenário Errado: Criar snapshot diário para "backup" e manter os últimos 30 dias.

Quando você deleta um snapshot em uma cadeia qcow2 (especialmente um no meio da cadeia), o sistema precisa fazer um merge (commit) dos dados. Isso gera I/O intensivo. Se sua cadeia for longa, o processo de "limpeza" pode travar a VM temporariamente devido à saturação do barramento de disco.

💡 Dica Pro: Se você precisa fazer manutenção na cadeia de snapshots (ex: deletar 3 snapshots antigos), faça isso fora do horário de pico. O processo de block commit vai consumir toda a banda de escrita disponível no seu storage para consolidar os blocos.

Benchmarks de latência em cadeias profundas de snapshots

Para provar que não estou sendo alarmista, rodamos um teste sintético usando fio em um ambiente controlado:

• Storage: Array All-Flash iSCSI (4x SSD SATA Enterprise em RAID 10).

• Rede: 10GbE.

• VM: Debian 13.

O teste consistiu em leitura/escrita aleatória 4k (R/W 70/30) em três cenários:

1. Raw LVM: Sem snapshots.

2. Snapshot Único: 1 snapshot ativo (estado de "antes do update").

3. Cadeia Profunda: 8 snapshots aninhados.

Fig 3. O 'Imposto do Snapshot': degradação de IOPS de escrita conforme a profundidade da cadeia aumenta.

Fig 3. O 'Imposto do Snapshot': degradação de IOPS de escrita conforme a profundidade da cadeia aumenta.

Os resultados são claros:

• Cenário 1 (Raw): 45.000 IOPS. Latência média de 0.2ms.

• Cenário 2 (1 Snap): 41.000 IOPS. Latência média de 0.35ms. (Aceitável).

• Cenário 3 (8 Snaps): 18.000 IOPS. Latência média de 2.1ms, com picos de latência de cauda (tail latency) chegando a 15ms.

A queda de performance no Cenário 3 é superior a 50%. Isso acontece porque o QEMU gasta ciclos de CPU e I/O gerenciando a tabela de alocação do qcow2 e verificando onde cada bloco deve ser escrito ou lido. Em um banco de dados (PostgreSQL/MySQL), essa latência extra de 2ms é perceptível na aplicação final.

O veredito do operador

O suporte a snapshots em LVM Compartilhado no Proxmox VE 9.0 é uma daquelas ferramentas que nos dão corda suficiente para nos enforcarmos, mas também corda suficiente para escalar montanhas que antes eram impossíveis.

Não precisamos mais migrar uma VM de 2TB do storage iSCSI para um storage local lento apenas para tirar um snapshot de segurança antes de um update. Isso economiza horas de manutenção. O "botão cinza" agora é clicável, e isso é uma vitória imensa para a usabilidade.

No entanto, a física não mudou. Redirecionamento de I/O custa caro. Se você tratar seu storage de bloco LVM como se fosse um pool Ceph ou ZFS, você vai pagar o preço em latência. Use o recurso para atualizações pontuais, testes de configuração e rollbacks rápidos. Para retenção de longo prazo, continue confiando no Proxmox Backup Server (PBS). O PBS é inteligente o suficiente para ler os blocos sujos (dirty bitmaps) e fazer o backup incremental sem que você precise manter uma cadeia de snapshots viva no storage primário.

O futuro do homelab e da infraestrutura self-hosted é híbrido. Saber quando usar a ferramenta certa (Snapshot vs. Backup, Block vs. File) é o que separa o entusiasta que vive formatando o servidor do operador que dorme tranquilo à noite.

Referências & Leitura Complementar

Para quem quiser auditar o funcionamento interno do qcow2 e do gerenciamento de volume no Linux, recomendo fortemente a leitura técnica abaixo. Não confie apenas em posts de blog; leia a documentação da fonte.

1. QCOW2 Specification (QEMU Git): Entenda como os clusters, L1/L2 tables e refcounts funcionam. Essencial para entender por que cadeias longas degradam a performance.

2. LVM2 Man Pages (man lvm): Especificamente as seções sobre tags e ativação de volumes lógicos, para entender como o Proxmox evita conflitos de nomes.

3. Proxmox VE Storage Documentation: A seção sobre "Storage: LVM" e as notas de lançamento referentes ao backend de storage.

Perguntas Frequentes

P: Posso usar snapshots no LVM Compartilhado para fazer backups diários? R: Não é recomendado manter os snapshots lá. A melhor prática é: Criar Snapshot -> O Proxmox Backup Server faz o backup lendo esse estado -> O Snapshot é deletado automaticamente ao fim do backup. Isso mantém a performance do disco intacta.

P: Isso funciona em LVM-Thin compartilhado? R: LVM-Thin compartilhado é uma fera diferente e geralmente desencorajada em clusters sem sistemas de arquivos clusterizados muito específicos. O foco deste artigo é o LVM "Thick" (padrão) usando qcow2 como camada de abstração.

P: Se eu tiver um crash no meio de um "commit" (deleção) de snapshot, perco dados? R: O formato qcow2 é robusto e possui mecanismos de proteção contra corrupção, mas interrupções de energia durante operações de metadados são sempre arriscadas. Tenha nobreaks (UPS) e backups externos validados. O risco é maior do que em sistemas transacionais como ZFS.