電力損失による破損からSSDを保護する方法はありますか？

Linux、ローカルWebサーバー、およびPostgreSQLがインストールされたコンシューマターミナルのグループがあります。問題のあるマシンのフィールドレポートを取得していますが、調査の結果、停電が発生したようで、ディスクに何か問題があるようです。

私は、問題は単にデータベースが破損すること、または最近の変更を含むファイルがスクランブルされることであると考えていましたが、他の奇妙な報告があります。

• 間違った許可を持つファイル
• ディレクトリになったファイル（たとえば、index.php現在はディレクトリ）
• ファイルになったディレクトリ
• スクランブルされたデータを含むファイル

データベースが破損する問題がありますが、それは私が期待できることです。私がもっと驚いたのは、より基本的なファイルシステムの問題です。たとえば、アクセス許可やファイルをディレクトリに変更することです。問題は、最近変更されていないファイル（ソフトウェアコードや構成など）でも発生しています。

これはSSD破損の「正常」ですか？もともとは安価なSSDで起こっていると思っていましたが、有名ブランド（消費者グレード）で起こっています。

FWIW、クリーンブートではautofsckを実行していません（理由はわかりませんが、私は新しいです）。一部の場所にはUPSが設置されていますが、場合によっては適切に実行されないなどがあります。これは修正する必要がありますが、それでも端末の電源を落とすことができます。ファイルシステムはext4です。

質問：システムレベルで問題を軽減するためにできることはありますか？

ハードウェアキャッシュをオフにするか、同期モードでドライブをマウントすることに関する記事をいくつか見つけましたが、この場合に役立つかどうかはわかりません（メタデータの破損と最近の変更ではありません）。また、読み取り専用モードでのファイルシステムのマウントに関するリファレンスも読んでいます。書き込む必要があるため、これを行うことはできませんが、それが役立つ場合は、コードと構成用の読み取り専用パーティションを作成できます。

これはドライブの例です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

突然電源が失われると、MLC / TLC / QLC SSDには2つの障害モードがあります。

• 飛行中およびDRAMのみの書き込みは失われます。
• プログラム中のNANDセルの下位ページに保存されている保存データを破損する可能性があります。

最初の障害状態は明らかです。電源保護がないと、安定したストレージ（つまり、NAND自体）になく、揮発性キャッシュのみ（DRAM）にあるデータが失われます。同じことが従来のメカニカルディスクでも発生します（それだけでは、fsyncを適切に発行しないファイルシステムに大混乱を引き起こす可能性があります）。

2番目の障害状態はMLC + SSDの問題です。新しいデータを保存するために上位ページビットを再プログラムする場合、予期しない電力損失により下位ビット（つまり、以前にコミットされたデータ）も破壊/変更される可能性があります。

真の、そして最も明白な唯一の解決策は、ハイエンドのRAIDコントローラーによって永遠に行われているように、電力損失保護されたDRAMキャッシュ（一般にバッテリー/スーパーキャップを使用）を統合することです。ただし、これにより、ドライブのコスト/価格が高くなります。一般に、消費者向けドライブには、電力損失で保護されたキャッシュがありません。むしろ、より経済的なソリューションを次のように使用しています。

• 部分的に保護された書き込みキャッシュ（例：Crucial M500 / M550 / M600 +）;
• NANDはジャーナルを変更します（例：Samsungドライブ、SMART PoR属性を参照）。
• 特別なSLC / pseudo-SLC NANDリージョンにより、以前のデータを危険にさらすことなく新しい書き込みを吸収します（例：Sandisk、Samsungなど）。

質問に戻ります。Kingstoneドライブは非常に安価なドライブであり、指定されていないコントローラーを使用し、基本的には公開仕様はありません。突然の電力損失が以前のデータを破壊したことは、私を驚かせません。残念ながら、ディスクのDRAMキャッシュを無効にしても（コマンドのパフォーマンスが大幅に低下する）、問題は解決しません。以前のデータ（保存データ）が予期せぬ電力損失によって破損する可能性があるためです。古いSandforceコントローラをベースにしている場合、「適切な」状況では完全なドライブブリックでさえ期待できます。

UPSを見直し、中期的にはこれらの老朽化したドライブを交換することを強くお勧めします。

PostgreSQLと他のLinuxデータベースに関する最後の音：彼らはなりません、ディスクのキャッシュを無効にしなければならないではないことをやってexptectedします。むしろ、定期的/必要なfsync / FUAを発行して、キーデータを安定したストレージにコミットします。これは、非常に説得力のある理由（つまり、ATA FLUSHES / FUAに関連するドライブ）が存在しない限り、物事を行う方法です。

編集：可能であれば、チェックサムファイルシステムへのZFSまたはBTRFSとしての移行を検討してください。少なくとも、ジャーナルのチェックサムと、最近ではメタデータのチェックサムも備えたXFSを検討してください。EXT4の使用を強制されている場合は、起動時にauto-fsckを有効にすることを検討してください（fsck.ext4は修復の破損に非常に適しています）。

うん。超安価なSSDを入手しないでください。ローエンドの消費者市場以外には、コンデンサと電力損失に対する完全な保護機能があります。Amdの費用はそれほどかかりません。

最初に行うことは、復旧時間と復旧ポイントの目標を定義することです。これらの端末の1つを回復するのにどれくらいの期間が必要ですか？また、どのデータポイントが許容されますか？おそらく数時間以内に、先週のバックアップに回復できる必要があります。

飛行中の書き込みが失われると、ファイルにあらゆる種類の奇妙なことが起こります。ファイルシステムの優先度は、独自のメタデータの一貫性を維持することであり、データに対して同じ保証を提供しない場合があります。言い換えれば、fsckデータの回復が保証されているわけではありません。その仕事は、マウントするファイルシステムを取得することです。

だから、力。UPSがシステムを正常にシャットダウンすることをインストール、構成、およびテストします。これにより、ファイルシステムキャッシュとドライブ自体が書き込みできるようになります。

そして、ディスクへの書き込みの耐久性。PostgreSQLの信頼性の章を読んでください。diskchecker.plそこにリンクされているスクリプトを使用してクラッシュテストを実行し、書き込みが不揮発性ストレージに到達したかどうかについてSSDが嘘をついているかどうかを判断します。損失がある場合は、電力損失保護があることが知られているSSDと交換することを検討してください。

編集：書き込みキャッシュが有効になっているという詳細を追加しました。それを無効にしようとすることができます：hdparm -W0 /dev/sdaまたはハードウェアアレイの適切なコマンド。参照： RHELストレージ管理ガイド。

ファイルシステムの書き込みバリアは、ジャーナルコミットの順序を強制します。データが無傷であることを保証するものではありませんが、揮発性キャッシュを備えたファイルシステムにとっては安全です。これはデフォルトですが、「バリア」マウントオプションを追加すると、パフォーマンスよりも一貫性を重視することが明確に文書化されます。

最後に、最後の防衛線。復元テストを実行して、アプリケーションとデータベースを目的の時点に到達できることを確認します。これは、停電だけでなく、あらゆる種類のデータ損失に役立ちます。