Czy istnieje sposób ochrony dysku SSD przed uszkodzeniem spowodowanym utratą zasilania?

Mamy grupę terminali konsumenckich z zainstalowanym Linuksem, lokalnym serwerem WWW i PostgreSQL. Otrzymujemy raporty terenowe dotyczące maszyn z problemami, a po badaniu wydaje się, że nastąpiła przerwa w dostawie prądu, a teraz coś jest nie tak z dyskiem.

Zakładałem, że problemem będzie po prostu uszkodzenie bazy danych lub szyfrowanie plików z ostatnimi zmianami, ale są też inne dziwne raporty.

• pliki z niewłaściwymi uprawnieniami
• pliki, które stały się katalogami (na przykład index.phpjest teraz katalogiem)
• katalogi, które stały się plikami
• pliki z zaszyfrowanymi danymi

Istnieją problemy z uszkodzeniem bazy danych, ale tego mogę się spodziewać. Bardziej zaskakują mnie bardziej podstawowe problemy z systemem plików - na przykład uprawnienia lub zmiana pliku na katalog. Problemy występują również w plikach, które nie uległy ostatnio zmianie (na przykład kod oprogramowania i konfiguracja).

Czy to „normalne” w przypadku uszkodzenia dysku SSD? Początkowo sądziliśmy, że dzieje się to na niektórych tanich dyskach SSD, ale dzieje się tak pod marką (klasa konsumencka).

FWIW, nie wykonujemy autofsck na nieczystym rozruchu (nie wiem dlaczego - jestem nowy). Mamy UPS-y zainstalowane w niektórych lokalizacjach, ale czasem nie jest to zrobione poprawnie itp. To powinno zostać naprawione, ale nawet wtedy ludzie mogą wyłączyć terminal nieczysto itp. - więc nie jest to głupie. System plików to ext4.

Pytanie: czy jest coś, co możemy zrobić, aby złagodzić problem na poziomie systemu?

Znalazłem kilka artykułów dotyczących wyłączania pamięci podręcznej sprzętu lub montowania napędu w trybie synchronizacji, ale nie jestem pewien, czy to pomogłoby w tym przypadku (uszkodzenie metadanych i nie najnowsze zmiany). Przeczytałem również odniesienie do montowania systemu plików w trybie tylko do odczytu. Nie możemy tego zrobić, ponieważ musimy pisać, ale moglibyśmy utworzyć partycję tylko do odczytu dla kodu i konfiguracji, gdyby to pomogło.

To jest przykład dysku 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

W przypadku nagłej utraty zasilania dyski SSD MLC / TLC / QLC mają dwa tryby awarii:

• tracą podczas lotu i zapisują tylko w pamięci DRAM;
• mogą uszkodzić dowolne dane w spoczynku przechowywane na dolnej stronie programowanej komórki NAND.

Pierwszy stan awarii jest oczywisty: bez ochrony zasilania wszelkie dane, które nie są w stabilnej pamięci (tj. Sama NAND), ale tylko w pamięci podręcznej (DRAM), zostaną utracone. To samo dzieje się z klasycznymi dyskami mechanicznymi (i to samo może siać spustoszenie w systemie plików, który nie wydaje poprawnie fsyncs).

Drugi warunek awarii jest sprawa MLC SSD +: gdy przeprogramowanie trochę wysoki page do przechowywania nowych danych, nieoczekiwana utrata zasilania może zniszczyć / zmienić trochę niższe (tj: poprzednia zaangażowana danych) również.

Jedynym prawdziwym i najbardziej oczywistym rozwiązaniem jest integracja pamięci podręcznej DRAM chronionej przed utratą zasilania (zwykle przy użyciu baterii / superkaps), jak to robiono od zawsze przez wysokiej klasy kontrolery RAID; to jednak zwiększa koszt / cenę napędu. Dyski konsumenckie zwykle nie mają pamięci podręcznych chronionych przed utratą zasilania; zamiast tego używają szeregu bardziej ekonomicznych rozwiązań, takich jak:

• częściowo chroniona pamięć podręczna zapisu (tj .: Crucial M500 / M550 / M600 +);
• NAND zmienia dziennik (tj .: dyski Samsung, patrz atrybut SMART PoR);
• specjalne regiony SLC / pseudo-SLC NAND do wchłaniania nowych zapisów bez wcześniejszych danych zagrożonych (np .: Sandisk, Samsung itp.).

Wracając do pytania: dyski Kingstone są ultra-tanie, używają nieokreślonego kontrolera i zasadniczo nie mają publicznych specyfikacji. Nie dziwi mnie, że nagła utrata zasilania spowodowała uszkodzenie poprzednich danych. Niestety, nawet wyłączenie pamięci podręcznej DRAM dysku (z ogromną utratą wydajności, którą nakazuje) nie rozwiąże twojego problemu, ponieważ poprzednie dane (tj. Dane w spoczynku) mogą i zostaną uszkodzone przez nieoczekiwane straty mocy. Jeśli są one oparte na starym kontrolerze Sandforce, nawet w przypadku „właściwych” okoliczności można oczekiwać całkowitej klocka napędowego.

Zdecydowanie polecam przejrzeć UPS i, w perspektywie średnioterminowej, wymienić te starzejące się dyski.

Ostatnia uwaga na temat PostgreSQL i innych baz danych Linuksa: nie wyłączą pamięci podręcznej dysku i nie powinny tego robić. Raczej używają okresowych / wymaganych fsyncs / FUA, aby zatwierdzić kluczowe dane do stabilnego przechowywania. W ten sposób należy to robić, chyba że istnieje bardzo ważny powód (tj. Dysk, który kłamie na temat ATA FLUSHES / FUA).

EDYCJA: jeśli to możliwe, rozważ migrację do systemu plików sumowania kontrolnego jako ZFS lub BTRFS. Rozważ przynajmniej XFS, który ma sumę kontrolną dziennika, a ostatnio nawet sumę kontrolną metadanych. Jeśli jesteś zmuszony używać EXT4, rozważ włączenie auto-fsck podczas uruchamiania (fsck.ext4 jest bardzo dobry w naprawianiu uszkodzeń).

Tak. Nie kupuj super taniego dysku SSD - wszystko poza rynkiem konsumenckim ma kondensatory i pełną ochronę przed utratą zasilania. Amd naprawdę nie kosztuje dużo więcej.

Pierwszą rzeczą do zrobienia jest określenie czasu odzyskiwania i celów punktu odzyskiwania. Jak długo trzeba odzyskać jeden z tych terminali i jaki punkt danych w czasie jest akceptowalny? Być może w ciągu kilku godzin będziesz w stanie odzyskać dane z kopii zapasowej z zeszłego tygodnia.

W przypadku utraty zapisów w locie do plików mogą się przydarzyć różne dziwne rzeczy. Priorytetem systemu plików jest zachowanie własnej spójności metadanych, mogą one nie zapewniać takich samych gwarancji dla danych. Innymi słowy, fscknie ma gwarancji odzyskania danych. Jego zadaniem jest uzyskanie systemu plików, który zostanie zamontowany.

Więc moc. Zainstaluj, skonfiguruj i przetestuj, czy UPS zamknie system z wdziękiem. Umożliwia to zapisywanie w pamięci podręcznej systemu plików i samych napędów.

I trwałość zapisów na dyskach. Przeczytaj rozdział dotyczący niezawodności PostgreSQL . Użyj diskchecker.plskryptu, do którego tam jest link, aby wykonać test zderzeniowy i sprawdź, czy dyski SSD kłamią, jeśli zapisy dotarły do ​​nieulotnej pamięci. W przypadku utraty należy rozważyć wymianę na dyski SSD, o których wiadomo, że mają zabezpieczenie przed utratą zasilania.

Edycja: dodałeś szczegóły, że pamięć podręczna zapisu została włączona. Możesz spróbować wyłączyć to: hdparm -W0 /dev/sdalub odpowiednie polecenie dla tablicy sprzętowej. Odniesienie: Przewodnik administracji pamięcią RHEL .

Bariery zapisu w systemie plików wymuszają kolejność zatwierdzeń dziennika. Nie gwarantuje to, że dane pozostaną nienaruszone, ale jest bezpieczniejszy dla systemu plików z lotną pamięcią podręczną. Chociaż jest to ustawienie domyślne, dodanie opcji montowania „bariery” wyraźnie dokumentuje, że cenisz spójność w porównaniu z wydajnością.

Wreszcie ostatnia linia obrony. Wykonaj test przywracania, aby upewnić się, że możesz uzyskać aplikację i bazę danych w żądanym momencie. Jest to przydatne w przypadku wszystkich rodzajów utraty danych, a nie tylko awarii zasilania.