RAID com ZFS: RAIDZ1, RAIDZ2, RAIDZ3 e Mirror

Por Equipe Técnica HD Doctor

Resposta direta

RAID em ZFS não é RAID tradicional. Não existe write hole, todo bloco tem checksum de ponta a ponta e o resilver copia apenas os dados usados, não o disco inteiro. Em compensação, a unidade de falha é o vdev: perder um vdev derruba o pool completo, mesmo com todos os outros perfeitos. É essa regra que decide a topologia certa.

Vdev, pool e por que a topologia importa mais que a marca do disco

Um pool ZFS é um stripe de vdevs, e cada vdev tem sua própria redundância. Mirror duplica (ou triplica) os dados; RAIDZ1, RAIDZ2 e RAIDZ3 distribuem 1, 2 ou 3 blocos de paridade. A tolerância vale por vdev: um pool com quatro vdevs RAIDZ2 aguenta duas falhas em cada um, mas a terceira falha dentro de qualquer um deles leva o pool inteiro. Três diferenças práticas em relação ao RAID de controladora. Primeira: o ZFS precisa enxergar os discos diretamente, via HBA em modo IT — controladora RAID com cache próprio esconde SMART, mente sobre gravação concluída e corrompe pool em queda de energia. Segunda: o resilver do ZFS lê só os blocos alocados, então um pool com 20% de uso reconstrói muito mais rápido que um RAID 5 equivalente; em compensação, é um resilver aleatório e pesado, e é exatamente durante ele que um segundo disco do mesmo lote costuma falhar. Terceira: até o OpenZFS 2.3 (2025, que chegou aos usuários com o TrueNAS SCALE 24.10 Electric Eel) não havia como adicionar disco a um RAIDZ existente — hoje a expansão existe, mas os dados antigos mantêm a proporção de paridade original até serem reescritos. Um detalhe que quase ninguém planeja: vdevs de apoio não são todos iguais em risco. Perder o L2ARC não custa nada e perder o SLOG raramente custa; perder um vdev special, que guarda metadados, destrói o pool inteiro. Special sempre em mirror.

Comparativo por topologia: quando usar cada uma

1.
Mirror (2 ou 3 vias). Tolera 1 disco por vdev (ou 2 no triplo). Melhor IOPS e o resilver mais rápido e mais leve de todos. Custa 50% da capacidade. Escolha padrão para VMs, bancos de dados e qualquer carga aleatória — e para quem quer poder crescer o pool de dois em dois discos.
2.
RAIDZ1. Tolera 1 disco por vdev. Aceitável só com discos pequenos (até ~4 TB) e backup real em outro lugar. Com discos de 12, 16 ou 20 TB o resilver dura dias, e a chance de um segundo disco do mesmo lote falhar nesse intervalo é alta o suficiente para desaconselhar.
3.
RAIDZ2. Tolera 2 discos por vdev. É o padrão sensato para arquivo e backup com 6 a 12 discos por vdev. Sobrevive à falha de um segundo disco durante o resilver, que é justamente o cenário que mais destrói pools RAIDZ1.
4.
RAIDZ3. Tolera 3 discos por vdev. Faz sentido em vdevs largos (12+ discos), discos muito grandes ou quando a reposição demora semanas. Custo de paridade alto, desempenho de escrita baixo.
5.
dRAID. Distribui os discos reserva dentro do próprio vdev, o que reduz o resilver de dias para horas em arranjos grandes. Compensa a partir de algumas dezenas de discos; abaixo disso, complexidade sem retorno.
6.
Stripe sem redundância. Zero tolerância: um disco fora e o pool inteiro se perde. Só para scratch descartável. É também o efeito colateral de adicionar um disco solto por engano a um pool RAIDZ — erro que não tem desfazer.

O que fazer quando um pool ZFS fica degradado, em 6 passos

O momento de maior risco de um pool ZFS não é a falha do primeiro disco: é o resilver que vem depois. Esta é a sequência segura.

1
Confirme o que realmente falhou
zpool status -v mostra o vdev afetado e o tipo de erro. Erros de CRC/UDMA em vários discos ao mesmo tempo apontam para cabo, backplane, expander ou fonte — trocar disco nesse cenário não resolve e ainda gasta a redundância que restou.
2
Faça backup antes do resilver, não depois
Com o pool degradado mas ainda montável, a prioridade absoluta é copiar os dados críticos para fora, de preferência com zfs send. Um pool RAIDZ1 com um disco fora está sem rede de proteção: qualquer erro de leitura durante a reconstrução vira perda.
3
Verifique a saúde dos discos restantes antes de reconstruir
smartctl -a em todos os membros, não só no que falhou. Se outro disco já mostra pending sectors, o resilver provavelmente vai derrubá-lo. Nesse caso, o caminho seguro é imagem dos discos e reconstrução em laboratório, não substituição no equipamento.
4
Substitua com o pool o mais parado possível
Pare serviços, snapshots agendados, replicação e scrub durante o resilver. Quanto menos concorrência de I/O, mais rápido termina e menor a chance de um segundo membro sair. Use zpool replace com o disco novo já conectado, sem remover o antigo se ele ainda responde.
5
Não rode scrub para 'testar' um pool degradado
Scrub lê todos os blocos de todos os discos em carga máxima. Em pool saudável é manutenção obrigatória, mensal. Em pool degradado, é o empurrão que falta para o disco marginal morrer. Scrub depois do resilver concluído, nunca durante ou antes.
6
Se o pool não importar mais, pare tudo
Quando a redundância acabou e o pool não monta, cada tentativa nova de import com -f ou -F consome os uberblocks antigos que permitiriam rewind. Desligue, preserve os discos na ordem original e trate como caso de laboratório: com imagem de cada membro, ainda há caminho de reconstrução.

Perguntas frequentes

RAIDZ2 ou mirror: qual escolher?

Pela carga, não pelo espaço. RAIDZ entrega o IOPS de um único disco por vdev, então é ótimo para arquivo, mídia e backup, e ruim para VM e banco de dados. Mirror entrega muito mais IOPS, resilver mais rápido e crescimento de dois em dois discos, ao custo de metade da capacidade. Storage de virtualização: mirror. Repositório de arquivos: RAIDZ2.

Quantos discos por vdev RAIDZ é o ideal?

Na prática, 6 a 10 discos por vdev RAIDZ2 é a faixa confortável. Vdev muito largo aumenta o tempo de resilver e o risco acumulado; vdev muito estreito desperdiça capacidade em paridade. Com muitos discos, prefira vários vdevs de 8 a somar tudo em um vdev único gigante.

Posso adicionar um disco a um RAIDZ existente?

Sim, desde o OpenZFS 2.3 (2025), que chegou aos usuários com o TrueNAS SCALE 24.10. A expansão adiciona um disco por vez e preserva os dados, mas os blocos antigos mantêm a proporção de paridade que tinham — o espaço só é plenamente aproveitado nos dados reescritos depois. Antes dessa versão, a única saída era criar um vdev novo.

ZFS RAID dispensa backup?

Não. RAID protege contra falha de disco, não contra ransomware, exclusão acidental, erro de administrador, incêndio ou destruição do pool. Snapshot ZFS vive dentro do mesmo pool e cai junto com ele. Backup é replicação para outro sistema, de preferência com uma cópia imutável.

Preciso mesmo de RAM ECC no ZFS?

O ZFS funciona sem ECC, mas o modelo de integridade dele assume que a memória é confiável: um bit corrompido na RAM entra no checksum como se fosse dado bom e é gravado assim. Para storage de produção, ECC é fortemente recomendável. Para homelab, é uma decisão de risco consciente.

Perdi dois discos em um RAIDZ1. Ainda dá para recuperar?

Frequentemente sim, em laboratório. Os dois discos raramente morrem por completo no mesmo instante: costuma haver um disco marginal com poucos setores ruins e outro que caiu por cabo, firmware ou controladora. Com imagem de cada membro e reconstrução do stripe fora do equipamento, a taxa de recuperação é alta. O que mata o caso é insistir em import forçado antes de imaginar os discos.

O que acontece se eu perder o vdev special?

O pool inteiro se perde. O special vdev guarda os metadados: sem ele, o ZFS não sabe onde estão os blocos, mesmo com todos os discos de dados intactos. Por isso ele deve ser sempre em mirror, com o mesmo nível de redundância dos vdevs de dados — regra que muita instalação com SSD 'só para acelerar metadados' ignora.

Pool ZFS degradado ou que não importa mais?

Reconstrução de RAIDZ e mirror em laboratório, com imagem de cada membro. Diagnóstico em 24h.