Esiste un modo per proteggere l'SSD dalla corruzione a causa della perdita di potenza?

Abbiamo un gruppo di terminali consumer su cui è installato Linux, un server Web locale e PostgreSQL. Stiamo ricevendo segnalazioni sul campo di macchine con problemi e dopo un'indagine sembra che ci sia stata un'interruzione di corrente e ora c'è qualcosa che non va nel disco.

Avevo supposto che il problema sarebbe dovuto al fatto che il database veniva danneggiato o che i file con le modifiche recenti venivano confusi, ma ci sono altri rapporti strani.

• file con autorizzazioni errate
• file che sono diventati directory (ad esempio, index.phpora è una directory)
• directory che sono diventate file
• file con dati codificati

Ci sono problemi con il database che viene danneggiato, ma è qualcosa che mi posso aspettare. Ciò di cui sono più sorpreso sono i problemi di base del file system, ad esempio le autorizzazioni o la modifica di un file nella directory. I problemi si verificano anche in file che non sono stati modificati di recente (ad esempio, il codice software e la configurazione).

Questo è "normale" per la corruzione SSD? Inizialmente pensavamo che stesse succedendo su alcuni SSD economici, ma abbiamo avuto questo su un marchio di marca (di qualità consumer).

FWIW, non stiamo facendo autofsck all'avvio impuro (non so perché, sono nuovo). Abbiamo UPS installati in alcune località, ma a volte non è fatto correttamente, ecc. Questo dovrebbe essere risolto, ma anche in questo caso le persone possono spegnere il terminale in modo impuro, ecc., Quindi non è infallibile. Il filesystem è ext4.

La domanda: c'è qualcosa che possiamo fare per mitigare il problema a livello di sistema?

Ho trovato alcuni articoli che si riferiscono allo spegnimento della cache hardware o al montaggio dell'unità in modalità di sincronizzazione, ma non sono sicuro che ciò possa aiutare in questo caso (corruzione dei metadati e modifiche non recenti). Ho anche letto un riferimento sul montaggio del filesystem in modalità di sola lettura. Non possiamo farlo perché dobbiamo scrivere, ma potremmo creare una partizione di sola lettura per il codice e la configurazione, se ciò potesse aiutare.

Questo è un esempio di unità 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

Quando si perde improvvisamente energia, gli SSD MLC / TLC / QLC hanno due modalità di guasto:

• perdono le scritture in volo e solo in DRAM;
• possono corrompere qualsiasi dato a riposo memorizzato nella pagina inferiore della cella NAND in fase di programmazione.

La prima condizione di errore è ovvia: senza protezione dell'alimentazione, tutti i dati che non si trovano su una memoria stabile (ovvero: NAND stessa) ma solo su cache volatile (DRAM) andranno persi. Lo stesso accade con i dischi meccanici classici (e questo da solo può provocare il caos nel filesystem che non emette correttamente fsync).

La seconda condizione di errore è una relazione MLC + SSD: durante la riprogrammazione del bit della pagina alta per l'archiviazione di nuovi dati, una perdita di potenza imprevista può distruggere / modificare anche il bit inferiore (ovvero: dati di commit precedenti ).

L'unica vera, e più ovvia, soluzione è quella di integrare una cache DRAM protetta dalla perdita di potenza (generalmente usando batteria / supercaps), come sempre fatto dai controller RAID di fascia alta; questo, tuttavia, aumenta il costo / prezzo dell'unità. Le unità consumer in genere non dispongono di cache protette dalla perdita di potenza; piuttosto, usano una serie di soluzioni più economiche come:

• cache di scrittura parzialmente protetta (es .: Crucial M500 / M550 / M600 +);
• Diario delle modifiche NAND (es .: unità Samsung, vedere l'attributo SMART PoR);
• regioni NAND speciali SLC / pseudo-SLC per assorbire nuove scritture senza precedenti dati a rischio (es. Sandisk, Samsung, ecc.).

Torna alla tua domanda: le tue unità Kingstone sono ultra-economiche, usando un controller non specificato e praticamente nessuna specifica pubblica. Non mi sorprende che un'improvvisa perdita di potenza abbia danneggiato i dati precedenti. Sfortunatamente, anche la disabilitazione della cache DRAM del disco (con l'enorme perdita di prestazioni che comanda) non risolverà il problema, poiché i dati precedenti (ad esempio: dati a riposo) possono e saranno danneggiati da perdite di potenza inaspettate. Se si basano sul vecchio controller Sandforce, nelle circostanze "giuste" ci si può aspettare anche un mattone di unità totale.

Consiglio vivamente di rivedere il vostro UPS e, a medio termine, di sostituire queste unità obsolete.

Un'ultima nota su PostgreSQL e altri database Linux: non disabiliteranno la cache del disco e non dovrebbero essere previsti. Piuttosto, emettono fsyncs / FUA periodici / richiesti per eseguire il commit dei dati chiave in un archivio stabile. Questo è il modo in cui le cose dovrebbero essere fatte a meno che non esista una ragione molto convincente (ovvero: un impulso che risiede su ATA FLUSHES / FUAs).

EDIT: se possibile, considera la migrazione a un filesystem di checksum come ZFS o BTRFS. Per lo meno, considera XFS, che ha checksum journal e, ultimamente, checksum metadata. Se sei costretto a usare EXT4, considera di abilitare auto-fsck all'avvio (fsck.ext4 è molto bravo a riparare la corruzione).

Si. Non ottenere SSD super economico: qualsiasi cosa al di fuori del mercato consumer di fascia bassa ha condensatori e protezione completa contro la perdita di potenza. Amd non costa davvero molto di più.

La prima cosa da fare è definire i tempi di recupero e gli obiettivi dei punti di ripristino. Per quanto tempo è necessario ripristinare uno di questi terminali e quale data point è accettabile? Forse entro un paio d'ore devi essere in grado di ripristinare il backup della scorsa settimana.

Se si perdono le scritture in volo, possono succedere cose strane ai file. La priorità del file system è mantenere la coerenza dei metadati, potrebbero non fornire le stesse garanzie per i tuoi dati. In altre parole, fscknon è garantito il recupero dei dati. Il suo compito è procurarti un file system che monterà.

Quindi potenza. Installa, configura e verifica che UPS spenga il sistema con grazia. Ciò consente alle cache del file system e alle unità stesse di scrivere.

E, la durata delle scritture sui dischi. Leggi il capitolo sull'affidabilità di PostgreSQL . Utilizzare lo diskchecker.plscript collegato lì per eseguire un crash test e determinare se gli SSD mentono se le scritture arrivano alla memoria non volatile. In caso di perdita, prendere in considerazione la sostituzione con SSD noti per la protezione della perdita di potenza.

Modifica: sono stati aggiunti dettagli per l'attivazione della cache di scrittura. È possibile tentare di disabilitare quello: hdparm -W0 /dev/sdao il comando appropriato per un array hardware. Riferimento: guida all'amministrazione della memoria RHEL .

Le barriere di scrittura del file system applicano un ordine di commit del journal. Non è una garanzia che i dati saranno intatti, ma è più sicuro per il file system con una cache volatile. Sebbene sia l'impostazione predefinita, l'aggiunta dell'opzione di montaggio "barriera" documenta chiaramente la tua coerenza rispetto alle prestazioni.

Finalmente l'ultima linea di difesa. Esegui un test di ripristino per assicurarti di poter ottenere l'applicazione e il database nel momento desiderato. Ciò è utile per tutti i tipi di perdita di dati, non solo per mancanza di corrente.