Começar hoje com um NVMe e passar para RAID mais tarde é um plano razoável para um servidor doméstico, mas o caminho seguro de migração não é «clicar em Converter JBOD em RAID». O tópico de origem de fevereiro de 2026 recomendava um processo controlado de cópia de segurança → criar uma nova matriz → restaurar → verificar, em vez de presumir que o ZimaOS conseguiria transformar o armazenamento existente num único disco no local.
O ZimaOS atual dispõe de ferramentas de migração melhoradas desde essa publicação. Em Definições > Migração de dados, é agora possível mover Imagens Docker, Dados de aplicações Docker e bases de dados de utilizadores do ZimaOS entre espaços de armazenamento. Isto facilita a migração do estado das aplicações, mas continua a não transformar um disco único já utilizado numa configuração RAID 1/5 redundante sem uma matriz de destino separada.
O utilizador de origem começou com um NVMe e um disco USB para cópias de segurança
O sistema utilizava o eMMC integrado para o ZimaOS, um SSD NVMe configurado como armazenamento JBOD e um HDD USB para cópias de segurança. O utilizador queria adicionar mais armazenamento NVMe posteriormente e mover tudo para RAID 1 ou RAID 5.
Esta é precisamente a situação em que é importante manter uma cópia de segurança independente verificada, porque alterar a topologia de armazenamento pode implicar inicializar discos novos e, eventualmente, apagar a configuração antiga de disco único.
Não presuma que um JBOD de um único disco pode ser convertido no local
A resposta da comunidade indicava que a interface de Armazenamento do ZimaOS não disponibilizava um processo suportado para converter um JBOD de um único disco em RAID. A recomendação era criar uma matriz nova a partir de discos não utilizados.
A documentação pública atual do Armazenamento já suporta a adição de discos a determinadas configurações RAID existentes, sobretudo a expansão de RAID 5, mas isso é diferente de converter, no local, um espaço de armazenamento não redundante de um único disco em RAID.
Faça uma cópia de segurança de mais do que as pastas partilhadas óbvias
Antes de alterar o armazenamento, proteja:
- ficheiros partilhados comuns;
- dados de aplicações Docker;
- pastas personalizadas montadas por bind mount;
- bases de dados de aplicações;
- definições Compose/YAML de aplicações personalizadas;
- configurações importantes que não sejam recriadas automaticamente.
Uma cópia de segurança deve ser verificada abrindo efetivamente ficheiros representativos ou realizando um teste de restauro, e não apenas confirmando que uma tarefa aparece como concluída.
Crie a nova matriz RAID antes de apagar o disco antigo
A arquitetura de migração mais segura consiste em deixar o NVMe original intocado enquanto a nova matriz é criada nos discos adicionados. Assim, o armazenamento original continua a ser outra fonte de recuperação até a nova matriz ser validada.
O ZimaOS atual gere a criação de matrizes através de Definições > Armazenamento. Utilize o processo atual de configuração do Armazenamento do ZimaOS, em vez de reproduzir procedimentos manuais antigos com mdadm.
Escolha RAID 1 ou RAID 5 com base no número de discos e no crescimento previsto
O RAID 1 é um espelho simples de dois discos. O RAID 5 requer pelo menos três discos e troca a capacidade equivalente a um disco pela tolerância à falha de um único disco.
A documentação atual do ZimaOS apresenta o RAID 5 como uma opção para bibliotecas em crescimento e indica que é possível adicionar discos ao longo do tempo. Isto pode tornar o RAID 5 interessante se o utilizador esperar expandir o conjunto após a migração inicial.
A Migração de dados atual pode mover dados geridos pelo ZimaOS
A documentação atual da IceWhale indica que Definições > Migração de dados pode mover:
- Imagens Docker;
- Dados de aplicações Docker;
- Bases de dados de utilizadores, como Galeria, Transferências, Documentos, Multimédia e Cópia de segurança.
Utilize o processo atual de Migração de dados do ZimaOS depois de o armazenamento de destino existir.
Os bind mounts personalizados continuam a exigir verificação manual
As categorias de migração integradas não garantem que todos os caminhos personalizados do anfitrião em todas as stacks Compose sejam reescritos automaticamente. Verifique as aplicações que montam pastas invulgares fora das localizações geridas normalmente pelo ZimaOS.
Após a migração, inspecione o mapeamento de volumes de cada aplicação importante e confirme que a pasta no lado do anfitrião aponta para o novo armazenamento.
Verifique a nova matriz RAID antes de reutilizar o NVMe original
Confirme que:
- a matriz RAID indica um estado saudável;
- as partilhas importantes contêm os ficheiros esperados;
- as aplicações Docker arrancam e as respetivas bases de dados estão intactas;
- as permissões funcionam a partir dos clientes habituais;
- as tarefas de cópia de segurança apontam para a origem e o destino pretendidos.
Só depois deverá apagar ou reutilizar o NVMe original.
Mantenha a cópia de segurança USB depois de passar para RAID
O RAID protege a disponibilidade após a falha de um disco membro. Não protege contra eliminação acidental, ransomware, corrupção de aplicações, roubo ou perda do servidor inteiro.
A cópia de segurança USB do plano de origem continua a ser útil depois da migração para RAID e pode passar a fazer parte de uma estratégia 3-2-1 mais abrangente.
Perguntas frequentes sobre JBOD para RAID
O ZimaOS atual consegue mover AppData entre espaços de armazenamento?
Sim. A ferramenta atual de Migração de dados inclui Dados de aplicações Docker e Imagens Docker.
Isso significa que um disco JBOD único pode ser convertido para RAID 1 no local?
Não. Mover dados e alterar a topologia de armazenamento são operações distintas.
Quando deve o disco original ser apagado?
Só depois de a nova matriz, os ficheiros, o estado das aplicações, as permissões e as cópias de segurança terem sido verificados.
