A regra mais antiga do ZFS era “você não pode adicionar um disco a um vdev RAIDZ”. Por quinze anos isso significava que expandir um NAS caseiro era ou um backup-e-restauração completo ou comprar um kit inteiro de discos de um segundo vdev de uma vez. OpenZFS 2.3 trouxe expansão RAIDZ, e a regra desapareceu. Adicione um disco a um RAIDZ1 existente, aguarde o reflow, e o vdev fica mais largo sem reconstrução.
As sete melhores ferramentas para expansão ZFS RAIDZ abaixo cobrem a expansão em si, o monitoramento que você quer durante um reflow de 30 horas em um NAS caseiro de 8 bays, e as ferramentas de snapshot e replicação que mantêm um pool em execução seguro enquanto você o expande. Tudo funciona no Linux (TrueNAS SCALE, Debian, Ubuntu Server, Proxmox); a maioria também funciona no FreeBSD.
O que procurar em um kit de ferramentas para expansão RAIDZ
- OpenZFS 2.3 ou mais recente como runtime, porque
zpool attachpara vdevs RAIDZ é o recurso que torna tudo isso possível. - Uma UI web ou dashboard que mostre o progresso da expansão sem deixar
zpool statusaberto em um terminal por um dia. - Automação de snapshots para manter snapshots pré-expansão para reversão.
- Replicação para um segundo host ou alvo na nuvem, porque expansão não é o mesmo que backup.
- Alertas para erros de scrub, falhas de resilver e o próprio processo de expansão.
- Suporte a rebalanceamento, porque dados escritos antes da expansão ficam na largura de stripe original até você reescrevê-los.
Tabela de comparação rápida
| App | Melhor para | Plataformas | Plano gratuito | Preço inicial/mês | Classificação |
|---|---|---|---|---|---|
| OpenZFS 2.3 | O runtime que faz a expansão | Linux, FreeBSD, illumos | Totalmente gratuito (CDDL) | Gratuito | Essencial |
| TrueNAS SCALE 24.10+ | Expansão via UI web | Bare-metal, VM | Totalmente gratuito | Gratuito (suporte Enterprise é extra) | Recomendado |
| Cockpit ZFS Manager | Gerenciamento de pool dentro do Cockpit | Linux | Totalmente gratuito (OSS) | Gratuito | Leve |
| Sanoid | Políticas automatizadas de snapshot | Linux | Totalmente gratuito (OSS) | Gratuito | Favorito da comunidade |
| zrepl | Replicação de snapshot com criptografia | Linux, FreeBSD | Totalmente gratuito (OSS) | Gratuito | Sólido |
| Houston UI | Console web Rocky Linux para ZFS | Rocky Linux | Totalmente gratuito (OSS) | Gratuito | Novo mas promissor |
| zfs-auto-snapshot | Snapshots simples por hora/dia | Linux | Totalmente gratuito (OSS) | Gratuito | Testado em batalha |
As ferramentas
1. OpenZFS 2.3 – o runtime que torna a expansão possível
OpenZFS 2.3 é onde zpool attach para vdevs RAIDZ vive. O comando é uma linha: zpool attach tank raidz1-0 /dev/sdX. O pool fica online durante o reflow, leituras e escritas continuam, e quando termina o vdev tem mais um disco de capacidade. Todas as outras ferramentas abaixo assumem esse runtime.
Onde fica aquém: Novas escritas após a expansão usam o stripe mais largo. Dados escritos antes da expansão mantêm a largura de stripe antiga até você reescrevê-los. Além disso, expansão RAIDZ é um attach por vez; um segundo attach não pode começar até o primeiro terminar.
Preço:
- Gratuito.
Plataformas: Linux, FreeBSD, illumos.
Download: OpenZFS releases no GitHub
Conclusão: Instale OpenZFS 2.3 primeiro. Tudo o mais é suporte.
2. TrueNAS SCALE 24.10 – melhor para expansão via UI web
TrueNAS SCALE 24.10 e mais recente vêm com OpenZFS 2.3 com expansão RAIDZ exposta na guia Storage. Adicione o disco, clique em Expand VDEV, confirme, e observe a barra de progresso do reflow passar horas ou dias dependendo do tamanho do pool. Alertas disparam quando o reflow termina, além de scrubs, erros SMART e saúde do pool.
Onde fica aquém: Não pode expandir um vdev mirror-of-mirror do mesmo jeito (mirrors sempre foram simples de crescer, então sem perda). Não pode combinar expansão com remoção de vdev em uma operação.
Preço:
- Gratuito: edição comunidade.
- Pago: suporte TrueNAS Enterprise começa em nível de preço de appliance de hardware.
Plataformas: Bare-metal x86, VM.
Download: TrueNAS.com
Conclusão: Se ZFS é sua camada de armazenamento, TrueNAS SCALE 24.10+ é o caminho mais curto de “disco extra em uma prateleira” para “RAIDZ1 expandido”.
3. Cockpit ZFS Manager – melhor para gerenciamento de pool dentro do Cockpit
Cockpit ZFS Manager adiciona um painel ZFS ao console web Cockpit que vem com Fedora Server, Rocky Linux e Debian. Crie datasets, navegue snapshots, faça snapshots manuais e verifique o status do pool sem terminal. A expansão funciona no shell por enquanto, mas a visibilidade é nativa do Cockpit.
Onde fica aquém: UI de expansão é mínima comparada ao TrueNAS. Alguns recursos esperam Cockpit já instalado na máquina.
Preço:
- Gratuito (LGPL).
Plataformas: Linux (Cockpit).
Download: optiplex-networks GitHub
Conclusão: Cockpit ZFS Manager é o add-on certo para um servidor Linux gerenciado pelo Cockpit que roda ZFS como algo secundário.
4. Sanoid – melhor para políticas automatizadas de snapshot
Sanoid aplica um arquivo de política aos seus datasets e pega snapshots por hora, diariamente, mensalmente e anualmente em cronograma. A ferramenta complementar syncoid cuida da replicação. Quando você está prestes a executar uma expansão RAIDZ, o snapshot diário pré-expansão do Sanoid é o ponto de reversão pelo qual você se agradecerá.
Onde fica aquém: Configuração é um arquivo de texto; sem UI web. Debugar replicação em links lentos requer ler logs de syncoid.
Preço:
- Gratuito (GPL).
Plataformas: Linux, FreeBSD.
Download: jimsalterjrs GitHub
Conclusão: Sanoid é a escolha “snapshots automáticos que funcionam” que todo usuário de ZFS deve ter instalado no terceiro dia.
5. zrepl – melhor para replicação criptografada
zrepl cuida da replicação de snapshots entre hosts com chaves de criptografia nativa, modo push ou pull, e regras de holdback para que um alvo falhando não remova seu pool de origem. Ele escala além de um home lab se você colocar o pool em um provedor colocalizado.
Onde fica aquém: Arquivo de config (hcl) tem uma curva de aprendizado. Sanoid faz casos mais simples com menos configuração.
Preço:
- Gratuito (MIT).
Plataformas: Linux, FreeBSD.
Download: zrepl.github.io
Conclusão: Escolha zrepl quando a replicação vai para algum lugar que você não confia completamente e criptografia em repouso não é opcional.
6. Houston UI – melhor para console web Rocky Linux
Houston UI da 45Drives é um console baseado em Cockpit para ZFS em Rocky Linux. Ele expõe criação de pool, gerenciamento de dataset, compartilhamento, e agora expansão RAIDZ em uma UI similar ao TrueNAS SCALE. Preferido por usuários que querem uma base Linux rolling-release sob uma interface ZFS familiar.
Onde fica aquém: Suporte da edição comunidade é best-effort. Suporte Enterprise requer hardware 45Drives.
Preço:
- Gratuito (edição comunidade).
Plataformas: Rocky Linux, AlmaLinux.
Download: 45Drives Houston
Conclusão: Houston UI é uma alternativa forte ao TrueNAS para fãs de Rocky Linux que ainda querem um painel ZFS amigável.
7. zfs-auto-snapshot – melhor para snapshots simples por hora
zfs-auto-snapshot é o original set-and-forget snapshot cron. Ele instala alguns cron jobs e começa a pegar snapshots frequentes, por hora, diários, semanais e mensais com retenção. Ideal quando Sanoid parece excessivo.
Onde fica aquém: Sem replicação embutida. Retenção é por-cronograma, não por-dataset sem config extra.
Preço:
- Gratuito (GPL).
Plataformas: Linux (Debian e Ubuntu o empacotam), FreeBSD (via ports).
Download: zfsonlinux GitHub
Conclusão: zfs-auto-snapshot é a camada de snapshot “um apt install e esqueça” para pools que não precisam da flexibilidade de Sanoid.
Como escolher a correta
- Todos precisam de OpenZFS 2.3 na máquina antes que uma expansão seja sequer possível.
- Se você executa um appliance TrueNAS SCALE, a UI embutida é a resposta completa.
- Em um servidor Linux genérico, adicione Cockpit ZFS Manager ou Houston UI para um painel amigável.
- Aplique Sanoid (ou zfs-auto-snapshot se você quer simples) para política de snapshot.
- Adicione zrepl se a replicação vai para qualquer lugar sensível.
Não empilhe Sanoid e zfs-auto-snapshot no mesmo dataset. Ambos pegam snapshots nos mesmos nomes e lutam pela retenção.
FAQ
Quanto tempo leva uma expansão RAIDZ em um NAS caseiro?
Para um disco de 8 TB adicionado a um RAIDZ1 de 4 vias saudável, espere 12 a 30 horas dependendo de quão cheio o pool está. Leituras e escritas continuam durante o reflow; o desempenho cai mas o pool fica online.
Ainda preciso reescrever arquivos existentes após expansão RAIDZ?
Meio que sim. Arquivos escritos antes da expansão mantêm a largura de stripe antiga, então o disco adicionado contribui menos para leituras nesses arquivos até você reescrevê-los. Um zfs send | zfs recv no dataset (ou uma passagem de syncoid Sanoid) rebalanceia bem. Em um pool grande uma reescrita agendada durante a noite é uma boa ideia.
A expansão RAIDZ é segura com um scrub em execução?
A expansão não começará enquanto um scrub está em voo; ZFS recusa limpamente. Aguarde o scrub, depois comece a expansão. Faça um snapshot primeiro.
Qual é a diferença entre expansão RAIDZ e adicionar um vdev?
Expansão alarga um vdev existente por um disco por vez. Adicionar um vdev cria um grupo RAIDZ separado dentro do mesmo pool. Ambos crescem a capacidade; expansão mantém a proporção de paridade que você já tinha, enquanto adicionar um vdev multiplica a tolerância a falhas.
Posso expandir um RAIDZ2 ou RAIDZ3?
Sim. zpool attach para RAIDZ funciona para RAIDZ1, RAIDZ2 e RAIDZ3 no OpenZFS 2.3 e mais recente. O comando é o mesmo; o reflow apenas move blocos de paridade apropriados ao nível RAIDZ.
