"Qual storage devo usar no Proxmox?" é a pergunta que mais recebemos, e a resposta honesta não é ZFS nem Ceph — é depende de quantos nós você tem e de quanto dado você aceita perder. Os dois são excelentes e resolvem problemas diferentes. Escolher pelo que está em alta, e não pelo seu cenário, gera ou um cluster caro demais para o porte, ou um ambiente que promete alta disponibilidade e não entrega.

A diferença que organiza toda a decisão

ZFS é um sistema de arquivos local. Ele vive dentro de um nó, cuida dos discos daquele nó e faz isso muito bem: detecta corrupção silenciosa, corrige com a cópia boa, tira snapshot instantâneo e comprime na escrita. O que ele não faz é compartilhar armazenamento entre nós.

Ceph é armazenamento distribuído. Ele junta os discos de vários nós num pool comum, replica cada bloco em mais de um nó e continua funcionando quando um nó cai. A VM não está presa a um servidor — o disco dela está no cluster.

Dessa diferença sai tudo o mais. Com ZFS, o disco da VM mora num nó específico; para a VM subir em outro lugar, o dado precisa ter sido copiado antes. Com Ceph, qualquer nó já vê o disco, e a VM sobe em segundos onde houver capacidade.

O que o ZFS entrega de verdade

Subestimar o ZFS por ele ser local é um erro comum. O que ele oferece é substancial:

• Integridade verificável. Checksum em tudo. Bit que apodrece no disco é detectado e corrigido a partir da cópia boa, em vez de virar corrupção silenciosa no banco de dados do cliente.
• Snapshot instantâneo e barato, por ser copy-on-write. Snapshot antes de atualizar um sistema deixa de ser um procedimento e passa a ser um reflexo.
• Compressão que acelera. Com LZ4, a compressão costuma melhorar a performance: menos bytes lidos do disco compensa com folga o custo de CPU.
• Replicação nativa com send/receive, que envia apenas o que mudou entre dois snapshots.
• Simplicidade operacional. Um nó, um pool. Sem rede de cluster, sem quórum de storage, sem curva de aprendizado de Ceph.

O custo é RAM. O cache do ZFS (ARC) usa memória de forma agressiva por projeto, e essa memória não está disponível para VMs. Em um host de virtualização, limite o ARC explicitamente e considere essa reserva no dimensionamento — senão você descobre a conta quando as VMs começarem a sofrer.

O que o Ceph entrega — e o que ele cobra

O ganho central do Ceph é a eliminação do ponto único de falha no armazenamento, e a consequência prática é alta disponibilidade real: nó morre, VM sobe em outro em segundos, sem perder uma escrita. Ele também se recupera sozinho — perdeu um disco, o cluster recria as cópias faltantes sem intervenção — e cresce adicionando nós.

O que ele cobra é concreto e precisa entrar na conta:

1. Número mínimo de nós. Três é o mínimo teórico para replicação em três cópias. Na prática, quatro dão folga para você perder um nó e ainda ter margem de manutenção sem operar no limite.
2. Rede dedicada e rápida. Ceph em rede compartilhada de 1 Gbps é a receita mais confiável de decepção. Considere 10 Gbps como piso, com rede pública e rede de cluster separadas.
3. Capacidade bruta triplicada. Com três cópias, cada terabyte útil consome cerca de três brutos. É o item que mais surpreende quem orçou o cluster olhando só o número do datasheet dos discos.
4. Conhecimento. Ceph tem vocabulário próprio — OSD, MON, PG, CRUSH. Ele funciona muito bem quando bem configurado, e é implacável quando é operado no chute.

O comparativo direto

O caminho do meio que muita gente ignora

Existe uma opção intermediária, e ela resolve uma faixa enorme de casos: ZFS com replicação agendada entre nós do cluster. Você mantém a simplicidade do storage local e o Proxmox envia snapshots incrementais para outro nó em intervalos curtos.

O resultado é honesto: se o nó morrer, a VM sobe no destino com o dado do último snapshot replicado. Se o intervalo é de cinco minutos, você aceita perder até cinco minutos. Não é zero, mas para muitos serviços é perfeitamente aceitável — e custa uma fração de um cluster Ceph.

Esse é o desenho que recomendamos com mais frequência para ambientes de dois ou três nós: ZFS em cada host, replicação a cada poucos minutos das VMs que importam e Proxmox Backup Server para retenção. Só migre para Ceph quando o RPO de minutos deixar de ser aceitável ou quando o número de nós justificar.

Como escolher, na prática

Três perguntas resolvem quase todos os casos:

• Quantos nós você tem? Um ou dois: ZFS, sem discussão. Três: ZFS com replicação é o mais sensato, e Ceph é viável se a rede permitir. Quatro ou mais, com 10 Gbps: Ceph passa a ser a escolha natural.
• Quanto dado você aceita perder num incidente de nó? Se a resposta é "nada", é Ceph. Se é "alguns minutos", ZFS com replicação resolve por muito menos dinheiro.
• Qual é a sua rede? Sem 10 Gbps dedicado, não faça Ceph. Não é preciosismo: é a diferença entre um cluster que funciona e um que parece lento sem motivo aparente.

Não empilhe ZFS embaixo do Ceph

Um erro que aparece com regularidade: colocar OSDs do Ceph sobre volumes ZFS, para "ter o melhor dos dois". O resultado é duas camadas de copy-on-write brigando, dupla contabilidade de checksum, consumo de RAM somado e performance ruim.

Ceph quer o disco cru. Se o nó vai ser nó de Ceph, entregue os discos diretamente ao Ceph. ZFS, nesse host, no máximo para o sistema operacional.

Discos e cache: onde a escolha erra silenciosamente

Os dois sistemas foram feitos para armazenamento de servidor, e isso tem uma implicação prática que atinge quem tenta economizar: SSD de consumo com proteção de perda de energia ausente destrói a performance de escrita síncrona. Em ZFS, isso aparece no ZIL/SLOG. Em Ceph, aparece no journal dos OSDs.

O sintoma é sempre o mesmo e confunde: o disco tem número de datasheet excelente, o benchmark sequencial é ótimo, e a aplicação real está lenta. Use disco com proteção de energia para essas funções. É um dos poucos lugares onde o modelo do componente, e não o desenho, decide a experiência.

Nenhum dos dois é backup

Vale dizer com clareza, porque a confusão é frequente e caríssima. ZFS espelhado sobrevive à morte de um disco. Ceph com três cópias sobrevive à morte de um nó. Nenhum dos dois sobrevive a um rm -rf bem-sucedido, a um ransomware que cifra os arquivos ou a um erro de aplicação que corrompe o banco — porque nesses casos a replicação faz exatamente o seu trabalho e replica o estrago.

Snapshot ajuda, e ajuda muito, mas mora no mesmo lugar que o dado. Backup é cópia separada, com retenção, em outro sistema. Nos dois cenários, Proxmox Backup Server entra como camada distinta e obrigatória.

Erros comuns

• Ceph em três nós com rede de 1 Gbps compartilhada, e a conclusão de que "Ceph é lento".
• Orçar capacidade de Ceph sem multiplicar por três a replicação.
• Não limitar o ARC do ZFS e culpar as VMs pela falta de memória.
• Assumir HA real com ZFS local, sem replicação configurada.
• Empilhar OSD de Ceph sobre volume ZFS.
• SSD de consumo em função de journal ou SLOG.
• Tratar snapshot como backup e descobrir o contrário no incidente.
• Ir de ZFS para Ceph por moda, sem que o RPO exigisse.

Onde a Solvefy/Cloud entra

Como parceiros oficiais Proxmox, essa escolha é uma das primeiras coisas que definimos em projeto: levantamos número de nós, rede disponível, perfil de carga e o RPO que o negócio realmente tolera — e recomendamos o desenho que atende com o menor custo, não o mais impressionante. Também resgatamos ambientes onde o Ceph foi implantado sem a rede necessária, migrando para um desenho que funciona com o hardware que existe.

Quer saber qual storage faz sentido no seu caso? Fazemos um diagnóstico gratuito da infraestrutura, sem compromisso, em solvefy.cloud.

Solvefy/Cloud — Infraestrutura que cresce com você.