Se o ZimaOS for reinstalado e um RAID 1 existente aparecer como discos não utilizados, não clique imediatamente em Create RAID. Recriar ou formatar a matriz pode destruir os dados que ainda estão presentes nos discos membros.
O primeiro caminho de recuperação deve ser o método oficial atual do ZimaOS: restaurar o ficheiro guardado local-storage.db ficheiro da instalação anterior do sistema. O tutorial da comunidade que está na origem desta página documenta uma alternativa de recurso mais invasiva para o caso mais difícil em que essa base de dados não tenha sido salvaguardada. Essa alternativa foi testada no ZimaOS 1.6.1, mas inclui operações RAID destrutivas e só deve ser considerada depois de os dados de origem terem sido copiados e verificados de forma independente.
Primeira opção: restaurar local-storage.db
O ZimaOS guarda as informações de configuração do armazenamento em:
/ZimaOS-HD/.casaos/db/local-storage.db
O guia oficial de recuperação atual recomenda descarregar este ficheiro antes de reinstalar o sistema e, depois, colocá-lo novamente no mesmo diretório após a nova instalação do ZimaOS e o reinício.
Recuperação oficial do RAID do ZimaOS após a reinstalação
Se ainda tiver acesso ao disco do sistema antigo, tente recuperar esta base de dados antes de tocar nos discos membros do RAID.
Porque é que a matriz de dados pode ainda estar intacta
O ZimaOS utiliza RAID por software do Linux. Os discos membros podem conservar os metadados RAID mesmo quando a nova instalação do ZimaOS já não tem a base de dados de armazenamento antiga. É por isso que os discos podem aparecer fisicamente presentes, enquanto a interface já não reconhece o conjunto de armazenamento original.
O ZimaOS 1.6 também introduziu melhorias na recuperação dos metadados RAID e no comportamento de reidentificação, pelo que não se deve presumir que um problema originalmente observado num sistema ocorra exatamente da mesma forma em todas as versões mais recentes.
Não crie um novo RAID antes de decidir como proceder à recuperação
Se os discos contiverem dados de que necessita, evite:
- formatar qualquer um dos discos membros;
- criar um novo RAID nos mesmos discos;
- executar
wipefsoumdadm --zero-superblockprematuramente; - adivinhar qual
/dev/sdXqual é o dispositivo.
Antes de qualquer trabalho de recuperação, identifique os discos pelo modelo, número de série e capacidade, em vez de depender apenas das letras dos dispositivos.
Verificar os metadados RAID em modo apenas de leitura
O autor da comunidade começou por utilizar uma inspeção apenas de leitura para confirmar que ambos os membros do RAID 1 ainda pertenciam à mesma matriz.
lsblk -o NAME,SIZE,TYPE,MOUNTPOINT,FSTYPE,MODEL,SERIAL
mdadm --examine /dev/sda
mdadm --examine /dev/sdb
Para um RAID 1 saudável, ambos os membros devem indicar o mesmo UUID da matriz e metadados RAID compatíveis. Se um membro estiver em falta, degradado ou indicar metadados diferentes, pare e peça assistência para recuperação, em vez de seguir uma receita genérica de reconstrução.
Monte o array antigo em modo só de leitura
Para uma recuperação avançada, montar em modo só de leitura reduz a probabilidade de modificar a origem enquanto verifica se os ficheiros estão acessíveis:
mdadm --assemble --readonly /dev/md127 /dev/sda /dev/sdb
mkdir -p /DATA/oldraid
mount -o ro /dev/md127 /DATA/oldraid
Em seguida, inspecione o sistema de ficheiros:
df -h /DATA/oldraid
ls -la /DATA/oldraid
du -sh /DATA/oldraid/*
Os nomes dos dispositivos acima são apenas exemplos. Nunca os cole sem alterações, a menos que tenha confirmado que correspondem ao seu hardware.
Crie uma cópia completa de transferência antes de qualquer passo destrutivo
O fluxo de trabalho de origem utilizou uma unidade externa ext4 com capacidade suficiente para armazenar todos os dados utilizados do RAID. Para dados de aplicações Linux, o ext4 é útil porque consegue preservar a propriedade, as permissões, as ligações, as ACL e os atributos estendidos normais.
Uma cópia de arquivo típica é:
rsync -aHAX --info=progress2 /DATA/oldraid/ /DATA/offload/
Execute a cópia em tmux ou outro terminal persistente, se uma desligação SSH interrompesse a operação.
Verifique a cópia de segurança antes de continuar
Não dependa apenas da linha de saída do rsync. Compare o número de ficheiros e verifique o tamanho dos diretórios principais:
find /DATA/oldraid -xdev -type f | wc -l
find /DATA/offload -xdev -type f | wc -l
du -sh /DATA/oldraid/*
du -sh /DATA/offload/*
Para dados insubstituíveis, é preferível ter uma segunda cópia de segurança independente. O RAID, por si só, não é uma cópia de segurança.
Último recurso: transferir os dados, remover os metadados RAID antigos e recriar na interface
O autor original da comunidade pretendia que o array recuperado voltasse a ser gerido normalmente pela interface do ZimaOS. O seu método de último recurso foi:
- verifique o array antigo em modo só de leitura;
- copie todos os dados para uma unidade externa;
- verifique a cópia;
- pare o array md antigo;
- remova os metadados RAID antigos;
- crie um RAID 1 novo utilizando a interface de Armazenamento do ZimaOS;
- restaure os ficheiros copiados;
- verifique os dados restaurados.
Este procedimento destrói intencionalmente os metadados RAID antigos. Depois de executar esse passo, a cópia de transferência passa a ser a sua fonte de recuperação. Não utilize esta abordagem se a cópia estiver incompleta ou se não tiver a certeza da identidade dos dispositivos.
O comando irreversível no fluxo de trabalho de origem
O procedimento utilizado pela comunidade:
mdadm --zero-superblock /dev/sda /dev/sdb
Este não é um comando de resolução de problemas. Remove os metadados RAID dos discos especificados. Um caminho de dispositivo incorreto pode causar uma perda de dados significativa.
Por esse motivo, esta página não recomenda executá-lo apenas porque a interface do ZimaOS não reconhece um RAID. Restaure local-storage.dbverifique o comportamento atual de recuperação do ZimaOS e contacte primeiro o suporte quando o array contiver dados importantes.
Porquê recriar o array através da interface do ZimaOS?
O objetivo do fluxo de trabalho de origem era terminar com um conjunto de armazenamento gerido normalmente pelo ZimaOS, em vez de um dispositivo md montado manualmente de forma permanente fora da interface de armazenamento.
Depois de os dados antigos terem sido descarregados em segurança e os discos terem sido intencionalmente reinicializados, utilize a interface de Armazenamento atual para criar RAID 1 e deixe concluir a sincronização inicial.
Restaure os ficheiros no novo conjunto
Depois de o novo conjunto ser criado e montado, restaure os dados a partir do disco de descarga:
rsync -aHAX --info=progress2 /DATA/offload/ /media/Storage/
Substitua /media/Storage com o caminho de destino efetivo apresentado pelo seu sistema.
Verifique o conjunto de armazenamento restaurado
find /DATA/offload -xdev -type f | wc -l
find /media/Storage -xdev -type f | wc -l
du -sh /media/Storage/*
cat /proc/mdstat
Mantenha a unidade de descarga de dados intacta até a sincronização do RAID estar concluída e ter verificado o acesso normal através da interface Ficheiros do ZimaOS e das aplicações que dependem dos dados.
Faça uma cópia de segurança de local-storage.db antes da próxima reinstalação
A recuperação mais fácil é aquela para a qual se preparou antecipadamente. Mantenha uma cópia atualizada de:
/ZimaOS-HD/.casaos/db/local-storage.db
fora da unidade do sistema. A documentação oficial fornece agora um procedimento direto de restauração utilizando este ficheiro.
Que caminho de recuperação deve escolher?
| Situação | Ação preferida |
|---|---|
| Fez uma cópia de segurança de local-storage.db | Utilize o método oficial de restauração da base de dados |
| O disco do sistema antigo ainda pode ser lido | Recupere local-storage.db antes de modificar os discos RAID |
| Sem cópia de segurança da base de dados; os metadados RAID parecem estar íntegros | Pause as ações destrutivas e procure aconselhamento de suporte ou recuperação |
| Tem uma cópia completa e verificada dos dados descarregados e pretende intencionalmente uma matriz limpa gerida pela interface | Considere o método comunitário de descarregar os dados, recriar e restaurar |
| Os membros do RAID apresentam metadados incompatíveis ou degradados | Pare e utilize orientação especializada de recuperação |
Perguntas frequentes sobre a recuperação de RAID no ZimaOS
A reinstalação do ZimaOS apaga automaticamente os dados do RAID?
Não. Reinstalar o disco do sistema é diferente de formatar os discos membros do RAID. A configuração de armazenamento pode perder-se, enquanto os metadados RAID e os dados permanecem nos discos membros.
Devo clicar em Criar RAID se os discos antigos aparecerem como não utilizados?
Ainda não, até confirmar que não há dados existentes que precisem de ser recuperados. Criar um novo RAID pode ser destrutivo.
Qual é a recuperação mais segura se eu tiver feito uma cópia de segurança de local-storage.db?
Utilize o procedimento oficial atual do ZimaOS para restaurar essa base de dados e reinicie.
É seguro pôr a superbloco do mdadm a zero?
É intencionalmente destrutivo para os metadados RAID. Utilize-o apenas como parte de um plano de recuperação verificado, depois de os dados terem sido copiados em segurança para outro local.
