
Quais são as etapas de práticas recomendadas para verificar/recuperar-se de possível corrupção do sistema operacional Linux, no caso de queda de energia inesperada (ou falha do host da VM)?
É claro que "depende" da instalação e configuração, mas estou procurando ações/verificações comuns para executar na maioria dos sistemas operacionais Linux (Debian, Ubuntu, Mint, outros) e sistemas de arquivos (XFS, ZFS, EXT4, vfat) .
Não se trata de evitar desligamentos inoportunos - trata-se de lidar com quando eles acontecem e tentar garantir a melhor recuperação possível.
Estou ciente de que os sistemas operacionais tendem a detectar quando um sistema de arquivos não foi desmontado (como faria durante um desligamento normal) e, portanto, executa verificações automaticamente na inicialização, mas quais são essas verificações e como executá-las manualmente?
Por exemplo, e2fsck -f
é uma dessas ferramentas, mas para os não iniciados, quando pode/deve ser usada e quando não (ou não funcionará)?
Por exemplo, no Windows você pode fazer:
- Verifique se há corrupção do sistema de arquivos NTFS usando o
chkdsk
equivalente antigo ou moderno derepair-volume
(no PowerShell) - Verifique a integridade dos arquivos principais do sistema operacional usando
sfc.exe /scannow
Etapas de verificação/recuperação específicas do aplicativo, como MySQL database
ou LDAP directories
etc., estão fora do escopo desta questão - a menos que seja algo muito comum, como algum banco de dados de sistema operacional, por exemplo, apt
ou snap
bancos de dados.
O que você faz?
Responder1
Os sistemas de arquivos modernos fazem diário de metadados, o que significa que uma simples queda de energia não deve representar nenhum problema para a integridade do sistema de arquivos em si: as transações concluídas, mas não confirmadas, são reproduzidas, enquanto as transações parciais são revertidas.
Dados em trânsito ou em cache, no entanto,podeser perdido ou parcialmente gravado - afinal, se um aplicativo manipula alguns dados no sistema operacional para gravação assíncrona (ou seja: gravações normais), mas a máquina perde energia antes que o sistema operacional possa gravá-los no armazenamento permanente, os dadosvaiestar perdido.
Por esse motivo, aplicativos críticos como bancos de dados (exceto MyISAM
) implementam seu próprio registro em diário e gravam dados com semântica de sincronização - usando fsync()
e similares.
Resumindo: um desligamento não planejado geralmente não precisa de nenhum reparo no sistema de arquivos (além da reprodução automática do diário). A verificação de aplicativos depende do próprio aplicativo, com a maioria dos bancos de dados não sendo afetada por uma perda repentina de energia - a menos que use MyISAM
, querequercorrendomysqlcheck