Solução da comunidade

Aumentar o RAID 1 do ZimaOS após substituir ambos os discos por unidades de maior capacidade: procedimento comunitário com mdadm + Btrfs

A November 2025-March 2026 discussion where ZimaOS could rebuild RAID1 onto larger replacement disks but did not automatically expose the extra capacity through the UI. One user on ZimaOS+ 1.5.4 replaced both 500 GB disks with 1 TB disks one at a time, used the GUI recovery each time, then successfully ran mdadm --grow followed by a Btrfs filesystem resize.

A fonte prova que substituir ambos os membros do RAID 1 por discos maiores **não aumenta automaticamente o sistema de ficheiros utilizável**. Um utilizador substituiu com êxito dois discos de 500 GB por discos de 1 TB, um de cada vez, e deixou o ZimaOS reconstruir o array após cada substituição. Nessa altura, ambos os membros físicos tinham 1 TB, mas o dispositivo RAID e o sistema de ficheiros Btrfs continuavam a expor apenas a antiga capacidade de 500 GB.

No ZimaOS+ 1.5.4, esse utilizador concluiu então a expansão através de SSH com mdadm --grow /dev/md0 --size=max, aguardaram pela recuperação/re sincronização resultante e, por fim, executaram btrfs filesystem resize max no sistema de ficheiros montado. Relataram que a interface gráfica e df e apresentou depois a maior capacidade. Esta é uma confirmação forte da comunidade, mas continua a ser um fluxo de trabalho manual através da CLI — não um procedimento atual da interface gráfica do IceWhale.

Faça uma cópia de segurança antes de iniciar uma expansão da capacidade

O RAID 1 protege contra a falha de um membro; não protege contra erros do operador, danos nos metadados do array, erros no sistema de ficheiros nem problemas com um segundo disco durante a reconstrução.

Substitua apenas um membro do RAID de cada vez

  1. desligue o sistema;
  2. substitua o primeiro disco antigo pelo disco maior;
  3. arranque;
  4. utilize a Recuperação do ZimaOS para reconstruir;
  5. aguarde até que a recuperação esteja completamente concluída.

Repita para o segundo membro

Só depois de concluída a primeira reconstrução é que o utilizador desligou o sistema e substituiu o segundo disco; em seguida, executou novamente a recuperação através da interface gráfica e aguardou a conclusão total.

Nesta fase, o array estava saudável em dois dispositivos físicos maiores, mas continuava dimensionado para o tamanho histórico dos membros.

O utilizador da comunidade aumentou então o array mdadm

O comando da fonte foi:

sudo mdadm --grow /dev/md0 --size=max

Verificaram a nova configuração do array com mdadm --detail e aguardou pela conclusão do novo estado de recuperação/re sincronização.

Nunca assuma que o seu array é /dev/md0; identifique primeiro o array real.

Depois, foi necessário expandir o sistema de ficheiros Btrfs

A fonte terminou com:

sudo btrfs filesystem resize max /your/mounted/filesystem

Utilize o caminho Btrfs realmente montado, em vez de copiar literalmente o marcador de posição.

Porque foram necessários dois passos de redimensionamento

  • o dispositivo RAID md do Linux;
  • o sistema de ficheiros Btrfs que se encontra sobre ele.

Ambos têm de expor a maior capacidade antes de os utilizadores verem a capacidade adicional.

Trate isto como um procedimento comunitário específico da versão

O utilizador da fonte executou explicitamente o ZimaOS+ 1.5.4. O ZimaOS atual é mais recente e o comportamento da gestão do armazenamento pode mudar. Antes de executar processos manuais mdadm --grow no armazenamento de produção, verifique se a interface continua sem apresentar uma opção de expansão suportada e considere contactar o suporte da IceWhale para obter o procedimento atual.

Verifique o Estado do RAID Antes de Cada Substituição Física

Antes de substituir o primeiro disco — e novamente antes de substituir o segundo — confirme que a matriz está íntegra e totalmente sincronizada. Iniciar a segunda substituição enquanto a reconstrução da primeira ainda não terminou elimina a redundância de que depende durante a atualização.

Registe os números de série dos membros para garantir que o disco físico removido corresponde ao membro lógico apresentado pelo ZimaOS.

Os Discos de Substituição Precisam de Capacidade Real Suficiente

Discos com capacidades nominais iguais podem diferir ligeiramente no número de setores utilizáveis. A expansão mais segura utiliza discos de substituição claramente maiores do que os membros antigos e, pelo menos, do mesmo tamanho entre si.

Se o segundo disco de “1 TB” for ligeiramente mais pequeno do que o primeiro, o passo de expansão/reconstrução do md poderá não funcionar como esperado.

Conte com Mais do que um Ciclo de Resincronização

O processo da fonte reconstruiu a matriz após a primeira substituição física, voltou a reconstruí-la após a segunda e, em seguida, entrou noutro estado de recuperação/re sincronização depois de mdadm --grow. Isto significa que uma atualização da capacidade pode demorar substancialmente mais do que a simples substituição de dois discos.

Mantenha o NAS ligado a uma fonte de alimentação fiável e evite reinícios desnecessários durante cada fase de recuperação.

Verifique o Dispositivo de Bloco e o Sistema de Ficheiros no Final

Após o redimensionamento final do Btrfs, verifique o resultado em mais de uma camada:

  • mdadm --detail — geometria do RAID md;
  • df -h ou ferramentas do sistema de ficheiros Btrfs — capacidade utilizável do sistema de ficheiros;
  • Interface de armazenamento do ZimaOS — tamanho esperado do conjunto e estado íntegro.

Se uma das camadas continuar a apresentar o tamanho antigo, pare e investigue, em vez de repetir cegamente os comandos de expansão.

Perguntas frequentes sobre a expansão do RAID 1

Um disco maior pode aumentar imediatamente a capacidade do RAID1?

Não. O espelho continua limitado pelo membro mais pequeno e pela geometria histórica da matriz.

A substituição de ambos os discos mais pequenos aumentou automaticamente a capacidade na fonte?

Não. O utilizador ainda teve de expandir a matriz md e, em seguida, redimensionar o Btrfs.

O processo manual de expansão foi confirmado pela fonte?

Sim, por parte de um utilizador do ZimaOS+ 1.5.4. Não foi publicado como um procedimento oficial da IceWhale.