Комментарии 91
Бэкапы по правилу "3-2-1" - не помним. И держим резервные копии на SSD.
Да уж...
Тем более что RAID это скорее про доступность данных, а не надежность. В свое время софтверный RAID 1 умудрился все данные испортить после ребилда, при этом сами диски были в порядке. Хотя, казалось бы, что сложного в банальном зеркалировании данных...
Хотя, казалось бы, что сложного в банальном зеркалировании данных...
очевидно, сложно определить какая из копий сектора верна, в raid1 нет соответствующей метаинформации (и если её добавить, то это ×2 к iops на запись).
в этом плане zfs правильно устроена, там есть merkle tree, которое позволяет валидировать данные, в том числе и в случае «рассинхрона» зеркала.
И держим резервные копии на SSD.
скорее у автора статьи в голове каша, он не отличает резервные копии от raid
Любители подешевле так и не дали умереть этим бракоделам... а жаль... вот уж много лет как обхожу их стороной после жмени мёртвых флешек разных моделей
для меня как владельца HDD статейки про смерть SSD всегда повод для умиления и попкорна. Когда я предупреждал - все улыбались, теперь моя очередь улыбаться.
и Пы.Сы. - я не страдаю от низкой скорости считывания, я просто обхожу ее стороной и пользуюсь ОЗУ (у нее еще пока циклы бесплатные, капиталисты пока до этого момента еще не добрались, но и это ненадолго, ибо "бесплатная работа еще и без подписки" не дает спокойно спать ночами всяким маркетологам и спецам по запланированному устареванию).
Будто в прошивках HDD не бывает багов :)))
статейки про смерть SSD всегда повод для умиления
Вы не страдаете, но не значит, что остальным не нужны SSD. Плюс большинство статей прошлого касалось ограниченного ресурса ssd, связанного с их циклами перезаписи. А статья вообще о другом - о баге в прошивке. Точно такой-же баг мог в теории произойти и в HDD. Так-что это вообще не связанно с типом диска.
Пы.Сы. - я не страдаю от низкой скорости считывания и пользуюсь ОЗУ.
Вы не страдаете, а я страдаю. А как вы в ОЗУ игры храните например? Браузер долго запускается? Или вы просто не выключаете никогда никакие проги?
для меня как владельца HDD
Вы видимо не слышали про WD Green, которые парковали головки через 8 секунд бездействия, что в определённых моделях использования убивало диски за два-три года.
И таких примеров у разных производителей - море.
О да, и для отключения этой фичи они выпустили аж целую утилиту под дос, которую надо было как-то еще запустить.
А ещё были диски Fujitsu, у которых таблица ошибок smart из-за отсутствия проверки могла вылезти за отведённые границы и шла перезапись каких-то важных заводских настроек, после чего винт умирал.
Помню, когда покупал в 2002 свой первый комп, то все друзья говорили мне "главное, не купи Дятла! И вообще, ну его Айбиэм этот, бери лучше Сигейт". Так что удачи верующим)
Как раз после того купил Сигей с неправильно откалиброванным термодатчиком, он переставал писать во время работы. В гарантийку с таким дефектом его сдать не смог, так как там выполняли только тест чтения поверхности...
Еще фуджики с циррозом примерно в то же время были..
я не страдаю от низкой скорости считывания, я просто обхожу ее стороной и пользуюсь ОЗУ
Базу на десяток ТБ в памяти мне разместите пожалуйста
Ну запихайте несколько десятков терабайт логов в ОЗУ. Или базу схожего размера. Дома-то порнуху можно хоть на дискетах хранить, но мир не ограничен домашними ПК.
Запланированное устаревание? Осень интересно.
Во-первых, насколько я понял, речь в статье идёт об ошибке.
Во-вторых, запланированного устаревание -- это жупел сторонников теории заговора. Оглянувшись вокруг можно увидеть много вещей которые, отработали не то чтобы гарантийный срок, а больше чем запланированный срок службы. Где запланированое устаревание?
Во-вторых, запланированного устаревание -- это жупел сторонников теории заговора.
То, что кто-то что-то написал на Википедии не добавляет этому правдоподобности.
Большая часть сторонников теории запланированного устаревания не учитывает в своей логике следующего:
1) Сложность современной техники значительно превышает сложность техники 30-летней давности. И речь идёт не только про микроэлектронику, речь про почти любую отрасль. Если ранее в автомобиле гидроусилитель руля был опцией, то сейчас там программно-технический комплекс с ЭВМ производительностью большей, чем производительность мейнфрэйма из 90. Чем выше сложность - тем больше компонентов. Чем больше компонентов - тем выше вероятность отказа, ведь у нас цепи не дублирующие. В некоторых случаях, как например с ДВС, прогресс пошёл в сторону экстремального увеличения эффективности. И в итоге с 1 атмосферного литра стали снимать не 50 лошадей, а 100. И потреблять при этом не 10 литров на литр объёма, а 3-5.
2) Помимо "компонентов более высокого уровня" о которых говорится в процитированной вами статье, на конечную надёжность техники влияет ещё множество факторов. В первую очередь - сложность. Да и как вы схему не упрощайте, вероятность брака никто не отменял. В итоге общая надёжность изделия (которая, к слову, считается математически) изменится пренебрежительно мало. К слову, сейчас на Марсе летает "вертолёт", который по своей компонентной базе больше похож на модель с Алиэкспресс. И ничего. Поэтому бездумное неприменение компонентов высочайших отборок это не "запланированное устаревание", а абсолютно адекватное желание производителя не увеличивать цену в 2+ раза для уменьшения вероятности отказа на 0,1% в год.
3) Везде упоминаемый "заговор производителей ламп накаливания" и "раньше лампы были лучше" это не более чем технически безграмотная интерпретация научно-технического прогресса и улучшения потребительских свойств ламп. Потому что продолжительность свечения ламп накаливания можно было уменьшить и другими способами. А вот насколько пользователю необходима изначально менее эффективная лампа после того, как на её колбе изнутри распылился "килограмм фольфрама" - вопрос, на который ответа никто не даёт. Вы можете сами поискать "столетняя лампа", открыть фотографии и обнаружить что от вечной лампы накаливания толку (как от источника света) нет никакого, а экономический эффект отрицателен - ведь свет то она потребляет как нормальная. То есть производители обменялись патентами и действительно обнаружили, что слишком долго работающие лампочки невыгодны..... потребителю. То, что при этом они допустили картельный сговор и начали держать цены - уже другой вопрос.
Но иногда это всплывает, тот же залёт от корпорации Эпл с замедлением смартфонов или нюансы работы принтеров с критическими деталями из пластика.
Всплывает что?
Но иногда это всплывает, тот же залёт от корпорации Эпл с замедлением смартфонов
Перевожу на русский: компания ограничила производительность железа в зависимости от износа аккумулятора чтобы избежать ВНЕЗАПНОГО отключения телефона, резкого снижения срока автономной работы и перегрева из-за убитого аккумулятора. Это ограничение автоматически снималось с установкой нового аккумулятора.
Это чертовски хорошее инженерное решение, которое не всплыло бы на поверхность, если бы на старых телефонах не гоняли бенчмарки.
нюансы работы принтеров с критическими деталями из пластика
Которые всплывали где? В обычном домашнем использовании, когда пользователям надо распечатать не больше десяти листов в месяц в среднем? И этим самым пользователям, чтобы "запланированно не устареть" надо было поставить шестерни/валы из фрезерованной инструментальной стали? Ну не говоря уж про то, что эксплуатационные характеристики полимеров в определённых применениях могут быть катастрофически выше стальных. Например, пары трения металл/металл.
Я вам даже больше могу сказать, про "ужасные пластиковые детали": эндопротезы уходят с пар трения "металл-металл" на "металл-полиэтилен" потому что частота ревизирования этих самых "цельно металлических" эндопротезов значительно выше и побочек больше (в том числе из-за размеров частиц износа пар трения).
Более того, если бы те самые "критические детали" делали из менее металлического ЦАМ то эксплуатационные характеристики принтера были бы хуже.
Там скорее всего переполнение счётчика времени - упомянутое в статье число 32768 буквально кричит об этом. Не надо искать злой умысел там, где банальная безответственность.
Бекапы на SSD? Красиво жить не запретишь :)
Новости о багах прошивок в 2019 и 2020 годах прошли, по сути, незамеченными.
В стораджовом чате активно обсуждали, не знаю, для кого это прошло незамеченным
Когда упал основной сервер HN, нагрузку перевели на резервный — но он тоже упал.
Естественно, возникает вопрос, как у главного IT-сайта в мире могут возникнуть такие проблемы с бэкапами?
При чём тут вообще бекап?
На самом деле, на странице RAID в википедии есть короткий абзац, который выражает смысл этой статьи (помимо штуки с багом в прошивке):
Коррелированные сбои
Накопители в массиве, за исключением запасных («spare»), первое время часто имеют одинаковый возраст, подвергаются одинаковой нагрузке и воздействию окружающей среды, это нарушает предположения о независимой вероятности отказа дисков; сбои на самом деле статистически коррелированы. На практике шанс второго отказа перед первым восстановлением выше, чем вероятность случайных сбоев.
устал объяснять клиентам почему в зеркало лучше ставить диски из разных партий, а лучше разных производителей.. в итоге один напоролся на одновременно вышедшую из строя пару дисков (слава бг системных а не с данными) и заказывая замену сам попросил чтобы были из рахных партий.
А потом мы спрашиваем клиента — какая у него в голове модель максимальной проектной аварии? А у него нету. Или он говорит, что хочет защититься от всего. А когда считаешь ему стоимость правильного резерва с географически разделенными локациями, и проч — он не хочет платить. И так и работает на как-то собранном в raid сервере…
Второй вариант ответа — давайте возьмем сервис в облаке/датацентре, там все будет 100% надежно. Почему? А так в ролике в интернете сказали (специалисты же врать не будут ...) :-(
давайте возьмем сервис в облаке/датацентре, там все будет 100% надежно.
Обычно для облака указан процент доступности, и там нет указанной вами цифры.
Ну вообще так и есть, в среднем свой сервер + среднестатистический местный админ — это гораздо менее надёжная вещь, чем машина в облаке амазона.
В общем, безусловно — решение отдать сервер в облако меняет ландшафт рисков, но отнюдь их не устраняет.
И да, лучше всего работает локальный сервер с географически распределенным резервом и бэкапами (в то же облако). Но… денег же жалко, и экспертизы нет. А экспертизы нет, потому что всем жалко денег…
и отказались от экспертизы внутри компании,
Тут вон эксперт ниже спрашивает, что будет, если один диск отключить. И хоть вы зауправляйтесь своими рисками и сценариями, в среднем по больнице оно как-то так всегда и выглядит.
экспертиза внутри компании бывает плохая и может даже сделать еще хуже чем если ничего не делать
Один мой знакомый (c) после отказа одного диска (SCSI, ещё на 72GB) в RAID5 не придумал ничего умнее, чем погасить сервер и заменить диск в надежде, что "оно само сребилдится", после старта контроллер спросил, что делать с новым диском, и получив команду "добавить в массив", начал бодренький ребилд (часика на полтора), во время которого, ещё один из хардов сказал "ку!"... в общем, домой он добрался только к вечеру следующего дня, так и не сумев поднять базу ни с основного места размещения, ни из бэкапов (по классике, делавшихся на тот же массив)... зато после этого случая у него с резервированием данных стало значительно лучше.
Всю жизнь ставил зеркала из одинаковых дисков из одной партии из соображений того, чтоб диски были одинаковой скорости и объем до байтика сходился. И даже после выхода одного из дисков из строя менял сразу пару на опять же одинаковые. И только после этой статьи и комментариев до меня дошла пагубность данной практики, ведь зеркало создается не для "работы", а для "поломки". Век живи, век учись.
P.S. Правда пару раз попадал в небольшую неприятность когда приходилось менять один из пары на другую модель и вот там эти различия в пару байт мешали нормально восстановить md raid. Победить это не сложно или создавать изначально raid не на весь объем, но видимо тоже служило причиной использования абсолютно одинаковых дисков.
А как победить? Уменьшить ФС и RAID следом?
Когда я столкнулся с таким конфузом, у меня не вышло ничего, кроме следующего варианта - на новом диске создал новый рейд так, чтобы общий размер был чуть меньше диска. Потом перенос данных, потом подключение выжившего диска к новому. Увы, не самая быстрая операция.
Первые разы именно так и делал, по дороге вылезали какие-то проблемы, уже не вспомню какие, да и не быстро это было. Так что потом просто создавал на новой паре дисков рейд заново и копировал данные.
Почему-то в памяти сидит, что когда-то для RAID на HDD была обратная рекомендация – ставить одинаковые диски, мол, так быстродействие выше.
Таааак, и тут я захотел отключить на время один диск из софтового райда (через mdadm), а потом вернуть его в райд. Такое можно нормально сделать? Чтобы нормально потом синканулся райд.
Мне ещё ни разу не требовалось восстанавливать массив, но отключение диска "на время" мне видится равноценным ситуации "выхода диска из строя". Соответственно дальше у вас идут варианты в зависимости от типа массива, но в конечном итоге все равно нужно будет проводить процедуру восстановления массива.
Ну, разве что на обоих дисках данные останутся полностью неизменном виде.
Ну вот восстановление массива сложная операция вообще, если нет нагрузки на сервер?
Не могу ответить, пока ни разу не доводилось выполнять. Знаю только, что в этот момент нагрузка на диски крайне высока, и это опасный момент в плане того, что если вышел из строя один диск, и вы восстанавливаете структуру массива, есть риск выхода других дисков из строя из-за интенсивной нагрузки и, собственно, корреляции выше.
Почему крайне высокая?
В нормальном рейд контроллере можно выставить в процентах допустимую нагрузку для синхронизации дисков в массиве.
Вдобавок в рейде типа 10, выход из строя одного диска практически не влияет на производительность.
Итого, давим 5% мощности на синхронизаци. Нагрузка вырастет на не более чем 5%.
Повторюсь, не то чтобы я эксперт по рейдам, оперирую данными со всяких википедий.
В нормальном рейд контроллере можно выставить в процентах допустимую нагрузку для синхронизации дисков в массиве
У меня сформировалось ощущение, что аппаратными рейдами уже не пользуются в виду того, что те что на матери не очень, т.к. в случае чего, они не подхватятся в другой системе, а программный рейд можно спокойно переносить между аппаратурой. А внешние аппаратные в то же время дорогие, не давая каких-то мастхев фич. Возможно для корпоративных схд мои представления не верны.
Насчет крайне высокой, это я запомнил, когда про пятый рейд читал:
При выходе из строя одного диска надёжность тома сразу снижается до уровня RAID 0 с соответствующим количеством дисков n−1, то есть в n−1 раз ниже надёжности одного диска — данное состояние называется критическим (degrade или critical). Для возвращения массива к нормальной работе требуется длительный процесс восстановления, связанный с ощутимой потерей производительности и повышенным риском. В ходе восстановления (rebuild или reconstruction) контроллер осуществляет длительное интенсивное чтение, которое может спровоцировать выход из строя ещё одного или нескольких дисков массива. Кроме того, в ходе чтения могут выявляться ранее не обнаруженные сбои чтения в массивах cold data (данных, к которым не обращаются при обычной работе массива, архивные и малоактивные данные), препятствующие восстановлению. Если до полного восстановления массива произойдет выход из строя, или возникнет невосстановимая ошибка чтения хотя бы на ещё одном диске, то массив разрушается и данные на нём восстановлению обычными методами не подлежат.
Если до полного восстановления массива произойдет выход из строя, или возникнет невосстановимая ошибка чтения хотя бы на ещё одном диске, то массив разрушается
У нас в компании как раз такое и произошло несколько лет назад.
Данные восстановили. Правда за очень долгий срок, в далеко не полном объёме, и ОЧЕНЬ недёшево (сисадмин отправлял СХД в контору, специализирующуюся на такого рода вещах)
На СХД были пользовательские файлы, но самое главное - база данных MSSQL на пару терабайт. Базу, само собой, восстановить не вышло ((
я ставил тест на системе, аппаратный vs программный, ну вообщем аппаратный гораздо шустрее, точных цифр не помню, но до 5-10 раз, диски SATA-HDD. Крайний раз прислали сервер тоже уже с контроллером, но там все специфично.
ЗЫ может ли выйти 2 диска одновременно? запросто, поэтому я стал заводить raid6, ну кое-где и raid1, но дисков больше 2-х + желательно spare
Насчет крайне высокой, это я запомнил, когда про пятый рейд читал:
Так это относится собственно именно к пятому рейду. У него есть проблемы с перформансом, зато он гораздо дешевле, чем зеркало и может быть почти таким же быстрым, как райд1 по чтению, но с некоторой отказоустойчивостью. Ну или есть еще 6-й рейд.
Как раз проблемы пятого рейда хорошо решает внешний рейд со своим отдельным контроллером, рассчитанным на нагрузки, а не тот, что встроен в материнку.
Опять таки внешний рейд контроллер обычно используется не просто как еще одна плата в системнике, а к нему уже прилагается отдельная корзина на много дисков, плюс поддержка хотсвопа, хот спейр, собственного аккумулятора на случай пропадания питания, всякое такое.
Начнется rebuild массива, это значит, что с первого диска прочитаются ВСЕ данные, и запишутся на вставленный заново диск. mdraid понятия не имеет какие сектора с данными у вас изменились с момента отключения диска.
Если на рабочем диске, с которого будет чтение, найдутся bad-блоки, то raid не соберется.
В идеале вам нужен третий диск, который вставите вместо одного старого, на него и делайте rebuild.
В крайнем случае перед "операцией" можно сделать resync массива, который возможно найдет дефекты на дисках, если они есть.
Как-то на Хетцнере брали сервер с "зеркалом" на NVMe, так оно вместо заявленных 300ГБ было около 80ГБ, и никак не хотело расширяться - немало времени убил, разбирая и пересобирая софт-рэйд (правда, в Win Server), в попытках расширить раздел - из GUI ничего не сработало, а вот diskpart вполне успешно увидел несоответствие разметки и смог пересобрать "на всё место"... и да, ресинк проходил очень быстро, но практически без нагрузки, да и места занято было чуть.
Если Raid 1, то можно. Только если когда массив онлайн. Если отключить диск в офлайне, то при пуске массив не соберётся и станет поломанным Raid 0. При каждом пуске его придётся пересобирать вручную. Давняя проблема mdadm, но никого не волнует.
ZFS же запустится, но из офлайна запасные диски в используемые не перейдут. Только если какой-то диск пропал в онлайне, то spare диск перейдёт в inuse.
Понятно. Значит лучше не теребить мой raid1. Но там всё равно сервер для бэкапов, если он сдохнет, то на основной сервер это не повлияет. Только придётся бежать за новыми дисками.
Если вопрос изначально в том, чтобы разнести диски по времени использования - чтобы они не вышли из строя в один день, то я бы от себя посоветовал альтернативный вариант. Добавить третий диск - по вкусу в качестве рабочего или хотспара. Для паранойи лучше хотспар, конечно. И можно спокойно ждать выхода из строя.
Постоянно в офлайне отключаю.
А можно где-то посмотреть полный список SSD с этим багом?
Ну а практический вывод из этой истории такой, что в один RAID нежелательно ставить накопители одной модели, а тем более из одной партии (с серийными номерами подряд).Сколько помню, всегда как раз рекомендовалось использовать максимально одинаковые диски, чтобы избежать дисбаланса в параметрах чтения-записи и связанных с ним потерь производительности. Да ещё и покупать в запас для будущей замены, так как когда диск сдохнет, в продаже скорее всего уже не окажется такой модели.
Но проблема с одновременностью, конечно, имеется; вот и гадай теперь, как быть…
Но проблема с одновременностью, конечно, имеется; вот и гадай теперь, как быть…
Очень просто: скажем, каждые 3 месяца докупается один диск и меняется на один из тех, что был установлен в RAID'е с самого начала, и так -- пока не будет докуплено N - 1 дисков.
В результате, в RAID'е будут диски с "разбегом" в 3 месяца, а в запасе тоже будут диски, с частично отработанным ресурсом.
В дальнейшем, при выходе из строя дисков в RAID'е, логично будет заменять их на диски из запаса, выбирая такие из них, чтобы "разбег" по выработке ресурса дисков в RAID'е оставался относительно равномерным.
Риск того, что новые диски в самом начале массово начнут выходить из строя, невелик.
Да и никакие ухищрения при таком развитии событий не спасут.
Но чем дальше от момента создания RAID'а, тем диверсифицированнее при таком подходе становится защита от флеш-моба дискового "падежа".
За уменьшение риска в одном месте приходится платить увеличением рисков в другом, а именно, -- тем, что запасные диски могут оказаться и вовсе невостребованными.
Так что, ситуация описанная в посте вполне себе реальная, увы.
Вообще, об этой проблеме известно как минимум с 2019 года. Однако в то время мало кто обратил внимание на эту информацию…
Вообще о подобной проблеме известно как минимум с 2012 года, только в роли SanDisk был Crucial m4 и вместо 40 000 часов было 5200.
www.storagereview.com/news/crucial-m4-0309-firmware-update-for-5200-hour-bug-released
Не совпадает ли это магическое число с периодом гарантии?
Самый грубейший расчет показывает что это магическое число приблизительно совпадает не с гарантийным сроком, а с заявленным сроком службы:
43830 часов /24/365,25 = 5 лет (обычно такой срок указывают для "бытовых" SSD).
Тоже такая мысль посетила. Причём тут ещё в статье написано, что уже была проблема 32768 часов... Она, очевидно, была следствием переполнения. Почему оставили только двухбайтовое целое? Ответ может быть, что люди которые это делали, считали что их продукт помрëт раньше, чем двухбайтоаый счётчик переполнится... А при фиксе, кто-то решил вставить костыль со словами: , "Ну столько то уж это барахло точно не проживëт"... И 32768 превратилось в 40000. Что тут сказать, версия идиотическая, но тем хуже если окажется действительностью... Интересно, сколько часов туда зашил новый патч? Остаётся надеяться, что не 65535...
Лишь бы не 46340, которое приблизительно √2³¹ (из-за использования знакового 32-разрядного вместо беззнакового)
Мне кажется, специально гробить ссд нет смысла, они и так сами по себе потихоньку дохнут, если вы об этом. А вот как можно написать такую прошивку, в которой дохнет контроллер из-за какого-то сраного счётчика часов, причем без возможности восстановления (если я это правильно понял) — вопрос крайне интересный
Это не магическое число, на мой взгляд, а так называемое "запланированное устаревание", хотя я бы добавил великого рандома в "баг", чтобы оно не было столь очевидно.
....так, еще один повод проверить архивы резервных копий на разворачиваемость...а SanDisk расстроил, помню его как производителя твердотельных дисков еще с конца 90х, и казалось бы больших проблем не должно было быть, а оказалось что ошибка очень похожа на вышедший из под контроля или не отлаженный механизм устаревания. сомневаюсь что через 30 лет можно будет запустить какой нибудь современный накопитель, а вот старый MFM HDD на 20 МБ сейчас вполне запускается
помню его как производителя твердотельных дисков еще с конца 90х
Надеюсь, под "твердотельными дисками конца 90-х" Вы подразумеваете карты памяти CF, совместимые с PCMCI? А то мне до середины (конца) нулевых не припоминается ни одного коммерческого решения на "традиционных" SSD...
В начале 00-ых были так называемые DOM, совместимые с IDE (да, по сути "CF на стероидах").
Вполне себе твердотельные диски, контроллеры у них были не такие навороченные, как современные, но тем не менее...
подразумевал именно диски а не карты, -они тогда выпускались для шин ISA,PC104 и, как появился, на PCI, только ввиду дороговизны и тогда еще недостаточного объема применялись в промышленных, научных и военных
Ну, в принципе, "RAM-диск" можно считать "твердотельным накопителем", и впервые такое изделие в виде коробки размером с компьютерный блок питания, подключаемой к какому-то порту не IBM-PC-совместимого компьютера, я увидел ещё в детстве (где-то в середине 80-х), оно, правда, было не SanDisk, а Hitachi, и по понятным причинам, я не особо понимал, как оно работает, но усвоил, что это "вместо дискет, и работает быстрее". Внутри был свинцовый аккумулятор, похожий на современные, для ИБП, и куча плат с микросхемами - я как-то присутствовал при замене аккумулятора, а до этого видел, как на это устройство пишутся диаграммы с диагностического медицинского оборудования - я был сыном одного из сотрудников спорткомитета ЦСКА и часто проводил целые дни "на работе отца", докучая, в основном, медперсоналу.
Просто на современном обиходном языке термином "SSD" обычно называют накопители с интерфейсом SATA или SAS, выполненные в форм-факторе "HDD", а другие форм-факторы как-то отделяют (NVMe, MicroSD, USB-flash etc.), несмотря на то, что они, как и RAM-disk и даже MRAM, формально являются Solid-State Drive.
Мне, правда, интересно - не поделитесь ссылкой на SSD середины 90-х производства SanDisk?
Понравилось, что в статье описали этот фактор риска, который нельзя списывать со счетов. Однако, тут имхо налицо не проблема в ССД накопителях, а в неграмотной организации политики резервного копирования. По большому счёту, любое оборудование может поломаться в любой момент. Риски могут быть минимизированы организацией параллельных бэкапов в облако. Альтернативно, локальные бэкапы можно организовать на локальный NAS с HDD.
упс, не сюда
Если SSD умирают через 40 000 часов, то все бэкапы могут сгореть одновременно