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

15

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
Yehosef
źródło
5
Możesz kupić lepsze dyski SSD. Typowe dyski SSD dla przedsiębiorstw mają wbudowane kondensatory, które zapewniają wystarczającą moc urządzenia, aby zakończyć zapisywanie danych w locie w przypadku awarii zasilania. Pieniądze, które oszczędzasz, nie musząc odzyskiwać z całkowicie zakodowanego systemu plików, z łatwością uzasadnią skromne dodatkowe koszty.
Michael Hampton
1
Cóż, nikt nie powiedział, że musisz wymienić je wszystkie . Ale możesz użyć lepszych dysków SSD do wymiany i / lub nowych instalacji.
Michael Hampton
2
„Zastąpienie ich wszystkich nie jest proste” - całkowicie takie jest. Zacznij od poinformowania faceta o decyzji zakupu, że ponosi on koszty wynikające z rażącego zaniedbania i niekompetencji. Ktoś popełnił dość poważny błąd, nie będąc kompetentnym na granicy.
TomTom
7
WriteCache=enabled. To ogromny problem. Pamięć podręczna zapisu nigdy nie powinna być włączona na dyskach twardych z bazą danych. Niektórzy dostawcy, na przykład HP, faktycznie uniemożliwiają włączenie buforowania zapisu na dysku twardym z tego właśnie powodu.
Greg Askew
3
@ Yehosef pamiętaj, że wyłączenie buforowania zapisu w systemie operacyjnym nie naprawi faktu, że dysk powoduje uszkodzenie danych w przypadku utraty zasilania. Ze względu na większą szybkość i trwałość dyski SSD klasy konsumenckiej mogą nie zapisywać danych w nieulotnej pamięci podczas zapisywania do pliku, i niestety nie ma mechanizmu sprzętowego dla napędu, który przenosiłby dane z ulotnej pamięci podręcznej do pamięci trwałej na awaria zasilania, tylko korporacyjne dyski SSD mogą to zrobić. Wierzcie lub nie. Byłem w podobnej sytuacji, gdy ktoś kupił wiele dysków SSD konsumenckich, nasz dostawca, który zacytował ten sprzęt, nie miał pojęcia, że ​​tak się stanie.
jrh

Odpowiedzi:

14

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ń).

Shodanshok
źródło
Doskonała odpowiedź. Proszę zobaczyć moje powiązane pytanie serverfault.com/questions/924054 / ... - jeśli chcesz skopiować / dostosować tę odpowiedź, chętnie ją głosuję / ją wybiorę. Wygląda na to, że wyłączenie pamięci podręcznej zapisu pomogłoby tylko w pierwszym przypadku. Czy masz więcej szczegółów na temat drugiego trybu awarii? Czy jest to związane z przywracaniem równowagi / zbieraniem śmieci, czy po prostu bliskością?
Yehosef,
1
@Yehosef Daj spojrzeć tutaj, w „strat mocy” Section: anandtech.com/show/8528/...
shodanshok
1
Problem z jakimkolwiek rozwiązaniem programowym polega na tym, że wiele dysków SSD wprost kłamie systemowi operacyjnemu, czy dane są bezpiecznie przechowywane, czy nie, w tym w odpowiedzi na polecenia fsync / FUA. W przypadku dysków korporacyjnych, które mają wystarczającą ilość energii do ukończenia opróżniania pamięci podręcznej po odcięciu zasilania, nie stanowi to problemu.
BeowulfNode42
@ BeowulfNode42 Bariery ATA i FUA muszą być honorowane. Podczas gdy w dniach IDE / PATA niektóre fałszywe dyski były pofałdowane, obecnie każdy taki „kłamliwy” dysk nie jest zgodny z SATA / SAS i powinien natychmiast zostać odrzucony.
shodanshok
a mimo to te niezgodne dyski są i tak sprzedawane, szczególnie w segmencie rynku konsumenckiego.
BeowulfNode42
11

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.

TomTom
źródło
To są Kingston - więc nie wiem, czy są one uważane za tanie, czy też jest wadliwe. Większy problem polega na tym, że jednostki (~ 6k) są już w terenie i większość z nich nie zawodzi (być może dlatego, że nie ma strat mocy). Zastąpienie ich to kosztowna ostatnia deska ratunku, na którą jeszcze nie trafiliśmy.
Yehosef
dodano informacje o dysku do pytania.
Yehosef
5
Są super tanie. Są to dyski dla użytkowników końcowych zorientowane na cenę. Wyszukaj dyski dla małych przedsiębiorstw. PRZECZYTAJ SPECYFIKACJE. Zasadniczo ochrona przed awarią zasilania znajduje się w specyfikacji.
TomTom,
1
Aby dodać do @TomTom - czasami tak naprawdę nie nazywa się to ochroną przed awarią zasilania - a czasami ochrona przed awarią zasilania nie jest tak naprawdę ochroną przed awarią zasilania! Musisz przeczytać kilka artykułów dla każdego producenta i dowiedzieć się, jak to nazywają dla ich konkretnej marki dysków SSD dla przedsiębiorstw. (Look, dla każdego MFR, do białych ksiąg one zostały napisane w jaki sposób naprawdę wspaniały własne SSD są przedsiębiorstwa). I znalazłem, że przynajmniej dla pojedynczych zakupów, to robi koszt trochę więcej. Ale nie robię zakupów hurtowych i przypuszczam, że może być inaczej dla ilości 100 lub więcej.
davidbak
3
Z tego, co przeczytałem do tej pory, producenci ci mają nazwy dla tej funkcji: Kingston = „Pfail” jak w serii DC400; Samsung = „Zabezpieczenie przed utratą zasilania”; Intel = „Ulepszona ochrona danych przed utratą zasilania”; Sandisk = „Ochrona przed utratą danych z zabezpieczeniem przed awarią zasilania”. Nie wiem, jak nazywają to inni producenci, ale wymagana jest dogłębna lektura specyfikacji. Uwaga: można to również osiągnąć za pomocą oprogramowania układowego, jeśli producent je dostarczy. Jeśli naprawdę masz ich> 6000, skontaktuję się z Kingston i wyjaśnię sytuację oraz zaoferuję zapłacenie za oprogramowanie układowe za dysk.
BeowulfNode42
7

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.

John Mahowald
źródło
Prawdopodobną odpowiedzią jest buforowanie zapisu na dysku. Z jakiegoś nieznanego powodu wydaje się, że Postgres nie wyłącza buforowania zapisu na dysku, co jest okropnym ustawieniem domyślnym.
Greg Askew
1
Aby to wyjaśnić - mamy codzienne kopie zapasowe i synchronizujemy dane z chmurą, więc problem jest mniej związany z utratą danych Postgres (jest to problem, ale myślę, że są opcje konfiguracji PG, które mogą pomóc.) Bardziej niepokojącym problemem jest to, że maszyna staje się bezużyteczna w związku z dziwnością metadanych. FWIW, zwykle komputer uruchamia się i możemy się z nim połączyć, ale aplikacja nie działa, ponieważ jej pliki zostały zaszyfrowane.
Yehosef
1
„wygląda na to, że Postgres nie wyłącza buforowania zapisu na dysku, co jest okropnym ustawieniem domyślnym”. @GregAskew Demosntrate, jak wyłączyć pamięć podręczną DRAM na dysku SSD coimsumer. Nie można tego wyłączyć.
TomTom
4
Ze względu na sposób działania dysku SSD. Bez pamięci podręcznej wypaliłbyś SSD znacznie szybciej. Komórki SSD są duże i zawsze muszą być całkowicie zapisane - więc możliwość łączenia wielu małych zapisów jest kluczowa dla życia SSD. Dlatego NIE MOŻESZ go wyłączyć na dyskach konsumenckich (dyski leżą lub nie pozwalają na to) ORAZ nie można tego zrobić na dyskach korporacyjnych (dyski w zasadzie mogą leżeć, ponieważ są nielotne - mają wystarczającą rezerwę energii, aby napisać dram na flashowanie
TomTom,
3
@ Yehosef Nie, nawet niezawodny Postgres ma moc magiczną do odzyskania, jeśli wysłał dane na dysk, dysk mówi „Dobrze, mam twoje dane”, a wtedy dysk nigdy nie zaczął zapisywać tych danych z wewnętrznej tymczasowej niestabilności pamięć podręczna do rzeczywistej pamięci trwałej. Ważne jest, aby używać tylko pamięci masowej klasy korporacyjnej, w której napęd lub jednostka RAID ma wewnętrzną pamięć podręczną podtrzymywaną przez baterię lub kondensator. PostgreSQL posiada cechy (plik WAL, itp) w celu ochrony przed utratą danych nie zostały jeszcze wysłane do napędu, ale Postgres nie można odzyskać dane utracone wewnątrz napędu.
Basil Bourque,