Quanto tempo leva a reconstrução de um drive de 22 TB

O número mais caro de um disco de 22 TB não aparece em lugar nenhum do próprio disco. Capacidade está na etiqueta, interface está na ficha técnica, classe de workload está na nota de rodapé; a grandeza que decide se um array sobrevive à primeira semana ruim é um intervalo de tempo — e ele pertence ao sistema montado em volta do disco, não ao disco.

Um modelo como o WD Ultrastar WUH722422ALE6L4 identifica um disco SATA de 22 TB e nada além disso. Quanto tempo o rebuild vai levar será definido pela geometria de paridade, pela política de rebuild do controlador, pelos slots de reserva e pelo tráfego dos usuários no pior horário possível. São decisões de compra, não de incidente.

O relógio, não o terabyte, é a variável de decisão

O tempo em que o array fica sem margem deveria decidir a compra, e é justamente a grandeza que quase ninguém anota. Redundância é um seguro com franquia paga em horas: a falha de um membro não apaga dados, ela inicia uma contagem em que não sobra folga para uma segunda falha, para um erro de leitura incorrigível ou para uma queda de energia na hora errada.

Todos os outros números da proposta comercial medem capacidade ou velocidade. Este mede quanto tempo o serviço passa a uma falha de distância de uma parada — e, ao contrário de quase todo indicador de risco, pode ser estimado antes, com uma conta que você consegue mostrar para outra pessoa. As perguntas de capacidade e de planejamento de rebuild que valem antes do pedido são, quase todas, variações dessa variável.

Quatro fatores mandam no relógio do rebuild

Nenhum dos quatro aparece como número pronto na ficha técnica: o primeiro depende da capacidade e da geometria, os outros do array e da operação.

O primeiro é o tamanho da tarefa. Em RAID com paridade, perder um membro significa ler todos os sobreviventes por inteiro e escrever a largura de um membro; um espelho copia apenas o que realmente guarda. Um array largo, de discos grandes, movimenta mais bytes no rebuild do que um array estreito de discos pequenos — mesmo com a mesma capacidade útil.

O segundo é a banda que o array consegue ceder. Controladoras e firmware costumam limitar a taxa de rebuild para proteger o desempenho de produção, e esse limite é política, não característica do disco. O que vale é a taxa no horário de pico, não a da madrugada.

O terceiro é o membro mais lento entre os sobreviventes. O rebuild não avança mais rápido que o disco mais fraco em participação; um membro com setores no limite pode travar a transferência várias vezes, e a saúde média do array não ajuda quando uma única região ruim dita o ritmo.

O quarto é o tratamento de erros. Política de retentativa, timeouts e uma verificação depois do rebuild são onde a aritmética limpa vira uma faixa de valores. Cópia linear é o melhor caso; recuperação profunda e verificação são o caso normal em discos que giram há anos.

A conta da sua janela de exposição

A janela de exposição se estima com uma divisão e três ajustes, usando medições do seu ambiente — nunca uma duração publicada por alguém.

1. Meça a taxa que o array realmente entrega a um rebuild enquanto atende o tráfego normal: leia os contadores da plataforma durante um scrub programado ou cronometre a retirada proposital de um membro em um array de teste com a mesma geometria.
2. Divida os bytes que precisam ser reconstruídos por essa taxa medida, contando leitura e escrita separadamente quando a geometria as trata de forma diferente.
3. Ajuste para a pior hora: use a taxa de pico e some a verificação da plataforma, se houver uma depois do rebuild.
4. Ajuste pelo segundo relógio: o tempo entre a falha e o momento em que o disco de reposição está no lugar. Em muitos ambientes, essa lacuna pesa mais na exposição do que a própria cópia.
5. Confira o resultado com um ensaio. Um único array de teste, com um membro retirado de propósito sob carga representativa, vale mais do que qualquer estimativa.

O que sai disso é uma duração defensável, não uma promessa. Multiplique pelo número de arrays que você opera e terá as horas de array vulnerável que cada incidente cria; compare com o que a operação tolera e a decisão de compra praticamente se resolve sozinha. Por que um único disco grande muda o perfil de risco do array inteiro está nesta nota sobre risco de disco único.

O preço real de cada mitigação

Nenhuma mitigação é gratuita: cada uma encurta a janela ou tira a gravidade dela, e todas cobram em capacidade, em slots, em energia ou em disciplina de operação.

Redundância mais larga — RAID 6 ou um layout com erasure coding — elimina o penhasco em que a segunda falha encerra a história. O custo é uma largura de membro em capacidade útil, parte da banda de escrita e mais processamento durante o rebuild. Um disco de reserva (hot spare) encurta a lacuna antes do rebuild, não o rebuild; ele cobra um slot, um disco que não faz mais nada e a energia de mantê-lo girando. Discos menores em maior número reduzem cada tarefa e multiplicam a quantidade de falhas que o array vai ver — uma troca real, não um ganho de graça. Teste de estresse antes da produção não acelera rebuild algum, mas remove discos fracos da população antes que participem de um; o guia de teste de estresse por risco mostra quanto tempo essa rodada deve durar.

Backup e restore são o plano B honesto, e o mais mal precificado de todos. Quando o restore leva mais tempo que o rebuild, o backup não é a mitigação que parece; quando nunca foi cronometrado, é uma esperança com data marcada.

Três regras valem para qualquer combinação. Quando a janela medida passa do que a operação tolera sem proteção, o que muda é a geometria ou o tamanho do disco no pedido, não o procedimento de incidente. Quando o array precisa manter desempenho cheio durante o rebuild, a conta usa a taxa do horário de pico. E quando o gabinete tem um único slot livre, um disco de reserva ali rende mais do que um modelo mais rápido do mesmo tamanho.

Por que essa conta é feita antes da compra

A janela é fixada na compra e apenas descoberta na falha. Tamanho e quantidade de discos, geometria e slots livres ficam presos ao pedido, e a escolha da plataforma define quais políticas de rebuild existem. Depois da primeira falha, restam apenas saídas de emergência: comprar capacidade sob pressão, operar degradado ou restaurar backup por um relógio que ninguém testou.

É por isso que a divisão vem antes do pedido. Planejar a falha antes que ela aconteça custa menos do que responder a ela em um canal de incidente, e a aritmética é a parte que pode ser feita com calma. Quem quer fazer essa divisão às três da manhã com o array degradado? As demais notas de compras da biblioteca de insights seguem o mesmo princípio: decisão que se consegue calcular na hora do pedido não deveria ficar para a pior hora.

Duas decisões que vão no pedido de compra

O orçamento de falhas e o caminho de recuperação são decisões de compra, porque depois do primeiro defeito só resta reagir.

O orçamento de falhas define quantas perdas simultâneas de membros o array precisa suportar e qual desempenho o serviço garante com um disco a menos. Essa frase escolhe a geometria, o tamanho dos discos e se existe reserva dentro do gabinete.

O caminho de recuperação define o que fica na prateleira, quem pode instalar, qual restore foi realmente cronometrado e o que o fornecedor da plataforma confirma por escrito sobre o comportamento do rebuild: limite de taxa sob carga, tratamento de erros e se há verificação no fim. Ficha técnica não responde isso, e resposta verbal não sobrevive a uma semana ruim. Peça a confirmação junto com o pedido, ao lado da classe de workload com que os discos vão operar.