Volume NAS Somente Leitura Após Desligamento Inseguro: Primeiras Verificações

Um volume NAS que se torna só de leitura após um desligamento inseguro está geralmente a proteger metadados danificados ou a reagir a erros de I/O de armazenamento — não simplesmente a mudar permissões.

Se as suas partilhas ainda abrirem mas uploads, bases de dados de aplicações ou scans de media falharem, resista à tentação de forçar uma remontagem de leitura-escrita. O caminho mais seguro é preservar os dados legíveis, identificar se o bloqueio ocorre na camada da partilha, sistema de ficheiros, pool ou disco, e depois usar o método de reparação adequado para essa pilha de armazenamento.

Primeiro, Congele as Alterações e Proteja os Dados Legíveis

Trate o modo só de leitura como um aviso, não como a falha em si. Pause trabalhos de sincronização, contentores, indexação de media, downloads e rotação de backups para que tentativas repetidas não ocultem os erros originais nem sobrecarreguem um disco fraco.

Se ficheiros importantes continuarem legíveis, copie os dados mais insubstituíveis para um armazenamento saudável separado antes de tentar reparar. Num caso reportado, um sistema de ficheiros só de leitura após falha de energia voltou após tentativas temporárias de reparação, mostrando porque a recorrência deve ser tratada como não resolvida.

1. Pausa os serviços e as escritas dos clientes.
2. Copie ficheiros críticos legíveis para outro local.
3. Guarde os ecrãs de estado do armazenamento e os registos de eventos.
4. Registe a disposição do pool e o tipo de sistema de ficheiros.
5. Comece as verificações sem alterar o array.

Esta ordem preserva tanto os dados como as evidências. Um reinício, montagem forçada, reparação ou remontagem pode alterar o estado que precisa de diagnosticar, por isso não faça um destes como primeiro experimento.

O que realmente se tornou só de leitura?

Um upload falhado não prova que todo o volume é só de leitura. Uma partilha, conjunto de dados, diretório de aplicação, sistema de ficheiros, pool de armazenamento ou dispositivo físico pode bloquear escritas, e cada camada precisa de uma correção diferente.

Compare a falha no painel do NAS e em mais do que um cliente. O padrão abaixo separa um problema de acesso de um evento de proteção de armazenamento antes de tocar nos discos ou executar uma ferramenta de reparação do sistema de ficheiros.

Se o próprio NAS conseguir criar um ficheiro de teste mas os clientes não, mantenha-se acima da camada do sistema de ficheiros. Se as escritas locais também falharem e o painel indicar um volume só de leitura, continue com os registos e a saúde do pool.

Leia os Registos Antes que Desapareçam

A primeira evidência útil é o evento imediatamente antes do volume se tornar só de leitura. Reveja o registo de eventos do sistema, histórico do gestor de armazenamento e mensagens do kernel para a arranque afetado e o anterior.

Alguns sistemas de ficheiros param de escrever após detetar um erro. No caso de um sistema ter passado subitamente para modo só de leitura, os intervenientes alertaram que novas entradas no diário podem não chegar ao disco. Capture as mensagens atuais do kernel antes de reiniciar sempre que possível.

Guarde entradas que contenham erros do sistema de ficheiros, abortos de diário, falhas de soma de verificação, reinicializações de dispositivos, tempos limite ou erros de I/O de leitura/escrita. Registe o identificador do dispositivo e o carimbo temporal; falhas repetidas no mesmo membro são mais importantes do que um aviso genérico de "desligamento não limpo".

Verifique o Pool ou RAID Antes do Sistema de Ficheiros

Um sistema de ficheiros assenta sobre um pool, conjunto RAID, volume lógico, controlador e unidades. Se essa camada inferior estiver incompleta ou instável, a reparação do sistema de ficheiros pode ler dados inconsistentes ou adicionar carga no pior momento.

Para RAID de software Linux, um array RAID 5 ou RAID 6 sujo e degradado pode apresentar risco de corrupção indetetável; a regra do array sujo e degradado explica porque a inicialização automática pode ser recusada. Não force a montagem apenas para limpar um aviso do painel.

Verifique se todos os membros estão presentes, se uma reconstrução ou resilver está ativa e se os contadores de leitura, escrita ou soma de verificação estão a aumentar. Registe a ordem dos membros e o estado exato sem forçar a montagem, substituir um disco ou iniciar uma verificação. Estabilize o pool antes de verificar o sistema de ficheiros acima dele.

Verifique a Saúde da Unidade, Cablagem e Alimentação

Revise todos os dispositivos HDD, SSD e NVMe, incluindo dispositivos de cache e metadados. Utilize a página de saúde do NAS para inspecionar a saúde SMART ou NVMe, auto-testes recentes, temperaturas, erros de mídia e se algum dispositivo desapareceu após o desligamento.

Não confie apenas num selo verde de "saudável". Correlacione os resultados de saúde com erros de I/O do kernel, reinicializações de dispositivos e o momento em que o volume mudou de estado. Um resumo aprovado não explica uma falha registada noutro ponto do caminho de armazenamento.

Desligue o NAS corretamente antes de recolocar uma ligação de dados ou energia acessível, e altere apenas uma variável de cada vez. Se vários discos desaparecerem juntos ou erros surgirem após uma porta em vez de um disco, pare de culpar discos individuais e investigue o caminho partilhado.

Combine a Ferramenta de Reparação com o Sistema de Ficheiros

Ext4 e XFS: Reparar Offline com Ferramentas Nativas

O Ext4 usa e2fsck, enquanto o XFS usa xfs_repair; nenhum deve ser usado num volume montado ou num caminho de dispositivo incerto. Se o NAS não conseguir desmontar o volume com segurança, use o seu fluxo de manutenção ou um ambiente de recuperação suportado.

Um guia prático de resolução de problemas de sistema de ficheiros separa as verificações da família ext da reparação XFS e coloca as verificações num sistema de ficheiros desmontado. Preserve uma cópia de segurança, identifique o dispositivo exato e comece com o modo nativo não modificador do sistema de ficheiros quando disponível.

Btrfs: Prefira Verificações Só de Leitura e Orientação Especializada

O Btrfs separa a verificação, a checagem estrutural e a reparação. Uma verificação valida somas de verificação e pode usar uma réplica boa, enquanto a checagem estrutural examina objetos do sistema de ficheiros; nenhuma deve ser tratada como um interruptor genérico que torna um volume danificado gravável.

O aviso oficial do btrfs check recomenda desmontar primeiro e alerta explicitamente contra o uso de --repair sem orientação experiente. Comece com a recuperação de dados legíveis e uma verificação não modificadora, depois siga o caminho de recuperação documentado pelo fornecedor do NAS.

ZFS: Estabilizar a Pool Antes de Verificar

O ZFS não usa um fluxo de trabalho tradicional fsck. Leia primeiro o estado da pool, preserve ficheiros críticos e resolva dispositivos em falta ou com falhas antes de adicionar a carga contínua de I/O de uma verificação.

Uma verificação da pool OpenZFS valida somas de verificação dos blocos e pode reparar a partir de réplicas boas, mas é intensiva em I/O e não pode criar uma cópia válida quando a redundância está esgotada. Inicie-a apenas depois da pool estar estável e os dados críticos protegidos.

Quando Restaurar as Escritas — e Quando Parar

Restaurar o serviço de leitura e escrita apenas depois de a pool estar estável, a verificação offline relevante ou a recuperação nativa estar concluída, e os registos recentes não mostrarem erros recorrentes de I/O ou metadados. Depois, iniciar um serviço de baixo risco e testar um ficheiro descartável antes de retomar as cargas de trabalho normais.

Se uma remontagem forçada falhar ou o volume voltar imediatamente a apenas leitura, aceite esse resultado como nova evidência. Repetir o mesmo comando não remove a causa; apenas aumenta as escritas, o calor e a pressão de recuperação.

Pare a reparação DIY quando vários membros do pool estiverem em falta, os contadores de erro continuarem a subir, um disco fizer cliques ou se desligar repetidamente, os checksums forem irrecuperáveis ou a única cópia legível for crítica. Preserve os registos e a ordem dos dispositivos, mantenha o sistema desligado se o hardware estiver instável e contacte suporte qualificado de recuperação de armazenamento ou da plataforma.

Prevenir a Próxima Paragem Não Segura

Use um UPS que possa sinalizar ao NAS para desligar automaticamente, não apenas uma bateria com portas de comunicação não utilizadas. Esta lista de verificação para falhas de energia no NAS cobre comunicação de desligamento, verificações pós-falha e porque a energia estável é importante durante a recuperação.

Mantenha cópias de recuperação fora do pool ativo. O RAID pode preservar a disponibilidade após algumas falhas de disco, mas segue a corrupção em tempo real e não fornece uma versão limpa anterior; a distinção entre RAID e recuperação por backup é mais importante quando uma reparação não tem sucesso.

Finalmente, ative alertas para disco, pool e UPS; agende verificações ou escrutínios adequados ao sistema de ficheiros; e teste uma pequena restauração periodicamente. Um arranque bem-sucedido é útil, mas um caminho de recuperação verificado é o que transforma a próxima paragem de emergência numa situação controlada.

Perguntas Frequentes

Um reinício pode corrigir um volume NAS em modo apenas leitura?

Um reinício pode completar a reprodução do diário ou limpar um estado temporário do serviço, mas não é prova de que o armazenamento está saudável. Verifique primeiro os registos guardados e o estado do pool, especialmente se o volume já mudou para apenas leitura mais do que uma vez.

Posso forçar uma remontagem em modo leitura-escrita tempo suficiente para copiar ficheiros?

Prefira copiar a partir do estado existente apenas de leitura. Uma montagem forçada em modo de escrita pode desencadear novas atualizações de metadados e pode falhar imediatamente se o kernel ainda detectar erros. Use-a apenas dentro de um plano de recuperação específico do sistema de ficheiros após proteger a melhor cópia disponível.

E se o SMART passar mas os registos ainda mostrarem erros de I/O?

Trate os registos como evidências não resolvidas. A falha pode envolver uma interface, cabo, backplane, controlador, caminho de energia ou um problema no disco não resumido pelo resultado geral do SMART. Isole um componente de cada vez e pare se os erros continuarem.

A verificação inicial mais segura é aquela que preserva as opções: proteger os dados legíveis, identificar a camada bloqueada e deixar que as evidências verificadas—e não uma remontagem forçada—escolham a próxima ação.