Queda de energia no servidor Linux - verificações de integridade de dados e corrupção de sistema operacional

Queda de energia no servidor Linux - verificações de integridade de dados e corrupção de sistema operacional

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 chkdskequivalente antigo ou moderno de repair-volume(no PowerShell)
  • Verifique a integridade dos arquivos principais do sistema operacional usandosfc.exe /scannow

Etapas de verificação/recuperação específicas do aplicativo, como MySQL databaseou LDAP directoriesetc., 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, aptou snapbancos 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

informação relacionada