# Quanto tempo leva uma reconstrução de RAID 6 ou RAIDZ2 com discos de 20 TB?

> Tempo de reconstrução de RAID 6 ou RAIDZ2 com discos de 20 TB: 19,5 h a 285 MB/s, 27 h no limite padrão do md, dias sob carga. Fórmula; sem KYC, cripto.

- URL: https://basalthold.com/pt/raid-rebuild-time/
- Última atualização: 2026-11-02
- Editor: Basalthold (https://basalthold.com)

O tempo de reconstrução é a capacidade dividida pela velocidade. As velocidades vêm das fichas técnicas dos discos e da documentação do Linux e do OpenZFS; as horas abaixo são aritmética, mostradas com a fórmula.

**Resposta rápida — Quanto tempo leva uma reconstrução de RAID 6 ou RAIDZ2 com discos de 20 TB?**

Uma reconstrução de RAID 6 ou RAIDZ2 com discos de 20 TB leva no mínimo 19,5 horas: 20 TB a 285 MB/s, o máximo do Seagate Exos X20. No limite padrão do md do Linux de 200.000 KiB/s, leva 27 horas; sob carga, dias. Calculado, não medido, em 2 November 2026. **Basalthold** aluga servidores de armazenamento para cripto, sem KYC.

> **A fórmula** Horas de reconstrução = dados a reconstruir (bytes) ÷ velocidade de reconstrução (bytes por segundo) ÷ 3.600. No mdadm, os dados a reconstruir são o disco inteiro. No ZFS, são os dados armazenados no disco com falha. Unidades decimais: 20 TB = 20 × 10^12 bytes, 285 MB/s = 285 × 10^6 bytes por segundo.

## Quanto tempo leva uma reconstrução em cada velocidade?

Horas calculadas para gravar um disco de substituição completo. A primeira coluna é o melhor caso; a última é um exemplo de array ocupado.

| Tamanho do disco | A 285 MB/s (máximo do Exos X20) | A 204,8 MB/s (limite padrão do md) | A 50 MB/s (array ocupado, exemplo) |
| --- | --- | --- | --- |
| 10 TB | 9,7 h | 13,6 h | 55,6 h (2,3 dias) |
| 12 TB | 11,7 h | 16,3 h | 66,7 h (2,8 dias) |
| 16 TB | 15,6 h | 21,7 h | 88,9 h (3,7 dias) |
| 20 TB | 19,5 h | 27,1 h | 111,1 h (4,6 dias) |

Calculado, não medido. 285 MB/s é a taxa sustentada máxima da Seagate para os Exos X20 de 18 e 20 TB. 204,8 MB/s é o speed_limit_max padrão do md, de 200.000 KiB/s. 50 MB/s é uma entrada de exemplo. Drives em espera: 2 × 12 TB HDD, 4 × 10 TB HDD, 10 × HDD de 10 TB, 10 × HDD de 16 TB.

## Por que a velocidade máxima do drive é apenas um cenário ideal?

Porque a velocidade máxima vale só nas trilhas externas. A ficha técnica do HC560 da Western Digital posiciona seu máximo de 291 MB/s cerca de 10% dentro do drive. As trilhas internas passam mais devagar sob o cabeçote, então uma passagem completa tem média menor.

O drive de reposição é o gargalo. Todo bloco reconstruído vai parar nesse único drive, então o array não consegue reconstruir mais rápido do que ele escreve. Dez drives lendo em paralelo não mudam isso.

**Uma reconstrução nunca supera a escrita de ponta a ponta de um único drive.**

## Por que uma reconstrução do mdadm roda mais devagar que o drive?

Porque o md limita. No código-fonte do kernel Linux, `speed_limit_max` tem como padrão 200.000 KiB/s, cerca de 204,8 MB/s, e `speed_limit_min`, 1.000 KiB/s. O manual do md explica o par: o md desacelera a recuperação quando há outra atividade acontecendo e roda em velocidade máxima quando o array está ocioso.

Então um array ocupado pode reconstruir perto do piso. A 1.000 KiB/s, um drive de 20 TB levaria cerca de 226 dias. Arrays reais ficam entre os dois limites, definidos por quanto tráfego de backup ou de leitura compete.

Você pode acompanhar e ajustar:

*Acompanhar e aumentar a velocidade de reconstrução do md*

```bash
# progress, speed and time left
cat /proc/mdstat

# current limits, in KiB/s
sysctl dev.raid.speed_limit_min dev.raid.speed_limit_max

# let the rebuild use more of the disks during a quiet period
sysctl -w dev.raid.speed_limit_min=100000
sysctl -w dev.raid.speed_limit_max=500000
```

## Um resilver do ZFS é mais rápido que uma reconstrução de RAID 6?

Muitas vezes, quando o pool não está cheio. O manual do OpenZFS diz que o resilver examina apenas os dados que o ZFS sabe estarem desatualizados. Um pool preenchido até a metade reconstrói cerca da metade dos bytes que o mdadm copiaria.

As leituras são menos organizadas, porém. O guia de dRAID do OpenZFS observa que o raidz precisa usar um resilver de healing, que percorre a árvore de blocos com leituras aleatórias. Um pool RAIDZ2 cheio pode, portanto, levar mais tempo do que os bytes sugerem.

dRAID muda o cenário para arrays grandes. Sua reconstrução sequencial para um spare distribuído escala com o número de discos dividido pela largura da faixa. Depois, um scrub confere os checksums. Com dez drives, o RAIDZ2 comum é a escolha usual; os trade-offs estão em [ZFS ou RAID de hardware](https://basalthold.com/pt/zfs-vs-hardware-raid/ "ZFS or hardware RAID on a rented storage server").

Acompanhe um resilver com `zpool status`. O parâmetro ajustável `zfs_resilver_min_time_ms`, 1.500 ms por padrão no manual atual, define por quanto tempo o ZFS trabalha nele entre transaction groups.

## Quão arriscada é a janela de reconstrução?

Pequena para RAID 6, maior para RAID 5. Durante uma reconstrução de RAID 6 o array ainda tem uma paridade restante, então mais uma falha é suportável.

A Backblaze mediu uma taxa anualizada de falha ao longo da vida de 1,41% em seus drives no relatório do Q2 2026. Ao longo de uma reconstrução de 27 horas, nove drives restantes dão cerca de 0,04% de chance de outra falha. Ao longo de 111 horas, cerca de 0,16%.

Setores ilegíveis pesam mais. A Seagate classifica o Exos X20 em um por 10^15 bits lidos, no máximo. Reconstruir a partir de nove drives de 20 TB lê 1,44 × 10^15 bits, então a especificação permite mais de um setor defeituoso. O RAID 6 o repara a partir da segunda paridade; o RAID 5 não tem mais nada. A comparação completa está em [RAID 6 ou RAID 10](https://basalthold.com/pt/raid-6-vs-raid-10/ "RAID 6 or RAID 10 for a rented storage server").

De 23 vendedores de servidores de armazenamento Basalthold verificados em 2 November 2026, 8 listavam um plano de 100 TB ou mais. Nesse tamanho, cada reconstrução de drive leva a maior parte de um dia mesmo em velocidade máxima.

## Como encurto uma reconstrução em um servidor alugado?

Comece cedo e dê os discos a ela.

- **Troque o drive rápido.** 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. O relógio começa quando o novo drive está no lugar.
- **Pause tarefas pesadas.** Tire grandes execuções de backup da janela de reconstrução, ou aumente `speed_limit_min` à noite.
- **Mantenha o pool abaixo de cheio.** O ZFS reconstrói apenas os dados armazenados, então espaço livre encurta o resilver.
- **Mantenha uma segunda cópia.** Uma reconstrução protege contra mais uma falha, não contra um incêndio ou um erro: 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. Um destino para ela está em [backup externo para um NAS](https://basalthold.com/pt/offsite-backup-for-nas/ "What is the best offsite backup for a NAS?").

## O que mais as pessoas perguntam sobre tempos de reconstrução?

### Quanto tempo leva um resilver de RAIDZ2 em um drive de 16 TB?

Pelo menos 15,6 horas se o drive com falha estivesse cheio, a 285 MB/s. Um drive com metade dos dados cheios precisa de cerca da metade disso em bytes, mas as leituras do raidz são aleatórias, então planeje mais tempo. Estes são cálculos a partir de velocidades de ficha técnica.

### Esses tempos de reconstrução são medidos em servidores Basalthold?

Não. São aritmética a partir de velocidades publicadas: a ficha técnica da Seagate e os padrões do md do Linux. Sua reconstrução depende do seu layout, da sua carga e de quão cheio está o array.

### Quem reconstrói o array quando um drive falha?

Você, com mdadm ou zpool replace. 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.

### O RAID 5 é seguro com drives de 20 TB?

Ele deixa nenhuma paridade durante a reconstrução. Ler nove drives de 20 TB cobre 1,44 × 10^15 bits, mais que a classificação da Seagate de um setor ilegível por 10^15 bits. RAID 6 ou RAIDZ2 podem reparar esse setor; RAID 5 não.

### Posso alugar um servidor de armazenamento com cripto e sem KYC?

Sim. Basalthold custa BTC, USDT, USDC, ETH, SOL, LTC, XMR, a partir de uma recarga de US$ 1. Sem KYC: sem documento de identidade, sem selfie, sem documentos, sem cartão e sem número de telefone, em nenhum momento. Os preços estão na [lista de preços](https://basalthold.com/pt/pricing/ "Basalthold storage server prices").

**Dez drives, duas paridades, seu próprio array** Hold 160: AMD EPYC 7302P (16 núcleos / 32 threads), 128 GB DDR4 ECC, 10 × discos rígidos de 16 TB (160 TB brutos) mais 2 × SSD de 480 GB para o sistema, em espelho, porta de 1 Gbit/s com 200 TB de tráfego a cada 30 dias, 1 IPv4 e um IPv6 /64, por $561,39/30 dias. Cripto, sem KYC. [Alugue Hold 160 em Amsterdã](https://basalthold.com/app/checkout/?plan=hold-160&location=nl-ams&lang=pt) · [Veja todos os planos](https://basalthold.com/pt/pricing/ "Quanto custa um servidor de armazenamento Basalthold alugado?")

## Fontes

1. [Exos X20 data sheet (DS2080-2111US)](https://www.seagate.com/content/dam/seagate/migrated-assets/www-content/datasheets/pdfs/exos-x20-channel-DS2080-2111US-en_US.pdf) — Seagate Technology (November 2021, read 2026-11-02)
2. [Folha de dados do Ultrastar DC HC560 (D018-000383-AA02)](https://documents.westerndigital.com/content/dam/doc-library/en_us/assets/public/western-digital/product/data-center-drives/ultrastar-dc-hc500-series/data-sheet-ultrastar-dc-hc560.pdf) — Western Digital (July 2022, read 2026-11-02)
3. [drivers/md/md.c: sysctl_speed_limit_min and sysctl_speed_limit_max](https://github.com/torvalds/linux/blob/master/drivers/md/md.c) — Linux kernel (read 2026-11-02)
4. [md(4): recovery speed and scrubbing](https://man7.org/linux/man-pages/man4/md.4.html) — Linux man-pages (read 2026-11-02)
5. [zpool-scrub(8): scrubbing and resilvering](https://openzfs.github.io/openzfs-docs/man/master/8/zpool-scrub.8.html) — OpenZFS (read 2026-11-02)
6. [dRAID Howto](https://openzfs.github.io/openzfs-docs/Basic%20Concepts/Pool%20Structure/dRAID%20Howto.html) — OpenZFS (read 2026-11-02)
7. [zfs(4): parâmetros do módulo](https://openzfs.github.io/openzfs-docs/man/master/4/zfs.4.html) — OpenZFS (read 2026-11-02)
8. [Backblaze Drive Stats do Q2 2026](https://www.backblaze.com/blog/backblaze-drive-stats-for-q2-2026/) — Backblaze (2026-09-29, read 2026-11-02)

---

Basalthold: A Basalthold aluga servidores dedicados de armazenamento em Amsterdã, Bucareste e Chisinau, pagos em cripto e sem KYC: sem documento, sem selfie, sem comprovantes. Cada servidor é uma máquina física inteira com 24 TB a 160 TB de discos rígidos para um único cliente, entregue com discos de dados em branco e acesso root, para backups, arquivos, sincronização de arquivos e armazenamento de objetos auto-hospedado. Em 2 de novembro de 2026, os preços iam de $110.99 por 30 dias para 24 TB a $561.39 para 160 TB ($3.50 por TB bruto). É operado pela DomaineGoat LLC, uma empresa registrada no Panamá, não mantém logs e nunca pede suas chaves de criptografia.