Gerenciar o armazenamento do Proxmox, visualmente
O armazenamento no Proxmox é poderoso, mas disperso: o ZFS vive em um lugar, o LVM em outro, e o que um disco está realmente fazendo vive na linha de comando. Quando um pool diz degraded, as primeiras perguntas são sempre as mesmas: qual disco, quão grave, o que fazer agora? Esta página cobre duas coisas: decisões de armazenamento que se sustentam em qualquer configuração, e como o Atlas mostra um disco do pool até o caminho de dados em um único mapa.
Por que o armazenamento fica confuso
As camadas vivem em telas separadas: disco físico, RAID/pool, dataset/LV, e o disco da VM por cima. Para ver em qual camada um problema vive, é preciso olhar quatro lugares.
ZFS, LVM-thin ou Btrfs? A decisão tomada no momento da instalação é a mais difícil de mudar depois, e a maioria dos guias dedica apenas uma frase a ela.
A saúde é invisível: quando rodou o último scrub, por que o pool está degraded, para onde vai a capacidade, na maioria das configurações isso só aparece quando algo quebra.
Uma rotina de armazenamento sólida
Seja qual for o sistema de arquivos escolhido, isto não muda:
Escolher a camada deliberadamente: LVM-thin para um único disco e flexibilidade; ZFS para integridade, compressão e snapshots.
Construir redundância desde o início: a decisão mirror/raidz é tomada na criação do pool; converter depois significa mover dados.
Agendar os scrubs (mensal é um bom ritmo) e ler o resultado; um erro de scrub é o alerta antecipado.
Levar a sério os sinais do disco: setores realocados crescentes são a carta de despedida de um disco; a troca é feita antes que ele obrigue a isso.
Um snapshot não é um backup: ele vive no mesmo pool e morre com ele. Manter uma cópia em um dispositivo separado (por exemplo, PBS) para desastres.
Deixar margem: o ZFS começa a ficar lento acima de 80 por cento; a expansão é planejada antes que o pool encha.
O Atlas coloca o armazenamento em um único mapa
Disco → pool → caminho de dados, em um único mapa de fluxo:
Quatro camadas, uma tela
ZFS, LVM, Btrfs e mdadm na mesma interface: pools, datasets, LVs e discos em uma única imagem em vez de abas separadas.
Assistente de criação de pool
Um novo pool, passo a passo: seleção de disco, redundância, nomeação; o que vai acontecer fica claro antes de aplicar.
Selos de redundância no mapa
Cada pool aparece no mapa de fluxo com o próprio selo (mirror, raidz ou disco único): tudo se lê de relance, sem precisar decorar.
Explorador de datasets
Percorra a árvore de datasets do ZFS: tamanhos, uso, qual VM escreve onde.
A saúde é visível
Estado do pool (online/degraded) e capacidade de relance; quando algo está errado, o mapa mostra em qual camada isso vive.
Operações seguras
Etapas destrutivas (limpeza, formatação) exigem confirmação explícita; o que pode ser desfeito é honestamente separado do que não pode, sem desfazer falso.
Perguntas frequentes
- Devo escolher ZFS ou LVM-thin?
- O LVM-thin é prático em um único disco com RAM limitada. Para integridade, compressão e snapshots flexíveis, o ZFS é a escolha. O ZFS gosta de RAM, mas retribui em integridade.
- Meu pool diz degraded. O que devo fazer?
- Sem pânico: degraded significa que a redundância caiu; os dados ainda estão acessíveis. O disco com falha é identificado e trocado, o pool não deve ser sobrecarregado até o resilver terminar, e o backup é verificado contra uma segunda falha enquanto isso.
- Com que frequência um scrub deve rodar?
- Mensal é um ritmo comum e suficiente para uso doméstico e de laboratório. O que importa é que ele rode regularmente e que alguém leia o resultado; scrubs são o que detecta corrupção silenciosa.
- Um snapshot conta como backup?
- Não. Um snapshot vive no mesmo pool; se o pool ou o disco morre, o snapshot morre junto. Snapshots servem para reversão rápida, uma cópia em um dispositivo separado serve para desastres.
- Onde eu configuro RAID no Proxmox?
- Sem RAID de hardware, o caminho mais limpo é um espelho ZFS ou um raidz. O mdadm também funciona, mas com ZFS disponível geralmente é uma camada extra. O Atlas expõe os dois caminhos na interface.
- Quão cheio é cheio demais para um pool?
- 80 por cento é o limite prático no ZFS: além disso, começam a fragmentação e a lentidão. Perto do limite, os snapshots antigos são limpos primeiro e a expansão vem depois.
Verbetes relacionados
- Como dispor os discos: espelho ou paridade distribuída A pergunta não é qual é mais rápido. É a qual falha você quer sobreviver e o que a máquina será obrigada a fazer depois dessa falha.
- Adicionar um disco e crescer o pool: o passo que encerra a redundância em silêncio Adicionar um disco são dois trabalhos distintos: fazer o sistema enxergá-lo, e decidir a que lugar ele pertence. Um erro no segundo pode encerrar a redundância de vez.
- Discos órfãos: a pergunta antes de apagar Você apagou a máquina mas o espaço não voltou. Os discos que ficam para trás ficam por três motivos diferentes, e não são a mesma coisa. A própria lista é uma lista de exclusão, então a confiabilidade dela é um assunto à parte.
- O disco encheu: para onde foi o espaço e o que é seguro apagar Num armazenamento cheio o primeiro passo não é apagar, e sim descobrir para onde foi o espaço. Snapshots, backups antigos e discos órfãos são os três suspeitos de sempre, e apagá-los não traz o mesmo risco.