Resposta direta: quando um sistema de arquivos Linux entra em modo somente leitura, preserve os logs, reduza gravações e confirme montagem, disco e erros do kernel antes de tentar remontar. Planeje manutenção e backup, pois forçar escrita ou reiniciar repetidamente pode ampliar corrupção ou dificultar a recuperação.
Revisão técnica: 08/09/2026.
Confirme onde ocorre a falha
Registre caminho, comando, mensagem e horário. Verifique pontos de montagem e tente uma operação segura no volume afetado. Diferencie permissão negada, quota, falta de espaço e sistema montado como somente leitura. Uma aplicação pode mostrar erro genérico enquanto outras partições continuam normais.
Preserve sinais do kernel
Consulte mensagens do kernel, journal e logs de armazenamento no período anterior ao sintoma. Procure erro de I/O, sistema de arquivos, dispositivo, controladora ou caminho remoto. Copie as evidências para outro local quando possível. Após reiniciar, mensagens voláteis e sequência causal podem desaparecer.
Avalie disco e infraestrutura
Confira espaço, inodes, estado do dispositivo, RAID, volume lógico e alertas do provedor. Não conclua que o disco está saudável apenas porque ainda responde. Em máquina virtual, inclua camada de armazenamento e eventos do host. Evite testes destrutivos ou longos no volume de produção durante o impacto.
Escolha contenção e recuperação
Interrompa serviços que insistem em gravar, preserve dados recuperáveis e avalie failover ou restauração. Não remonte para leitura e escrita sem entender por que a proteção foi acionada. Ferramentas de verificação devem ser usadas conforme o tipo de sistema, geralmente com o volume desmontado e backup disponível.
Valide antes de liberar tráfego
Depois do reparo ou restauração, confirme montagem, leitura, gravação, permissões, bancos, filas e aplicações. Compare dados e teste reinicialização controlada quando fizer parte do plano. Monitore erros e latência. Para bancos afetados, siga também a triagem de MySQL lento ou indisponível.
Reduza a chance de recorrência
Documente causa, componente substituído, comandos e critérios de decisão. Melhore alertas de I/O, espaço, RAID e erros do kernel. Teste backup e recuperação em infraestrutura separada. Registre ações e responsáveis no relatório pós-incidente, sem tratar redundância local como substituto de backup.
