Tem como evitar corrompimento do sistema Linux em queda de energia?

[Arthur Guillermo]

Estou pensando montar um servidor onde fique ao meu acesso apenas de forma remota, como há quedas de energia gostaria de saber se há algum modo de tornar "inquebrável" o sistema Linux (não sei se na instalação ou coisa do tipo) 

Ainda não escolhi o sistema e após instalar presencialmente meu objetivo é apenas remoto (visando wake on lan e AC Start).

 

Da última vez que usei Linux para servidor (ano passado) ocorreu um corrompimento após queda de energia e pelo que vi precisaria estar presente para reparar o que dificultaria para mim no caso de eu já não estar na residência onde deixei o servidor.

 

Não estou muito a fim de um nobreak por ser um PC abandonado e de baixa capacidade, visando principalmente economia X pela busca

[Ferox Graxaim]

@Arthur Guillermo Boa noite!
Eu costumo usar TimeShift, que apesar de não tornar o sistema inquebrável, torna-o facilmente recuperável em caso de quebra. Agora "blindar" o sistema contra corrompimento em queda de energia não tem como, o máximo que pode fazer é manter o sistema sempre atualizado para correções de problemas que possam levar ao corrompimento por desligamento inesperado. Até mesmo porque Linux é muito difícil de corromper por queda de energia (apesar de não ser impossível), eu mesmo nunca consegui corrompê-lo por desligar de maneira abrupta. O que ocorreu foi a corrupção de arquivos de um programa específico? Se for esse o caso, acredito que não tenha como evitar, a não ser com um no-break. Apesar do no-break online (que é o único que pode ser usado com computador) ser um equipamento muito caro, valerá a pena o investimento se o servidor for muito importante e não pode falhar de maneira alguma.
Caso não queira gastar muito com um no-break online, e o servidor é um hardware que vai ser trocado mais pra frente e/ou tu não estiveres preocupado com a danos na fonte a longo prazo, até dá de pensar num no-break offline, mas é algo que como falei, é nocivo para a fonte do computador.

[Arthur Guillermo]

20 horas atrás, Ferox Graxaim disse:

@Arthur Guillermo Boa noite!
Eu costumo usar TimeShift, que apesar de não tornar o sistema inquebrável, torna-o facilmente recuperável em caso de quebra.

Boa noite @Ferox Graxaim , interessante a opção, porém o mesmo serve para arquivos do sistema ou apenas arquivos pessoais ?

20 horas atrás, Ferox Graxaim disse:

O que ocorreu foi a corrupção de arquivos de um programa específico? Se for esse o caso, acredito que não tenha como evitar, a não ser com um no-break.

Não creio que tenha sido de um programa específico, porém meu medo de corrupção é por não estar na residência para poder consertar, possuo um IP válido e este computador abandonado, estou em outra cidade por estudos porém por ter energia solar abandonada pois não posso usar em outra concessionária, gostaria de mantê-lo 24h, ainda que tenha quedas de energia (não importa as quedas)

 

Meu problemas são como este (o último que ocorreu):

 

Não teria como ter acesso remoto a ele para concerto (creio eu), esse erro foi ocasionado por quedas de energia em quanto estava fora da residência

[Marcos FRM]

Essa tela mostra erro de hardware: alguns setores do disco não puderam ser lidos. Pode ser momentâneo, ou não. O disco está falhando, mesmo assim. Contra esse tipo de erro, apenas RAID pode ajudar.

 

Os três principais sistemas de arquivos de uso geral do Linux -- EXT4, XFS e Btrfs -- são configurados por padrão para manter a ordenação do journal em dia, de forma que, em teoria, num desligamento inesperado, a estrutura do sistema de arquivos em si poderá ser recuperada usando o journal na próxima inicialização.

 

Digo em teoria pois hardware doméstico não tem ajuste fino para isso. Não horando ATA_CMD_FLUSH sempre, por exemplo, fará o coitado do sistema de arquivos ter muito mais trabalho para recuperar-se de um desligamento incorreto.

 

Exemplo prático: SSDs para o mercado corporativo possuem um recurso chamado Power Loss Protection (PLP); é um banco de capacitores que permite ao chip controlador ter tempo suficiente para transferir tudo que está na RAM usada como cache para as memórias flash e atualizar seu mapeamento de endereços (qual endereço LBA corresponde a quais bits em quais páginas) na ocasião de falta de energia:

 

 

(de https://www.servethehome.com/micron-7400-pro-3-84tb-and-960gb-m-2-pcie-gen4-ssds-with-plp-review/)

 

SSDs domésticos tentam através do firmware fazer o mesmo, até chamam de "Firmware PLP", mas não é a mesma robustez do banco de capacitores.

[Arthur Guillermo]

@Marcos FRM como quero usar uma medida mais econômica e pelo jeito o que passou ser problema de hardware, existem setores ruins possivelmente, seria mais útil eu separar sistema em um armazenamento externo e arquivos no HD que ocorreu isso ?

 

Tava procurando uma solução mais simples e econômica... afinal seria uma "reciclagem" de um PC abandonado.

 

 

[Marcos FRM]

Rodar via USB? Fica ruim. Tem o paliativo de zerar o disco por completo e depois reinstalar o Linux -- a partir de qualquer mídia live: dd if=/dev/zero of=/dev/sdx bs=1M status=progress (substituindo sdx pelo nome correto do dispositivo em questão). Isso faz o firmware realocar os setores ruins, caso ainda seja possível. No entanto, o ideal é trocar o disco.

 

Edit: não custa lembrar que esse comando dd vai apagar tudo do disco, né...

[Arthur Guillermo]

@Marcos FRM após execução do comando, seria melhor eu realizar uma verificação então de bad blocks e isolar se existentes ?

 

Minha ideia ainda é formatar o computador de qualquer modo, então não importa a perca de informações existentes nele.

[Marcos FRM]

Depois que o comando dd terminar, caso o firmware tenha dado conta do recado, é para os setores defeituosos desaparecerem. Você pode fazer uma formatação lenta com o mkfs.ext4 posteriormente, porém não sei se as distribuições oferecem opção para isso nos instaladores. De qualquer forma, ainda existindo setores ruins depois do dd, o disco não presta mais. Escrevi sobre isso anos atrás aqui.

[Marcos FRM]

Cabe um esclarecimento sobre o mkfs.ext4 no que diz respeito à "formatação lenta". Existem as seguintes opções que afetam o tempo requerido para criar o sistema de arquivos:

 

-c ou -cc

Roda o bad blocks por baixo do capô para verificar o disco. -c é uma verificação somente leitura e -cc leitura/escrita. Como o firmware realocará setores ruins durante a gravação de dados, precisa ser -cc.

 

-E lazy_itable_init=1,lazy_journal_init=1

Aceleram a criação do sistema de arquivos, sem ligação com a procura de setores defeituosos. Habilitadas por padrão e aplicadas depois da verificação do bad blocks concluir.

[Ferox Graxaim]

Em 13/07/2022 às 18:35, Arthur Guillermo disse:

Boa noite @Ferox Graxaim , interessante a opção, porém o mesmo serve para arquivos do sistema ou apenas arquivos pessoais ?

Configurável, mas é principalmente arquivos de sistema.

 

Em 13/07/2022 às 18:35, Arthur Guillermo disse:

Não creio que tenha sido de um programa específico, porém meu medo de corrupção é por não estar na residência para poder consertar, possuo um IP válido e este computador abandonado, estou em outra cidade por estudos porém por ter energia solar abandonada pois não posso usar em outra concessionária, gostaria de mantê-lo 24h, ainda que tenha quedas de energia (não importa as quedas)

Nesse caso a melhor opção seria um no-break mesmo... Infelizmente o mais barato que posso recomendar é o NHS Premium Online G2 1500VA, acredito ser o suficiente, mas qual a configuração do computador?
 

[Arthur Guillermo]

@Marcos FRM @Ferox Graxaim

realizei o dd do disco, instalei o OS e esta rodando, já teve uma queda de energia e até agora está ok... 

 

Usei a ideia do TimeShift para tentar recuperar de forma rápida, porém, creio que só com o tempo para poder ver realmente se vai dar certo sem o nobreak, estava pensando na ideia do nobreak sim, porém está fora do meu orçamento, como a tentativa é reciclar isto para coisas básicas creio que não valha a pena 

 

O computador é um dual core 1.1GHz 4GB RAM DDR3, HD Toshiba 500GB

[Marco Tada]

Em teoria a maioria dos sistemas de arquivos mais modernos usam journaling, onde as mudanças que estão sendo feitas no sistema de arquivos são guardadas em um log antes da escrita, para que em caso de problemas como um crash ou falta de energia o sistema de arquivos possa ser recuperado mais facilmente. No primeiro boot após uma falha o sistema vai identificar que não foi dado shutdown no sistema e tentará fazer uma correção no startup.

Nesse seu caso, está reclamando do fsck que roda no startup, provavelmente vai ter que iniciar um linux com uma mídia externa, e rodar o fsck manualmente em cada filesystem.

[JohnWayne]

@Arthur Guillermo Amigo, linux é uma porcari a quando se trata de corromper sistema de arquivos. O journaling não serve pra nada. Pode ser o melhor sistema de arquivos da Terra; pode ter RAID, ele VAI corromper se cair a energia.
Tenho um server caseiro; a única forma de mantê-lo funcionando foi comprar um nobreak. Com a atenção de quando a queda é prolongada, desligá-lo corretamente antes de a bateria acabar.

Uso um bem baratinho de 300VA, já que minha máquina não consome muito (atom), dura quase 40min.

[Marcos FRM]

7 horas atrás, JohnWayne disse:

Uso um bem baratinho de 300VA

 

Nenhum presta, infelizmente. Não entrarei nessa discussão aqui, pois há a seção sobre isso no fórum em que tal assunto já foi comentado à exaustão.

 

Sobre os sistemas de arquivos Linux serem menos resistentes à desligamentos incorretos... até antes de habilitarem por padrão a opção de montagem "barrier", era uma calamidade de fato. Contudo, desde lá (isso deve ter uns 15 anos mais ou menos), melhorou muito. O que ainda existe são comportamentos inseguros de programas (não do kernel) que assumem coisas que os sistemas de arquivos não fazem, ou seja: não possuem cuidado ao manusear arquivos importantes.

 

É uma problemática loooonga...

 

https://lwn.net/Articles/351422/

 

...que ainda está aí, sendo aos poucos atacada. Diria que as coisas melhoraram desde lá. Me vem à cabeça uma chamada de sistema relativamente recente, renameat2() (https://stackoverflow.com/a/50353568), que melhora a API no que diz respeito a essa questão.

 

O Windows é conhecido por ter um desempenho muito inferior no acesso ao disco (gravação) por dar garantias muito além das dadas pelo Linux aos programas do espaço de usuário.