Lista de verificação para recuperação de metadados Btrfs num servidor doméstico quase cheio

A abordagem segura consiste em tratar a estabilização das gravações, a recuperação de espaço de trabalho, a execução apenas de um balanceamento filtrado e a verificação dos dados antes do serviço normal como uma sequência de etapas observáveis, não como um único comando.

Num sistema de ficheiros Btrfs de um servidor doméstico quase cheio, o risco prático é o Btrfs comunicar ENOSPC ou ficar só de leitura quando o espaço de metadados se esgota. Registe a identidade atual e o ponto de recuperação, comece pelo diagnóstico menos invasivo, interprete os resultados positivos e negativos 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 sucesso ou quando as evidências atingirem um limite de escalada.

Estabilize o sistema de ficheiros antes de tentar repará-lo

Pare contentores, transferências, instantâneos e tarefas com muitos registos que escrevam no sistema de ficheiros afetado. Guarde os erros do kernel e o resultado de btrfs device stats noutro local. Se o sistema de ficheiros tiver sido remontado como só de leitura ou comunicar erros de checksum, de transação principal ou de E/S, mantenha-o só de leitura até ter uma cópia recuperável.

Não comece com btrfs check --repair, um balanceamento completo, desfragmentação ou eliminação em massa. A questão imediata é saber se o estado válido do sistema de ficheiros não dispõe de espaço de trabalho para alocação ou se os erros de armazenamento estão a danificar os metadados; começar pela reparação pode dificultar essa distinção e consumir o espaço restante.

A etapa de segurança é aprovada quando os serviços com muitas gravações estão parados, os dados importantes têm outra cópia e sabe qual é o dispositivo de blocos e o ponto de montagem que está a examinar. Passe para a criação de uma imagem de recuperação se o dispositivo for reiniciado, desaparecer ou acumular erros de leitura.

Leia a alocação em vez do número geral de espaço livre

Execute btrfs filesystem usage -T /mount, btrfs filesystem df /mount, btrfs device usage /mount e inspecione as mensagens recentes do kernel. Compare os metadados alocados e utilizados e o espaço não alocado disponível em cada dispositivo; o df normal, por si só, não mostra se o Btrfs consegue alocar outro bloco de metadados.

Um balanceamento direcionado precisa de espaço de trabalho totalmente não utilizado. Um guia detalhado para o balanceamento direcionado do Btrfs explica que um balanceamento sem filtros reescreve todos os grupos de blocos elegíveis e que o objetivo é manter espaço não alocado ao nível do dispositivo, não simplesmente eliminar um ficheiro grande e presumir que os metadados podem crescer.

Se os metadados estiverem elevados mas ainda houver espaço não alocado, um pequeno balanceamento filtrado poderá recuperar blocos vazios ou pouco utilizados. Se nenhum dispositivo tiver espaço de trabalho, remova primeiro dados ou instantâneos que possam ser eliminados em segurança, em pequenos lotes, ou adicione um dispositivo temporário adequado ao perfil do sistema de ficheiros; não inicie uma relocação que não possa terminar.

Recupere espaço de trabalho com a ação menos invasiva

Comece por eliminar ficheiros descartáveis que não sejam mantidos por instantâneos e, depois, elimine apenas os instantâneos confirmadamente desnecessários. Sincronize e volte a verificar a utilização após cada pequena alteração. Se um balanceamento for justificado, comece com btrfs balance start -dusage=0 -musage=0 /mount ou outro filtro restrito escolhido com base na alocação observada, não com um balanceamento completo.

A descrição do manual do Linux sobre o comportamento do balanceamento filtrado indica que os filtros limitam a relocação e que pode ocorrer ENOSPC quando o próprio balanceamento não dispõe de espaço de trabalho. Observe btrfs balance status e os registos do kernel. Se a relocação aumentar os erros, ficar bloqueada devido a falhas do dispositivo ou consumir a última margem de segurança, cancele-a e volte à recuperação só de leitura.

Não acumule filtros e eliminações sem fazer medições entre cada passo. O ramo de recuperação é bem-sucedido quando os metadados têm margem, existe espaço não alocado nos dispositivos necessários e uma pequena gravação é concluída sem um novo ENOSPC ou uma mudança forçada para só de leitura.

Featured

ZimaCube 2 NAS Pessoal Cloud para Casa

ZimaCube2

$799.00 - $2,499.00

Buy Now

Verifique os dados e evite uma recaída imediata

Reinicie apenas um serviço de baixo risco e reproduza a carga de trabalho que originalmente encheu os metadados, como a criação de instantâneos ou muitas alterações em ficheiros pequenos. Volte a verificar a utilização e os registos do kernel após a carga de trabalho e depois de reiniciar. Uma montagem que funciona uma vez mas volta a ficar só de leitura durante a atividade normal não está recuperada.

Utilize o método da ZimaSpace para distinguir se são os instantâneos ou ficheiros ativos que utilizam o espaço do NAS antes de alterar a retenção. Os dados mantidos por instantâneos podem fazer com que a eliminação pareça ineficaz, enquanto as alterações contínuas em muitos ficheiros pequenos podem manter elevada a pressão sobre os metadados; a política correta depende do estado que as medições comprovarem.

Retome o serviço normal apenas depois de o sistema de ficheiros permanecer gravável, as estatísticas do dispositivo deixarem de aumentar, um ficheiro representativo ser restaurado ou ter os hashes verificados corretamente e a monitorização gerar alertas antes de a mesma margem desaparecer. Encaminhe erros estruturais persistentes para um especialista em recuperação Btrfs e trabalhe a partir de um clone, em vez de repetir comandos de reparação na única cópia.