Чи є спосіб захистити SSD від корупції через втрату електроенергії?

У нас є група споживчих терміналів, на яких встановлений Linux, локальний веб-сервер та PostgreSQL. Ми отримуємо польові звіти про машини з проблемами, і після розслідування здається, що сталося відключення електроенергії, а з диском щось не так.

Я припускав, що проблема полягатиме лише в тому, що база даних пошкоджується, або файли з останніми змінами стають скрутними, але є й інші дивні звіти.

• файли з неправильними дозволами
• файли, які стали каталогами (наприклад, index.phpзараз це каталог)
• каталоги, які стали файлами
• файли із зашифрованими даними

Є проблеми з пошкодженням бази даних, але я можу очікувати цього. Що мене більше дивує, це більш основні проблеми файлової системи - наприклад, дозволи або зміна файлу в каталог. Проблеми трапляються також у файлах, які нещодавно не змінилися (наприклад, програмний код та конфігурація).

Це "нормально" для корупції SSD? Спочатку ми думали, що це відбувається на деяких дешевих SSD-дисках, але у нас це відбувається на найменуванні (бренд споживача.)

FWIW, ми не робимо autofsck під нечистим завантаженням (не знаю, чому я новачок). У нас встановлені ДБЖ в деяких місцях, але іноді це не робиться належним чином і т. Д. Це потрібно виправити, але навіть тоді люди можуть нечисто вимикати термінал і т. Д. - тож це не дурно. Файлова система 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). Те ж саме відбувається з класичними механічними дисками (і лише вони можуть спричинити хаос у файловій системі, яка не видає належним чином fsyncs).

Друга умова відмови - справа MLC + SSD: при перепрограмуванні біту високої сторінки для зберігання нових даних несподівана втрата електроенергії також може знищити / змінити нижній біт (тобто попередні скоєні дані).

Єдине вірне і найбільш очевидне рішення - інтегрувати захищений від втрат електроенергією кеш-пам'ять DRAM (як правило, використовуючи батарею / суперкап), як це робиться назавжди висококласними RAID-контролерами; це, однак, збільшує вартість / ціну приводу. Споживчі накопичувачі, як правило, не мають кешованих захищених втрат потужності; скоріше, вони використовують масив більш економічних рішень як:

• частково захищений кеш-запис (тобто: вирішальний M500 / M550 / M600 +);
• Журнал змін NAND (тобто: накопичувачі Samsung, див. Атрибут SMART PoR);
• спеціальні області SLC / pseudo-SLC NAND для поглинання нових записів без попередніх даних загрози (тобто: Sandisk, Samsung тощо).

Поверніться до свого запитання: ваші накопичувачі Kingstone - це наддешеві пристрої, що використовують не визначений контролер і, як правило, не публічні характеристики. Мене не дивує, що раптова втрата електроенергії пошкодила попередні дані. На жаль, навіть відключення кеш-пам’яті DRAM диска (з великою втратою продуктивності, яку він командує) не вирішить вашу проблему, оскільки попередні дані (тобто дані в стані спокою) можуть бути, і будуть пошкоджені несподіваними втратами електроенергії. Якщо вони базуються на старому контролері Sandforce, то при «правильних» обставинах можна очікувати навіть загальну цеглину приводу.

Я наполегливо пропоную переглянути Ваш ДБЖ та в середньостроковій перспективі замінити ці накопичувачі.

Остання примітка про PostgreSQL та інших базах даних Linux: вони не відключать кеш диска і не повинні бути вилучені для цього. Швидше, вони потребують періодичних / необхідних fsyncs / FUA, щоб ввести ключові дані для стабільного зберігання. Так потрібно робити, якщо не існує дуже вагомої причини (тобто: привід, який лежить про ATA FLUSHES / FUA).

EDIT: якщо можливо, розгляньте можливість переміщення до файлової системи контрольної суми як ZFS або BTRFS. По крайней мере, розглянемо XFS, в якому є контрольна сума журналів, а останнім часом навіть контрольна сума метаданих. Якщо ви змушені використовувати EXT4, подумайте про включення авто-fsck при запуску (fsck.ext4 дуже добре виправляє пошкодження).

Так. Не купуйте супердешевий SSD - все, що знаходиться поза споживчим ринком низького класу, має конденсатори та повний захист від втрати електроенергії. Amd дійсно не коштує так багато.

Перше, що потрібно зробити, це визначити час відновлення та цілі точки відновлення. Як довго вам потрібно відновити один з цих терміналів, і який момент часу прийнятний? Можливо, за пару годин вам потрібно буде відновитись до резервного копіювання минулого тижня.

З файлами можуть траплятися всілякі дивні речі, якщо під час запису польоту втрачено. Пріоритетом файлової системи є збереження власної узгодженості метаданих, вони можуть не надавати однакових гарантій для ваших даних. Іншими словами,fsck не гарантовано відновлення ваших даних. Його завдання - отримати вам файлову систему, яка буде монтуватися.

Отже, влада. Встановіть, налаштуйте та перевірте, що UPS витончено закриє систему. Це дозволяє кешувати файлові системи та самі диски записувати.

І, довговічність запису на диски. Прочитайте розділ надійності PostgreSQL . Використовуйте diskchecker.plскріплений там скрипт, щоб зробити тест на збій і визначити, чи брешуть SSD-диски, якщо записи потрапили в енергонезалежне сховище. Якщо є втрати, подумайте про заміну на SSD, які, як відомо, мають захист від втрати електроенергії.

Редагувати: ви додали дані, кеш запису ввімкнено. Ви можете спробувати відключити це: hdparm -W0 /dev/sdaабо відповідну команду для апаратного масиву. Довідка: Посібник з адміністрування зберігання RHEL .

Бар'єри для запису файлової системи виконують порядок здійснення журналу. Це не гарантія, що дані будуть недоторканими, але безпечніше для файлової системи з мінливим кешем. Хоча це і є за замовчуванням, додавання параметра "бар'єр" чітко підтверджує послідовність щодо продуктивності.

Нарешті, остання лінія оборони. Зробіть тест на відновлення, щоб переконатися, що ви зможете додати програму та базу даних до потрібного моменту. Це корисно для всіх видів втрати даних, а не лише відключення живлення.