Existe uma maneira de proteger o SSD da corrupção devido à perda de energia?

Temos um grupo de terminais de consumidores com o Linux, um servidor da Web local e o PostgreSQL instalado. Estamos recebendo relatórios de campo de máquinas com problemas e, sob investigação, parece que houve uma queda de energia e agora há algo errado com o disco.

Eu tinha assumido que o problema seria apenas com o banco de dados sendo corrompido ou arquivos com alterações recentes sendo embaralhadas, mas existem outros relatórios estranhos.

• arquivos com permissões erradas
• arquivos que se tornaram diretórios (por exemplo, index.phpagora é um diretório)
• diretórios que se tornaram arquivos
• arquivos com dados codificados

Há problemas com o banco de dados sendo corrompido, mas isso é algo que eu poderia esperar. O que mais me surpreende são os problemas mais básicos do sistema de arquivos - por exemplo, permissões ou alteração de um arquivo em diretório. Os problemas também estão acontecendo em arquivos que não foram alterados recentemente (por exemplo, o código e a configuração do software).

Isso é "normal" para corrupção de SSD? Originalmente, pensávamos que isso estava acontecendo em alguns SSDs baratos, mas temos isso em uma marca de nome (classe de consumidor).

FWIW, não estamos fazendo o autofsck na inicialização suja (não sei por que, eu sou novo). Temos no-breaks instalados em alguns locais, mas às vezes isso não é feito corretamente etc. Isso deve ser consertado, mas mesmo assim as pessoas podem desligar o terminal de maneira não limpa, etc. - para que não seja à prova de idiotas. O sistema de arquivos é ext4.

A questão: existe alguma coisa que possamos fazer para atenuar o problema no nível do sistema?

Encontrei alguns artigos referentes à desativação do cache de hardware ou à montagem da unidade no modo de sincronização, mas não tenho certeza se isso ajudaria nesse caso (corrupção de metadados e alterações não recentes). Também li uma referência sobre a montagem do sistema de arquivos no modo somente leitura. Não podemos fazer isso porque precisamos escrever, mas poderíamos criar uma partição somente leitura para o código e a configuração, se isso ajudasse.

Este é um exemplo de uma unidade sudo hdparm -i /dev/sda1:

Model=KINGSTON RBU-SMS151S364GG, FwRev=S9FM02.5, SerialNo=<deleted>
Config={ Fixed }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=0
BuffType=unknown, BuffSize=unknown, MaxMultSect=16, MultSect=16
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=125045424
IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes:  pio0 pio3 pio4
DMA modes:  mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5 *udma6
AdvancedPM=yes: disabled (255) WriteCache=enabled
Drive conforms to: Unspecified:  ATA/ATAPI-3,4,5,6,7

Ao perder energia repentinamente, os SSDs MLC / TLC / QLC têm dois modos de falha:

• eles perdem as gravações em voo e somente em DRAM;
• eles podem corromper qualquer dado em repouso armazenado na página inferior da célula NAND que está sendo programada.

A primeira condição de falha é óbvia: sem proteção de energia, todos os dados que não estiverem no armazenamento estável (por exemplo: NAND propriamente dito), mas somente no cache volátil (DRAM) serão perdidos. O mesmo acontece com os discos mecânicos clássicos (e isso por si só pode causar estragos no sistema de arquivos que não emite fsyncs).

A segunda condição de falha é um caso de MLC + SSDs: ao reprogramar o bit de página alta para armazenar novos dados, uma perda inesperada de energia pode destruir / alterar o bit inferior (ou seja: dados confirmados anteriormente ).

A única solução verdadeira e mais óbvia é integrar um cache DRAM protegido contra perda de energia (geralmente usando bateria / supercaps), como sempre feito pelos controladores RAID de ponta; isso, no entanto, aumenta o custo / preço da unidade. As unidades consumidoras normalmente não têm caches protegidos contra perda de energia; em vez disso, eles usam uma variedade de soluções mais econômicas como:

• cache de gravação parcialmente protegido (ou seja: Crucial M500 / M550 / M600 +);
• Diário de alterações NAND (por exemplo: unidades Samsung, consulte atributo SMART PoR);
• regiões especiais SLC / pseudo-SLC NAND para absorver novas gravações sem dados anteriores em risco (por exemplo: Sandisk, Samsung, etc.).

Voltando à sua pergunta: suas unidades Kingstone são ultra baratas, usando um controlador não especificado e basicamente nenhuma especificação pública. Não me surpreende que uma súbita perda de energia tenha corrompido os dados anteriores. Infelizmente, mesmo a desativação do cache DRAM do disco (com a enorme perda de desempenho que ele comanda) não resolverá o seu problema, pois os dados anteriores (por exemplo: dados em repouso) podem e serão corrompidos por perdas de energia inesperadas. Se eles são baseados no antigo controlador Sandforce, até um bloco total de unidades pode ser esperado nas circunstâncias "corretas".

Sugiro fortemente que você revise seu no-break e, a médio prazo, substitua essas unidades antigas.

Uma última observação sobre o PostgreSQL e outros bancos de dados Linux: eles não desabilitam o cache do disco e não devem ser impedidos de fazer isso. Em vez disso, eles emitem fsyncs / FUAs periódicos / necessários para confirmar os dados principais para um armazenamento estável. É assim que as coisas devem ser feitas, a menos que exista uma razão muito convincente (por exemplo, uma unidade que se refira aos ATA FLUSHES / FUAs).

EDIT: se possível, considere migrar para um sistema de arquivos de soma de verificação como ZFS ou BTRFS. No mínimo, considere o XFS, que possui soma de verificação de diário e, ultimamente, mesmo soma de verificação de metadados. Se você for forçado a usar o EXT4, considere ativar o auto-fsck na inicialização (o fsck.ext4 é muito bom em reparar a corrupção).

Sim. Não obtenha SSD super barato - qualquer coisa fora do mercado consumidor de baixo custo possui capacitores e proteção total contra perda de energia. A AMD realmente não custa muito mais.

A primeira coisa a fazer é definir o tempo de recuperação e os objetivos do ponto de recuperação. Quanto tempo você tem para recuperar um desses terminais e qual ponto de dados no tempo é aceitável? Talvez em algumas horas você precise recuperar o backup da semana passada.

Todos os tipos de coisas estranhas podem acontecer aos arquivos se as gravações em voo forem perdidas. A prioridade do sistema de arquivos é manter sua própria consistência de metadados; eles podem não fornecer as mesmas garantias para seus dados. Em outras palavras, fscknão é garantido recuperar seus dados. Seu trabalho é obter um sistema de arquivos que será montado.

Então, poder. Instale, configure e teste se o no-break desligará o sistema normalmente. Isso permite que os caches do sistema de arquivos e as próprias unidades gravem.

E durabilidade das gravações nos discos. Leia o capítulo de confiabilidade do PostgreSQL . Use o diskchecker.plscript vinculado lá para fazer um teste de falha e determinar se os SSDs estão mentindo sobre se as gravações chegaram ao armazenamento não volátil. Se houver perda, considere a substituição por SSDs que possuem proteção contra perda de energia.

Editar: você adicionou detalhes de que o cache de gravação foi ativado. Você pode tentar desativar isso: hdparm -W0 /dev/sdaou o comando apropriado para uma matriz de hardware. Referência: Guia de administração de armazenamento RHEL .

As barreiras de gravação do sistema de arquivos impõem uma ordem de confirmações do diário. Não é uma garantia que os dados estejam intactos, mas é mais seguro para o sistema de arquivos com um cache volátil. Embora seja o padrão, adicionar a opção de montagem "barreira" documenta claramente que você valoriza a consistência sobre o desempenho.

Finalmente, a última linha de defesa. Faça um teste de restauração para garantir que você possa obter seu aplicativo e banco de dados no momento desejado. Isso é útil para todos os tipos de perda de dados, não apenas para falta de energia.