A abordagem segura consiste em tratar os números de série dos discos e os IDs persistentes, substituir um membro confirmado e, em seguida, verificar a reconstrução e a carga de trabalho original como uma sequência de etapas observáveis, não como um único comando.
Num NAS doméstico Linux que utilize ZFS, mdraid ou Btrfs, o risco prático é ter de substituir um disco do NAS sem confundir as letras de dispositivo variáveis do Linux. Registe a identidade atual e o ponto de recuperação, comece pelo identificador menos invasivo, interprete os resultados de aprovação e falha antes de alterar outra variável e pare quando o armazenamento se tornar instável ou quando a única cópia recuperável ficar exposta. O procedimento abaixo só termina quando a carga de trabalho original for executada com êxito ou quando as evidências atingirem um limite de escalada.
Criar um mapa de substituição entre número de série e baia
Guarde o estado do conjunto ou pool, a topologia dos dispositivos, a identidade SMART, a ranhura do invólucro, o número de série, o WWN e o symlink /dev/disk/by-id de cada membro. As letras de dispositivo do Linux podem mudar após um reinício ou uma ligação a quente, por isso /dev/sdX é uma observação relativa a este arranque, não a identidade duradoura utilizada no registo de substituição.
Um guia prático de servidor doméstico ZFS demonstra a substituição utilizando um caminho persistente by-id e monitorizando o resilver, em vez de confiar numa letra de dispositivo temporária. O mesmo princípio de identidade aplica-se a mdraid e Btrfs, embora os respetivos comandos de substituição sejam diferentes.
Faça corresponder duas vezes o membro que falhou no software à etiqueta física: uma vez antes de o colocar offline e novamente antes de remover o hardware. Pare se a passagem do número de série estiver em falta, se duas ranhuras apresentarem a mesma identidade da bridge ou se o pool não conseguir tolerar a passagem de outro membro para offline.
Preparar a substituição sem reduzir a redundância antecipadamente
Confirme que o novo disco tem pelo menos tantos setores utilizáveis como o anterior, que possui o formato de setores esperado e que passa verificações básicas de integridade fora do conjunto, quando possível. Registe o número de série e o caminho by-id antes da inserção. Para membros encriptados ou de arranque, preserve também o esquema de partições, as chaves e os metadados de arranque exigidos por essa plataforma.
Consulte a discussão da ZimaSpace sobre diferentes tamanhos de setor num espelho ZFS quando uma substituição apresentar um tamanho de setor lógico ou físico diferente. A capacidade indicada na caixa não é suficiente; o tamanho real, as expectativas de ashift ou alinhamento, a tabela de partições e as regras da plataforma NAS determinam se a substituição é válida.
Substitua apenas um dispositivo de cada vez. Se o disco antigo ainda for legível e a plataforma suportar anexar e depois desanexar, isso poderá preservar a redundância; caso contrário, coloque o membro confirmado offline, desligue o sistema quando o chassis não for seguro para troca a quente e identifique imediatamente o disco removido.
Iniciar e monitorizar a reconstrução específica da plataforma
Utilize a identidade do membro do pool ou conjunto apresentada pelo próprio comando de estado, associada ao novo caminho persistente by-id. Não cole um comando genérico sem verificar a topologia: a substituição de um espelho ZFS, a adição de um membro mdraid e a substituição de um dispositivo Btrfs têm máquinas de estados e semânticas de falha diferentes.
Monitorize o progresso, os erros de leitura, as reparações de checksum, as alterações SMART, a temperatura e os reinícios do controlador. Um relato independente sobre substituição salienta a importância de registar o número de série do disco avariado e aguardar a conclusão do resilver antes de substituir o membro seguinte.
Se o novo disco desaparecer, se os erros aumentarem num membro sobrevivente ou se a reconstrução reiniciar repetidamente, pare a carga não essencial e preserve os registos. Não remova outro disco, não limpe erros nem force a conclusão até compreender o componente que está a falhar e a redundância atual.
Verificar o NAS reparado antes de retirar o disco antigo
Uma barra de progresso concluída é necessária, mas não suficiente. Confirme que o pool ou conjunto está saudável, que cada membro previsto utiliza a identidade persistente esperada, que nenhuma partição permanece subdimensionada e que os mounts agendados, partilhas, contentores e cópias de segurança sobrevivem a dois reinícios.
Execute a verificação de integridade ou o scrub da plataforma após a reconstrução, de acordo com o procedimento seguro correspondente, restaure depois um ficheiro representativo e reproduza a carga de trabalho que revelou a falha. Verifique se os contadores de erros permanecem estáveis durante leituras e escritas prolongadas.
Mantenha o disco antigo offline e identificado até o novo membro ter passado uma carga de trabalho normal e um ciclo de cópia de segurança. A recuperação está concluída quando a topologia, as verificações de dados, a integridade dos dispositivos e os caminhos das aplicações forem aprovados; escale o problema se a identidade continuar ambígua ou se algum membro sobrevivente desenvolver novos erros durante a reconstrução.
Suporte e Dicas
Mais para Ler

Guia de migração do Borg Backup para mover um repositório para um novo armazenamento
Mova um repositório Borg como um objeto consistente: pare os processos de escrita, preserve as chaves e a identidade, verifique as reposições e, em...

Fluxo de manutenção do repositório Restic: verificar, podar, compactar e testar o restauro
O Restic não tem um comando separado de compactação: o prune faz a reempacotagem. Proteja os bloqueios e o espaço livre, volte a verificar...

Guia de recuperação de NAS do Time Machine para históricos de cópias de segurança danificados ou abandonados
Mantenha o pacote antigo. Separe o acesso ao NAS, a identidade do destino, os danos na imagem e o histórico abandonado antes de escolher...

