Есть ли способ защитить SSD от повреждения из-за потери питания?

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

Я предполагал, что проблема будет просто в повреждении базы данных или в зашифрованных файлах с недавними изменениями, но есть и другие странные отчеты.

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

Есть проблемы с повреждением базы данных, но это то, что я мог ожидать. Больше всего меня удивляют более простые проблемы с файловой системой - например, права доступа или изменение файла в каталоге. Проблемы также возникают в файлах, которые не были изменены в последнее время (например, программный код и конфигурация).

Это "нормально" для коррупции 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 имеют два режима отказа:

• они теряют записи в полете и только в DRAM;
• они могут повредить любые данные в состоянии покоя, хранящиеся на нижней странице программируемой ячейки NAND.

Первое условие отказа очевидно: без защиты электропитания любые данные, которые находятся не в стабильном хранилище (то есть: непосредственно в NAND), а только в энергозависимом кеше (DRAM), будут потеряны. То же самое происходит с классическими механическими дисками (и это само по себе может нанести ущерб файловой системе, которая не выдает должным образом fsyncs).

Вторым условием сбоя является проблема MLC + SSD: при перепрограммировании старшего бита для хранения новых данных неожиданная потеря мощности может также разрушить / изменить младший бит (т. Е. Предыдущие зафиксированные данные).

Единственное верное и наиболее очевидное решение - это интегрировать кэш DRAM с защитой от потери мощности (обычно с использованием батарей / суперкапс), как это делалось всегда высокопроизводительными RAID-контроллерами; это, однако, увеличивает стоимость привода / цену. Потребительские накопители обычно не имеют защищенных кешей кэшей; скорее они используют множество более экономичных решений как:

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

Вернемся к вашему вопросу: ваши накопители Kingstone очень дешевые, используют неуказанный контроллер и практически не имеют публичных спецификаций. Меня не удивляет, что внезапная потеря питания испортила предыдущие данные. К сожалению, даже отключение кэш-памяти DRAM на диске (с большой потерей производительности, которой он командует) не решит вашу проблему, так как предыдущие данные (то есть: данные в состоянии покоя) могут и будут повреждены из-за необнаруженных потерь мощности. Если они основаны на старом контроллере Sandforce, при «правильных» обстоятельствах можно ожидать даже общий объем диска.

Я настоятельно рекомендую пересмотреть ваш ИБП и в среднесрочной перспективе заменить эти устаревшие накопители.

Последнее замечание о PostgreSQL и других базах данных Linux: они не будут отключать кэш диска и не должны быть защищены для этого. Скорее они используют периодические / необходимые fsyncs / FUA для фиксации ключевых данных в стабильном хранилище. Именно так все и должно быть сделано, если не существует очень веской причины (т. Е. Диска, связанного с ATA FLUSHES / FUA).

РЕДАКТИРОВАТЬ: если возможно, рассмотрите возможность перехода на файловую систему контрольной суммы как ZFS или BTRFS. По крайней мере, рассмотрим XFS, которая имеет контрольную сумму журнала и, в последнее время, даже контрольную сумму метаданных. Если вы вынуждены использовать EXT4, рассмотрите возможность включения auto-fsck при запуске (fsck.ext4 очень хорош в исправлении ошибок).

Да. Не покупайте сверхдорогие твердотельные накопители - все, что находится за пределами рынка потребительских товаров низкого уровня, имеет конденсаторы и полную защиту от потери мощности. Amd действительно не стоит так много больше.

Первое, что нужно сделать, это определить время восстановления и целевые точки восстановления. Как долго вы должны восстанавливать один из этих терминалов, и какой момент времени данных приемлем? Возможно, в течение пары часов вам понадобится восстановить резервную копию на прошлой неделе.

Все виды странных вещей могут произойти с файлами, если во время полета записи будут потеряны. Приоритет файловой системы - сохранение собственной согласованности метаданных, они могут не обеспечивать одинаковые гарантии для ваших данных. Другими словами, fsckне гарантируется восстановление ваших данных. Его задача - получить файловую систему, которая будет монтироваться.

Итак, сила. Установите, настройте и проверьте, что ИБП корректно выключит систему. Это позволяет кэшам файловой системы и самим дискам писать.

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

Изменить: вы добавили детали, что кеш записи был включен. Вы можете попытаться отключить это: hdparm -W0 /dev/sdaили соответствующую команду для аппаратного массива. Справка: руководство по администрированию хранилища RHEL .

Барьеры записи файловой системы обеспечивают порядок фиксации журнала. Это не гарантия того, что данные будут целы, но безопаснее для файловой системы с энергозависимым кешем. Хотя это значение по умолчанию, добавление опции «барьерного» монтирования четко документирует, что вы цените согласованность по сравнению с производительностью.

Наконец, последняя линия обороны. Проведите тест восстановления, чтобы убедиться, что вы можете получить приложение и базу данных в нужный момент времени. Это полезно для всех видов потери данных, а не только для сбоя питания.