RAIDZ2 ou RAIDZ3: quanta paridade um pool ZFS grande precisa?

O que cada nível de paridade sobrevive?

O manual do OpenZFS estabelece a regra: um grupo raidz de N discos com P discos de paridade comporta cerca de (N − P) vezes o tamanho do disco e sobrevive a P dispositivos com falha. O RAIDZ2 sobrevive a dois, o RAIDZ3 a três.

A mesma página recomenda de 3 a 9 dispositivos por grupo, "para ajudar a aumentar o desempenho". Um grupo de dez drives fica um acima dessa faixa. A faixa é sobre desempenho, não segurança: a paridade cobre P falhas em qualquer largura.

Cada drive de paridade extra compra mais uma falha e custa um drive de espaço. Em Hold 160, isso são 16 TB, ou 12,5% da capacidade do RAIDZ2.

Quanto tempo o pool fica exposto durante um resilver?

Tanto quanto o novo drive levar para encher. O ZFS faz resilver apenas dos dados que o pool contém, então um pool pela metade reconstrói cerca da metade dos bytes.

• Melhor caso, drive de 16 TB cheio: 16 TB na velocidade máxima de 285 MB/s de um Seagate Exos X20 leva cerca de 15,6 horas.
• Pool ocupado, exemplo a 50 MB/s: o mesmo drive leva cerca de 89 horas, ou 3,7 dias.
• Antes de o resilver começar: um drive com falha em um servidor alugado espera o datacenter trocá-lo. Quando um disco falha, abra um ticket: a equipe faz a troca sem custo, e reconstruir o array no novo disco fica por conta da sua configuração.

Durante essa janela, o RAIDZ2 tem uma paridade restante e o RAIDZ3 tem duas. A aritmética de reconstrução para drives de 10 a 20 TB está em quanto tempo leva uma reconstrução RAID 6 ou RAIDZ2.

O que os setores ilegíveis mudam?

Eles tornam o terceiro drive de paridade útil mesmo sem uma terceira falha. O data sheet do Exos X20 especifica erros de leitura não recuperáveis de 1 setor a cada 10^15 bits lidos. Isso é um setor a cada 125 TB lidos, no teto do data sheet.

Um resilver lê os drives sobreviventes. Em um pool cheio de dez drives de 16 TB, nove sobreviventes comportam 144 TB, então o teto permite cerca de um setor ilegível. Drives reais costumam se sair melhor que a especificação; a especificação é o pior caso que o fabricante aceita.

• RAIDZ2, um drive a menos: o ZFS reconstrói um setor ilegível a partir da paridade restante. Nada é perdido.
• RAIDZ2, dois drives a menos: não resta paridade. O bloco é perdido, e zpool status -v lista os arquivos que contêm erros de dados.
• RAIDZ3, dois drives a menos: resta uma paridade, então o setor é reconstruído.

O RAIDZ3 é seguro para a segunda falha, não para a primeira.

Qual é a probabilidade de uma segunda falha durante a janela?

Pequena, no papel. A Backblaze relatou uma taxa anualizada de falhas ao longo da vida útil de 1,41% em seus drives, no relatório do Q2 2026. Ao longo de um resilver de 89 horas, um drive falha com probabilidade de cerca de 1,41% × 89 ÷ 8.760, ou 0,014%. Com nove sobreviventes, a chance de mais uma falha é de cerca de 0,13%.

Essas contas tratam as falhas como independentes. Drives comprados juntos compartilham modelo, lote e idade, e um resilver força todos os sobreviventes. Os números são um piso, não uma previsão.

O mercado está migrando para esse tamanho. Dos 23 vendedores de servidores de armazenamento que Basalthold verificou em 2 November 2026, 8 listavam um servidor com 100 TB ou mais de discos rígidos.

Posso mudar de RAIDZ2 para RAIDZ3 depois?

Não. O OpenZFS 2.3 adicionou a expansão RAID-Z: você pode anexar um novo disco a um grupo existente, com o recurso de pool raidz_expansion. O manual é explícito que "um RAID-Z2 continua sendo um RAID-Z2 mesmo após a expansão". Blocos antigos também mantêm sua antiga proporção de dados por paridade.

Mudar o nível de paridade significa copiar os dados para fora, destruir o pool e criá-lo de novo. Em um servidor alugado, o momento certo é na entrega, quando os drives de dados ainda estão em branco. O sistema operacional fica em um SSD próprio (dois SSDs espelhados no modelo maior); os discos de dados chegam vazios e sem partição, para você montar ZFS, um array mdadm ou um conjunto de discos independentes. Se quiser que a equipe prepare um array RAID 6 ou RAID 10 antes da entrega, avise o suporte antes da entrega do servidor.

# your ten data drives by stable ID; the system SSDs stay out of the pool
ls -l /dev/disk/by-id/ | grep -v part

# three drives' worth of parity (replace DRIVE01 to DRIVE10 with the real IDs)
zpool create -o ashift=12 -O compression=lz4 tank raidz3 /dev/disk/by-id/ata-DRIVE{01..10}

# capacity, health, and the files hit by any data error
zpool list tank
zpool status -v tank

Qual devo escolher em um servidor de armazenamento alugado?

Escolha pelo que o pool serve e por quanto tempo uma falha pode esperar.

• RAIDZ2: um destino de backup cujos originais vivem em outro lugar. Um arquivo perdido pode ser copiado de novo.
• RAIDZ3: um arquivo que é a única cópia por um tempo, um pool que você não consegue acompanhar todos os dias, ou drives tão grandes que um resilver sob carga dura dias.
• Dois ou quatro drives: um mirror em Hold 24; em Hold 40, RAIDZ2 e mirrors em stripe mantêm ambos 20 TB: o RAIDZ2 sobrevive a quaisquer duas falhas, os mirrors dão I/O aleatório mais rápido.

Hold 100 e Hold 160 têm cada um dez drives de dados; seus termos estão na página de preços da Basalthold.

Paridade não é backup. Um servidor de armazenamento não é backup de si mesmo: não guardamos nenhuma cópia dos seus dados em outro lugar, então uma segunda cópia em outro local continua sendo responsabilidade sua. A segunda cópia usual para um NAS está em qual é o melhor backup offsite para um NAS. O mesmo trade-off sem ZFS está em RAID 6 ou RAID 10, e por que o ZFS quer os drives brutos está em ZFS ou RAID de hardware.