有沒有辦法保護 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突然斷電時，有兩種故障模式：
- 他們失去了飛行中和僅在 DRAM 中的寫入；
- 它們可以破壞儲存在正在程式的 NAND 單元下部頁面中的任何靜態數據。
第一個故障情況很明顯：沒有電源保護，任何不在穩定儲存（即：NAND 本身）但僅在易失性記憶體（DRAM）上的數據都會失去。經典機械磁碟也會發生同樣的情況（僅此一項就會對無法正確發出 fsync 的文件系統造成嚴重破壞）。
第二個故障情況是 MLC+ SSD 事件：在重新程式高頁位以儲存新數據時，意外斷電也可能破壞/更改低位（即：先前送出的數據）。
唯一真正且最明顯的解決方案是集成一個斷電保護的 DRAM 記憶體（通常使用電池/超級電容），就像高端 RAID 控制器永遠做的那樣；但是，這會增加驅動器成本/價格。消費類驅動器通常沒有斷電保護記憶體；相反，他們使用了一系列更經濟的解決方案：
- 部分受保護的寫記憶體（即：Crucial M500/M550/M600+）；
- NAND改變日誌（即：三星驅動，見SMART PoR屬性）；
- 特殊的 SLC/pseudo-SLC NAND 區域來吸收新的寫入，而不會對以前的數據造成風險（即：Sandisk、Samsung 等）。
回到你的問題：你的 Kingstone 驅動器是超便宜的，使用未指定的控制器，基本上沒有公開規格。突然斷電損壞以前的數據並不令我感到驚訝。不幸的是，即使禁用磁碟的 DRAM 記憶體（它會導致大量性能損失）也無法解決您的問題，因為以前的數據（即：靜態數據）可能而且將會因意外的電源損失而損壞。如果它們基於舊的 Sandforce 控制器，那麼在“正確”的情況下，甚至可以預期整個驅動器磚。
我強烈建議檢查您的 UPS，並在中期更換這些老化的驅動器。
關於 PostgreSQL 和其他 Linux 數據庫的最後一點說明：它們不會禁用磁碟的記憶體，也不應該這樣做。相反，他們發出定期/必需的 fsyncs/FUA 以將關鍵數據送出到穩定儲存。除非存在非常令人信服的理由（即：關於 ATA FLUSHES/FUA 的驅動器），否則應該這樣做。
**編輯：**如果可能，考慮遷移到校驗和文件系統作為 ZFS 或 BTRFS。至少考慮一下 XFS，它有日誌校驗和，最近甚至還有元數據校驗和。如果您被迫使用 EXT4，請考慮在啟動時啟用 auto-fsck（fsck.ext4 非常擅長修復損壞）。