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

Question

Temos um grupo de terminais de consumidor que tem o Linux, um servidor web local e o PostgreSQL instalado. Estamos recebendo relatórios de campo de máquinas com problemas e, após 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 há outros relatórios estranhos.

• arquivos com as permissões incorretas
• arquivos que se tornaram diretórios (por exemplo, index.php agora é um diretório)
• diretórios que se tornaram arquivos
• arquivos com dados embaralhados

Existem 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 no diretório. Os problemas também estão acontecendo em arquivos que não foram alterados recentemente (por exemplo, o código do software e a configuração).

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

FWIW, não estamos fazendo o autofsck em boot sujo (não sei por que - eu sou novo). Temos UPSs instalados em alguns locais, mas às vezes não é feito corretamente, etc. Isso deve ser corrigido, mas mesmo assim as pessoas podem desligar o terminal sem limpeza, etc. - então não é à prova de erros. O sistema de arquivos é ext4.

A pergunta: existe alguma coisa que podemos fazer para mitigar o problema no nível do sistema?

Encontrei alguns artigos referentes a desativar o cache de hardware ou montar a 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). Eu 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

    

Answer 1

Quando de repente perdem energia, os SSDs MLC / TLC / QLC têm dois modos de falha:

• eles perdem as gravações em andamento e somente na DRAM;
• eles podem corromper todos os dados em repouso armazenados 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 em armazenamento estável (isto é: NAND em si), mas somente em cache volátil (DRAM) serão perdidos. O mesmo acontece com discos mecânicos clássicos (e somente isso pode causar estragos no sistema de arquivos que não emitem fsyncs apropriadamente).

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

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

• cache de gravação parcialmente protegido (isto é: Crucial M500 / M550 / M600 +);
• NAND altera o diário (ou seja, unidades da Samsung, consulte o 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.).

Voltemos à sua pergunta: suas unidades Kingstone são ultra baratas, usando um controlador não especificado e basicamente sem especificações públicas. Não me surpreende que uma perda repentina de energia tenha corrompido dados anteriores. Infelizmente, mesmo a desativação do cache DRAM do disco (com a enorme perda de desempenho que ele comanda) não resolverá seu problema, já que os dados anteriores (isto é: data-at-rest) podem e serão corrompidos por perdas de energia não-esperadas. Se eles forem baseados no antigo controlador Sandforce, até mesmo um total de blocos de unidades pode ser esperado sob as circunstâncias "certas".

Sugiro vivamente que reveja a sua UPS e, a médio prazo, substitua estas unidades antigas.

Uma última nota sobre o PostgreSQL e outros bancos de dados Linux: eles não desativarão o cache do disco e não não serão expedidos para fazer isso. Em vez disso, eles emitem fsyncs / FUAs periódicos / obrigatórios para enviar dados importantes para o armazenamento estável. É assim que as coisas devem ser feitas, a menos que exista uma razão convincente muito (ou seja, uma unidade que esteja sobre o ATA FLUSHES / FUAs).

EDITAR: 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 tem soma de verificação de diário e, ultimamente, até mesmo soma de verificação de metadados. Se você for forçado a usar o EXT4, considere a possibilidade de ativar o auto-fsck na inicialização (fsck.ext4 é muito bom no reparo de corrupção).

    

Answer 2

Sim. Não fique super barato SSD - qualquer coisa fora do mercado de consumidor final baixo tem capacitadores e proteção total contra perda de energia. A AMD realmente não custa muito mais.

    

Answer 3

A primeira coisa a fazer é definir o tempo de recuperação e os objetivos do ponto de recuperação. Quanto tempo você precisa para recuperar um desses terminais e qual data point in time é aceitável? Talvez dentro de algumas horas você precise ser capaz de se recuperar do backup da semana anterior.

Todos os tipos de coisas estranhas podem acontecer com arquivos se as gravações em vôo 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, fsck não tem garantia de recuperar seus dados. Sua tarefa é obter um sistema de arquivos que será montado.

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

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

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

As barreiras de gravação do sistema de arquivos impõem uma ordem de confirmações de diário. Não é uma garantia de que os dados estarão 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 o valor da consistência em relação ao 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 ponto desejado no tempo. Isso é útil para todos os tipos de perda de dados, não apenas para falha de energia.