Apakah ada cara untuk melindungi SSD dari kerusakan akibat kehilangan daya?

Kami memiliki sekelompok terminal konsumen yang menginstal Linux, server web lokal, dan PostgreSQL. Kami mendapatkan laporan lapangan tentang mesin yang bermasalah dan setelah diselidiki sepertinya ada pemadaman listrik dan sekarang ada yang salah dengan disk.

Saya berasumsi masalahnya hanya dengan database menjadi rusak, atau file dengan perubahan baru-baru ini diacak, tetapi ada laporan aneh lainnya.

• file dengan izin yang salah
• file yang telah menjadi direktori (misalnya, index.phpsekarang menjadi direktori)
• direktori yang telah menjadi file
• file dengan data acak

Ada masalah dengan database menjadi rusak, tapi itu sesuatu yang bisa saya harapkan. Yang lebih mengejutkan saya adalah masalah sistem file yang lebih mendasar - misalnya, izin atau mengubah file menjadi direktori. Masalahnya juga terjadi pada file yang tidak berubah baru-baru ini (misalnya, kode perangkat lunak dan konfigurasi).

Apakah ini "normal" untuk korupsi SSD? Awalnya kami pikir itu terjadi pada beberapa SSD murah, tetapi kami memiliki ini terjadi pada nama-merek (tingkat konsumen.)

FWIW, kami tidak melakukan autofsck pada boot yang tidak bersih (tidak tahu kenapa- saya baru). Kami memiliki UPS yang dipasang di beberapa lokasi, tetapi kadang-kadang itu tidak dilakukan dengan benar, dll. Ini harus diperbaiki, tetapi bahkan orang-orang dapat mematikan terminal secara tidak bersih, dll. - jadi itu bukan bukti yang bodoh. Sistem file adalah ext4.

Pertanyaannya: adakah yang bisa kita lakukan untuk mengurangi masalah di tingkat sistem?

Saya menemukan beberapa artikel yang merujuk pada mematikan cache perangkat keras atau memasang drive dalam mode sinkronisasi, tapi saya tidak yakin apakah itu akan membantu dalam kasus ini (korupsi metadata dan perubahan yang tidak baru-baru ini). Saya juga membaca referensi tentang pemasangan sistem file dalam mode read-only. Kami tidak dapat melakukan itu karena kami perlu menulis, tetapi kami dapat membuat partisi read-only untuk kode dan konfigurasi jika itu akan membantu.

Ini adalah contoh drive 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

Ketika tiba-tiba kehilangan daya, SSD MLC / TLC / QLC memiliki dua mode kegagalan:

• mereka kehilangan tulisan dalam penerbangan dan hanya dalam DRAM;
• mereka dapat merusak data yang disimpan di halaman bawah sel NAND yang diprogram.

Kondisi kegagalan pertama jelas: tanpa perlindungan daya, data apa pun yang tidak pada penyimpanan stabil (yaitu: NAND itu sendiri) tetapi hanya pada cache volatil (DRAM) akan hilang. Hal yang sama terjadi dengan disk mekanis klasik (dan itu saja dapat mendatangkan malapetaka pada sistem file yang tidak mengeluarkan fsyncs dengan benar).

Kondisi kegagalan kedua adalah urusan MLC + SSD: ketika memprogram ulang bit halaman tinggi untuk menyimpan data baru, kehilangan daya yang tidak terduga dapat menghancurkan / mengubah bit yang lebih rendah (yaitu: data yang dilakukan sebelumnya ) juga.

Satu-satunya solusi yang benar, dan paling jelas, adalah mengintegrasikan cache DRAM yang kehilangan daya (umumnya menggunakan baterai / supercaps), seperti yang dilakukan sejak dulu oleh pengontrol RAID kelas atas; ini, bagaimanapun, meningkatkan biaya / harga penggerak. Drive konsumen biasanya tidak memiliki cache yang dilindungi kehilangan daya; alih-alih, mereka menggunakan serangkaian solusi yang lebih ekonomis sebagai:

• cache tulis yang dilindungi sebagian (mis: Crucial M500 / M550 / M600 +);
• NAND mengubah jurnal (yaitu: drive Samsung, lihat atribut SMART PoR);
• daerah SLC / pseudo-SLC NAND khusus untuk absorbe penulisan baru tanpa data sebelumnya yang berisiko (yaitu: Sandisk, Samsung, dll).

Kembali ke pertanyaan Anda: drive Kingstone Anda sangat murah, menggunakan pengontrol yang tidak ditentukan dan pada dasarnya tidak ada spesifikasi publik. Tidak mengejutkan saya bahwa kehilangan daya secara tiba-tiba merusak data sebelumnya. Sayangnya, bahkan menonaktifkan cache DRAM disk (dengan hilangnya kinerja besar-besaran yang diperintahkan) tidak akan menyelesaikan masalah Anda, karena data sebelumnya (yaitu: data-at-rest) dapat, dan akan, rusak oleh kehilangan daya yang tidak terdeteksi. Jika mereka didasarkan pada pengontrol Sandforce lama, bahkan total drive bata dapat diharapkan dalam keadaan "benar".

Saya sangat menyarankan untuk meninjau UPS Anda dan, dalam jangka menengah, untuk mengganti drive yang menua ini.

Catatan terakhir tentang PostgreSQL dan database Linux lainnya: mereka tidak akan menonaktifkan cache disk dan seharusnya tidak diharapkan untuk melakukan itu. Sebaliknya, mereka melakukan fsyncs / FUAs secara berkala / diperlukan untuk mengkomit data kunci ke penyimpanan yang stabil. Ini adalah cara segala sesuatu harus dilakukan kecuali ada alasan yang sangat menarik (yaitu: drive yang terletak tentang ATA FLUSHES / FUA).

EDIT: jika mungkin, pertimbangkan untuk bermigrasi ke sistem file checksumming sebagai ZFS atau BTRFS. Paling tidak mempertimbangkan XFS, yang memiliki jurnal checksum dan, belakangan, bahkan metadata checksum. Jika Anda terpaksa menggunakan EXT4, pertimbangkan untuk mengaktifkan auto-fsck saat startup (fsck.ext4 sangat baik dalam memperbaiki korupsi).

Ya. Jangan dapatkan SSD super murah - apa pun di luar pasar konsumen kelas bawah memiliki kapasitor dan perlindungan penuh terhadap kehilangan daya. Amd benar-benar tidak membutuhkan biaya lebih banyak.

Hal pertama yang harus dilakukan adalah menentukan waktu pemulihan dan sasaran titik pemulihan. Berapa lama Anda harus memulihkan salah satu terminal ini, dan titik waktu apa yang dapat diterima? Mungkin dalam beberapa jam Anda harus dapat memulihkan cadangan minggu lalu.

Segala macam hal aneh dapat terjadi pada file jika dalam penerbangan menulis hilang. Prioritas sistem file mempertahankan konsistensi metadata mereka sendiri, mereka mungkin tidak memberikan jaminan yang sama untuk data Anda. Dengan kata lain, fscktidak dijamin untuk memulihkan data Anda. Tugasnya adalah memberi Anda sistem file yang akan dipasang.

Jadi, kekuatan. Instal, konfigurasikan, dan uji apakah UPS akan mematikan sistem dengan anggun. Ini memungkinkan cache sistem file dan drive itu sendiri untuk menulis.

Dan, daya tahan penulisan ke disk. Baca bab keandalan PostgreSQL . Gunakan diskchecker.plskrip yang tertaut di sana untuk melakukan crash test dan tentukan apakah SSD berbohong tentang apakah penulisan dapat penyimpanan non-volatil. Jika ada kerugian, pertimbangkan untuk mengganti dengan SSD yang dikenal memiliki perlindungan kehilangan daya.

Sunting: Anda menambahkan detail yang menulis cache diaktifkan. Anda dapat mencoba menonaktifkannya: hdparm -W0 /dev/sdaatau perintah yang sesuai untuk larik perangkat keras. Referensi: Panduan administrasi penyimpanan RHEL .

Hambatan menulis sistem file memberlakukan urutan komitmen jurnal. Ini bukan jaminan data akan utuh, tetapi lebih aman untuk sistem file dengan cache volatil. Meskipun ini adalah default, menambahkan opsi mount "barrier" dengan jelas mendokumentasikan Anda menghargai konsistensi dibandingkan kinerja.

Akhirnya, garis pertahanan terakhir. Lakukan tes pemulihan untuk memastikan Anda bisa mendapatkan aplikasi dan database Anda ke titik waktu yang diinginkan. Ini berguna untuk semua jenis kehilangan data, bukan hanya kegagalan daya.