SSD'yi güç kaybı nedeniyle bozulmaya karşı korumanın bir yolu var mı?

Linux, yerel bir web sunucusu ve PostgreSQL'in kurulu olduğu bir grup tüketici terminalimiz var. Sorunlu makinelerin saha raporlarını alıyoruz ve soruşturma üzerine bir elektrik kesintisi varmış gibi görünüyor ve şimdi diskte bir sorun var.

Sorunun sadece veritabanı bozulması veya son değişikliklerin karıştırılması ile ilgili olacağını varsaymıştım, ancak başka garip raporlar var.

• yanlış izinlere sahip dosyalar
• dizin haline gelen dosyalar (örneğin, index.phpartık bir dizin)
• dosya haline gelen dizinler
• şifrelenmiş veriler içeren dosyalar

Veritabanının bozulmasıyla ilgili sorunlar var, ancak bu beklediğim bir şey. Daha fazla şaşırdığım şey daha temel dosya sistemi sorunlarıdır - örneğin, izinler veya bir dosyayı dizine değiştirmek. Sorunlar son zamanlarda değişmeyen dosyalarda da meydana geliyor (örneğin, yazılım kodu ve yapılandırması).

SSD bozulması için bu "normal" midir? Başlangıçta bazı ucuz SSD'lerde olduğunu düşündük, ancak bunu bir markada (tüketici sınıfı) yapıyoruz.

FWIW, kirli önyüklemede autofsck yapmıyoruz (neden bilmiyorum- yeniyim). Bazı yerlerde UPS'ler kurulur, ancak bazen düzgün yapılmaz, vb. Bu düzeltilmelidir, ancak o zaman bile insanlar terminali temiz bir şekilde kapatabilir, vb. Dosya sistemi ext4'tür.

Soru: Sistem seviyesinde sorunu hafifletmek için yapabileceğimiz bir şey var mı?

Donanım önbelleğini kapatmaya veya sürücüyü senkronizasyon modunda monte etmeye ilişkin bazı makaleler buldum, ancak bu durumda yardımcı olup olmayacağından emin değilim (meta veri bozulması ve yakın zamanda yapılmayan değişiklikler). Ayrıca, dosya sistemini salt okunur modda bağlama hakkında bir başvuru da okudum. Bunu yapamayız çünkü yazmamız gerekiyor, ancak yardımcı olursa kod ve yapılandırma için salt okunur bir bölüm oluşturabiliriz.

Bu bir sürücü örneğidir 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

Aniden güç kaybederken, MLC / TLC / QLC SSD'lerin iki arıza modu vardır:

• uçuş sırasında ve yalnızca DRAM içinde yazıyorlar;
• programlanmakta olan NAND hücresinin alt sayfasında depolanan herhangi bir veriyi bozabilirler.

İlk arıza durumu açıktır: güç koruması olmadan, kararlı depolamada olmayan (yani: NAND'ın kendisi) ancak yalnızca geçici önbellekteki (DRAM) veriler kaybolacaktır. Aynı şey klasik mekanik diskler için de geçerlidir (ve tek başına fsyncs'i düzgün bir şekilde vermeyen dosya sisteminde tahribat yaratabilir).

İkinci arıza koşulu bir MLC + SSD olayıdır: yeni verileri depolamak için yüksek sayfa bitini yeniden programlarken, beklenmedik bir güç kaybı da düşük biti yok edebilir / değiştirebilir (yani önceki işlenmiş veriler).

Tek doğru ve en belirgin çözüm, sonsuza kadar üst düzey RAID denetleyicileri tarafından yapıldığı gibi, güç kaybına karşı korumalı bir DRAM önbelleğini (genellikle pil / süper başlıklar kullanarak) entegre etmektir; ancak bu, sürücü maliyetini / fiyatını artırır. Tüketici sürücülerinde genellikle güç kaybı korumalı önbellekler yoktur; bunun yerine, bir dizi daha ekonomik çözüm kullanırlar:

• kısmen korunan yazma önbelleği (yani: Crucial M500 / M550 / M600 +);
• NAND günlüğü değiştirir (yani: Samsung sürücüler, bkz. SMART PoR özelliği);
• Daha önce risk altında veri olmadan yeni yazmaların emilmesi için özel SLC / sözde SLC NAND bölgeleri (ör: Sandisk, Samsung, vb.).

Sorunuza geri dönün: Kingstone diskleriniz, belirtilmemiş denetleyici kullanan ve temelde hiçbir kamuya açık özellik olmayan ultra ucuz sürücülerdir. Ani bir güç kaybının önceki verileri bozması beni şaşırtmıyor. Ne yazık ki, diskin DRAM önbelleğini devre dışı bırakmak (büyük performans kaybıyla komutları) bile , önceki veriler (yani, beklemedeki veriler) beklenmedik güç kayıpları tarafından bozulabileceği ve bozulacağı için sorununuzu çözmez. Eski Sandforce kontrolörüne dayanıyorsa, "doğru" koşullar altında toplam bir tahrik tuğlası bile beklenebilir.

Kesinlikle UPS'inizi gözden geçirmenizi ve orta vadede bu eskime sürücülerini değiştirmenizi öneririm.

PostgreSQL ve diğer Linux veritabanları hakkında bir son not: onlar olacak değil diskin önbelleği devre dışı bırakmak ve gerektiği değil bunu yapmak için exptected edilecek. Daha ziyade, önemli verileri kararlı depolamaya adamak için periyodik / gerekli fsyncs / FUA'lar kullanırlar. Çok zorlayıcı bir neden olmadığı sürece işlerin böyle yapılması gerekir (örneğin: ATA FLUSHES / FUA'lar hakkında yatan bir tahrik).

EDIT: mümkünse, bir sağlama toplamı dosya sistemine ZFS veya BTRFS olarak geçiş yapmayı düşünün. En azından dergi sağlama toplamı ve son zamanlarda meta veri sağlama toplamı olan XFS'yi düşünün. EXT4 kullanmak zorunda kalırsanız, başlangıçta auto-fsck'i etkinleştirmeyi düşünün (fsck.ext4 onarım bozulması için çok iyidir).

Evet. Süper ucuz SSD almayın - düşük son tüketici pazarının dışındaki herhangi bir şey kapasitörlere ve güç kaybına karşı tam korumaya sahiptir. Amd gerçekten çok daha pahalı değil.

Yapılacak ilk şey, toparlanma süresi ve toparlanma noktası hedeflerini tanımlamaktır. Bu terminallerden birini ne kadar sürede kurtarmanız gerekiyor ve hangi veri noktası kabul edilebilir? Belki birkaç saat içinde geçen haftanın yedeklemesini geri kazanabilmeniz gerekir.

Uçuş yazılarında kaybolursa, dosyalara her türlü garip şey olabilir. Dosya sistemi önceliği kendi meta veri tutarlılığını korur, verileriniz için aynı garantileri sağlamayabilir. Başka bir deyişle, fsckverilerinizi kurtarmanız garanti edilmez. Görevi size bağlanacak bir dosya sistemi elde etmektir.

Yani, güç. UPS'nin sistemi zarif bir şekilde kapatacağını kurun, yapılandırın ve test edin. Bu, dosya sistemi önbellekleri ve sürücülerin kendilerinin yazmasına olanak tanır.

Ve yazıların disklere dayanıklılığı. PostgreSQL'in güvenilirlik bölümünü okuyun . diskchecker.plÇarpışma testi yapmak için oraya bağlı komut dosyasını kullanın ve SSD'lerin yazma işlemlerinin kalıcı depolama alanına girip girmediğini belirleyin. Kayıp varsa, güç kaybı korumasına sahip olduğu bilinen SSD'lerle değiştirmeyi düşünün.

Düzenle: yazma önbelleğinin etkinleştirildiği ayrıntıları eklediniz. Bunu devre dışı bırakmayı deneyebilirsiniz: hdparm -W0 /dev/sdaveya bir donanım dizisi için uygun komutu. Referans: RHEL depolama yönetim kılavuzu .

Dosya sistemi yazma engelleri, dergi taahhütlerinin uygulanmasını zorunlu kılar. Verilerin sağlam olacağını garanti etmez, ancak geçici bir önbellek içeren dosya sistemi için daha güvenlidir. Varsayılan olsa da, "bariyer" montaj seçeneği eklediğinizde performans tutarlılığına değer verdiğinizi açıkça belgelersiniz.

Son olarak, son savunma hattı. Uygulamanızı ve veritabanınızı istediğiniz zaman elde edebileceğinizden emin olmak için bir geri yükleme testi yapın. Bu, sadece elektrik kesintisi için değil, her türlü veri kaybı için kullanışlıdır.