SSD dahua не форматируется

[Teror]

Модель dahua c800as 500 гб

на коробки написано полная model: dhi-ssd-c800as500g

тип памяти 3d nand

надо восстановить данные если ли шанс или не стоит заворачиваться? кристал диск не видит, виктория видит его, смарт не считывается, из под винды если зайти в администрирование - управлении дискам видно два раздела по 200 гб если хочешь с ними сделать форматирование, удаление выдаётся ошибка

через новую версию виктори (которая работает с sdd) не определяется подробная информация о прошивке, модели и т д

R-Studio так же видит разделы и диск, но не может считать

я так понимаю нужна версия контролера накопителя пока не могу найти софт для определения, в тех характеристиках документации в к этому накопителю что находил в интернете про контролер не слова

[DVDshnik]

Форматировать диск и восстановить данные это суть абсолютно противоположные вещи. Однако, скорее всего диску пушистый зверёк пришёл как говорится.

[Teror]

Форматировать диск и восстановить данные это суть абсолютно противоположные вещи. Однако, скорее всего диску пушистый зверёк пришёл как говорится.
------- »
вообще главная цель восстановить данные частично, я раньше на hdd форматировал потом восстанавливал, может на ссд такой принцип не действует не знаю, пробовал 3 программы для определения контролера без результатно

[Teror]

вскрыл: два больших чипа вроде это банки памяти
1 чип
oenye1at3qaleeaacab
2215l127381
2 чип
oenye1a2t7qdleeaacab
2211k967931

тот что поменьше:
RayMX
rm1135
m120tp1 gm10aa
realtek

вроде это контролёр что последний, главное восстановить файлы с него хоть не все, часть

что то по поисковику новости не утешительные по этому контролеру...есть шансы хоть?

[Cereal Keeler]

Teror, у вас скорее всего слетела таблица FTL, иногда её получается восстановить инженерным софтом, подключением через JTAG, но это надо специальный внешний программатор и не везде работает. Так можно восстановить работоспособность девайса. А данным - гудбай. Если данные не резервировались заранее, то они априори не нужны. Такова селяви.

[Teror]

у вас скорее всего слетела таблица FTL, иногда её получается восстановить инженерным софтом, подключением через JTAG, но это надо специальный внешний программатор и не везде работает. Так можно восстановить работоспособность девайса. А данным - гудбай. Если данные не резервировались заранее, то они априори не нужны. Такова селяви »
я как понял данные по любому не восстановятся?


в сети искал инфу по этому контроллеру, я как понимаю там должна быть программа специальная для прошивки этого самого контролера....плюс программа должна поддерживать единовременно и саму память банки и сам контролер, но такой программы не существует или я не нашёл, в общем поддержки программы для прошивки самого контроллера не достаточно, надо чтобы она умела "видеть работать" и с памятью, то что я находил софт она не работает с памятью именно 3d nand, а если и найти правильный софт то данные не восстановить.....если что поправьте

[Avatar-Lion]

Teror, Любое ПО, которое предназначено для восстановления работоспособности SSD, автоматом после этого выполняет команду Secure Erase, т.е. обнуляет все ячейки памяти. Если данные реально важны, то несите накопитель в спец.фирму, которая умеет восстанавливать инфу с таких накопителей. Но учитывая ваши действия и сколько времени прошло, скорее всего, по факту там ничего уже не осталось из-за фоновой работы TRIM.

[Cereal Keeler]

я как понял данные по любому не восстановятся? »
Я ж сказал
А данным - гудбай. Если данные не резервировались заранее, то они априори не нужны. »

P.S. Если данные реально важны, например, вы имели несчастье хранить биткойновый кошелёк стоимостью в сотни тысяч настоящих денег на этом носителе, никуда не резервируя, тогда да, имеет смысл обратиться в
спец.фирму, которая умеет восстанавливать инфу с таких накопителей. »
Это может стоить сотни денег и результат не гарантируется. Иначе - нет смысла. И вбить в себе в глупую башку "я всегда буду резервировать данные".

[Teror]

Teror, Любое ПО, которое предназначено для восстановления работоспособности SSD, автоматом после этого выполняет команду Secure Erase, т.е. обнуляет все ячейки памяти. Если данные реально важны, то несите накопитель в спец.фирму, которая умеет восстанавливать инфу с таких накопителей. Но учитывая ваши действия и сколько времени прошло, скорее всего, по факту там ничего уже не осталось из-за фоновой работы TRIM. »
понятно значит всё ну всё теперь хоть на будущее знать

[dmitryst]

что то по поисковику новости не утешительные по этому контролеру...есть шансы хоть? »
На usbdev говорят, что нет прошивки на этот контроллер (май 2024г). Софта для прошивки, как пишут, тоже нет, но можно стандартным способом залить через JTAG. Но заливать нечего, так что... :dont-know

[Teror]

На usbdev говорят, что нет прошивки на этот контроллер (май 2024г). Софта для прошивки, как пишут, тоже нет, но можно стандартным способом залить через JTAG. Но заливать нечего, так что... »
спасибо, интересно а что за JTAG?

Это может стоить сотни денег и результат не гарантируется. Иначе - нет смысла. И вбить в себе в глупую башку "я всегда буду резервировать данные". »
понятно, на самом деле это не мой диск, я всегда всем говорю резервировать данные, но люди это понимают слишком поздно...с hdd я понял проще данные восстановить

Но учитывая ваши действия и сколько времени прошло, скорее всего, по факту там ничего уже не осталось из-за фоновой работы TRIM. »
я знаю про перезапись данных что если поверх записать то данные мало вероятно что восстановятся, но не знал что TRIM работает в фоне даже если диск " не активный"

[dmitryst]

интересно а что за JTAG? »
JTAG (https://habr.com/ru/articles/190012/)
hdd я понял проще данные восстановить »
так-то да, но есть нюансы, как говорится.

[Cereal Keeler]

так-то да, но есть нюансы, как говорится. »
Ага, SMR сложнее.
понятно, на самом деле это не мой диск, я всегда всем говорю резервировать данные, но люди это понимают слишком поздно... »
Кстати, наиболее приемлемую для большинства случаев стратегию резервирования 3-2-1 разработал не инженер, не админ, а профессиональный фотограф, потерявший свои фоточки. Он прошёл по граблям, сделал выводы и разработал стратегию, чтобы это не делать другим, но как говорится, пока жареный петух не придёт по лично твою задницу...

3 - иметь как минимум 3 копии важных данных
2 - использовать как минимум 2 разных физических хранилища данных для разных копий. Пример - один набор копий хранить на одном жёстком диске, другой - на другом.
1 - как мимнимум одна из копий должна быть offsite, то есть храниться в другом помещении/городе/стране. Проще и дешевле всего для этого арендовать облачное хранилище.

3-2-1 не покрывает вопросы RPO (Recovery Point Objective) и RTO (Recovery Time Objective), но для большинства домашних пользователей они и не критичны.
я знаю про перезапись данных что если поверх записать то данные мало вероятно что восстановятся, но не знал что TRIM работает в фоне даже если диск " не активный" »
Тут немного не так. TRIM это команда от хоста произвести "уборку". Но "уборку" (Garbage Collection, GC) время от времени проделывает и сам накопитель, вернее, его контроллер, для чего достаточно чтобы он был просто запитан, даже не подключен.

Вообще по идее при сбоях контроллер должен перевести накопитель в режим только для чтения, как раз на случай, если данные нужно с него восстановить, но то зависит от контроллера и его прошивки, в которых бывают ошибки. Не было б ошибок, не было б и катастрофических сбоев – ни разу не видел SSD, который бы умер от износа, все пациенты откисали из-за глюков.

[dmitryst]

пациенты откисали из-за глюков. »
самое обидное, что после перепрошивки они могут работать годами. У самого лежит парочка таких.

[Cereal Keeler]

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

[Teror]

Вообще по идее при сбоях контроллер должен перевести накопитель в режим только для чтения, как раз на случай, если данные нужно с него восстановить, но то зависит от контроллера и его прошивки, в которых бывают ошибки. Не было б ошибок, не было б и катастрофических сбоев – ни разу не видел SSD, который бы умер от износа, все пациенты откисали из-за глюков. »
а это правда что сбои на ssd чаще всего "виновата служебная область"? либо сама прошивка контролера слетает

цитата

Почему SSD выходят из строя, если в SMART всё хорошо

Казалось бы, даже 20-30 циклов перезаписи – вполне приличная цифра, а уж 1000-1500 – и вовсе величина, для обычного пользователя запредельная. Если умножить на ёмкость накопителя в 512 ГБ, на него нужно записать 10-15 ТБ до того, как начнётся хоть сколько-нибудь заметная деградация ячеек. Если же брать цифру производителя, то данные и вовсе можно писать сплошным потоком в течение многих лет. Однако даже с учетом использования специальных алгоритмов «равномерности записи», проблемы наступают гораздо раньше.

Узким местом каждого накопителя является так называемая служебная область. Служебная область – это ограниченная фиксированная область, выделенная для хранения прошивки (управляющей микропрограммы) и служебных структур. Эта область постоянна и имеет ёмкость порядка 4-12 Гбайт. В ней хранятся все служебные структуры — модули (таблицы переназначенных блоков, части микрокода, отвечающие за хранение пароля, атрибуты SMART и т.д.)

Проблема же в том, что каждый раз при записи информации в доступной пользователю части накопителя меняются и служебные структуры, отвечающие за информирование контроллера о переводе физических блоков в логические. В зависимости от характера использования накопителя (запись последовательности данных большим куском или множества мелких операций записи) нагрузка на служебную зону, находящуюся по фиксированному адресу, может существенно вырасти. Для служебной зоны не работают алгоритмы равномерности записи (wear levelling); она не может быть переадресована при износе ячеек.

В результате в определённых сценариях использования (к примеру, SSD используется для активной работы базы данных с огромным числом транзакций, которые изменяют буквально несколько байт данных – но перезаписывают всё равно целый блок) уже через несколько месяцев (а не лет!) современные SSD начинают приходить в негодность. Закончиться всё может печально: совершенно неожиданно, при отличных показателях диагностики SMART и параметре износа порядка единиц процентов («оставшийся ресурс: 99%») SSD может просто пропасть из системы. Связано это с тем, что количество неисправных ячеек в служебной области увеличивается настолько, то коды ЕСС коррекции контроллера уже не могут их скорректировать, и SSD прекращает определяться в BIOS или показывать полную емкость.

Происходит следующий циклический процесс. Контроллер подгружает микропрограмму с NAND микросхем; микропрограмма содержит критическое количество ошибок; контроллер получает ошибку о невозможности считать микропрограмму; контроллер пробует прочитать ее снова и подгрузить в ОЗУ; снова получает ошибку; и так до бесконечности.

Как правило, наиболее частой неисправностью является выход из строя самого важного модуля – «транслятора», который транслирует адреса физических блоков в логические. С точки зрения пользователя это может выглядеть как катастрофическое падение определяемой ёмкости накопителя – к примеру, видны 2 МБ или 980 МБ вместо полноценных 512 ГБ.

[Cereal Keeler]

а это правда что сбои на ssd чаще всего "виновата служебная область"? либо сама прошивка контролера слетает »
Очень упрощённо и большей частью неверно. Слетает не сама прошивка, а FTL - Flash Translation Layer, таблица, сопоставляющая адреса LBA физическим адресам в NAND. А прошивка при невозможности считать FTL переходит в аварийное состояние, диск не работает.

Проблема хранения FTL действительно сложна и интересна. Хоть её размер относительно невелик, порядка десятков мегабайт, но туда действительно много пишется, читается и сбой FTL = безвовзвратная потеря даных. То есть, данные никуда не деваются, но найти их не представляется возможным. При выравнивании износа, уборке мусора, FTL тоже должна обновляться, так как меняется физическое расположение данных в NAND. В ход идут разные ухищрения, вроде журналов, циклического перемещения служебной области по мере записи и т.п. В общем, утверждать про какую-то фиксированную "служебную область", износ в которой вызывает сбой FTL, я бы не стал. Ещё, для снижения нагрузки эта таблица мапится в DRAM память, либо на самом диске, либо в DMA хоста в случае безбуферников, но тут возникает проблема, что делать в случае сбоев, например, питания. И там тоже идут в ход ухищрения, вроде конденсаторов, обеспечивающих работу контроллера в случае пропажи питания, на миллисекунды, чтобы успеть дописать.

Всё очень сложно, неудивительно, что сбои не редкость и они вовсе не обязательно связаны с износом какой-то "служебной области". Тем более, что после попытки перепрошивки сбойного диска тот часто продолжает работать как ни в чём ни бывало. Будь фиксированная служебная область у таких экземпляров ушатана в ноль, восстановить работоспособность не получалось бы.

Усугубляет и то, что имплементации этого всего разные в разных контроллерах, алгоритмы работы и их реализации - где и как хранится FTL, как обеспечивается защита от сбоев - представляют собой коммерческую тайну, потому подробной инфы в открытом доступе просто нет.

[Teror]

Очень упрощённо и большей частью неверно. Слетает не сама прошивка, а FTL - Flash Translation Layer, таблица, сопоставляющая адреса LBA физическим адресам в NAND. А прошивка при невозможности считать FTL переходит в аварийное состояние, диск не работает.
Проблема хранения FTL действительно сложна и интересна. Хоть её размер относительно невелик, порядка десятков мегабайт, но туда действительно много пишется, читается и сбой FTL = безвовзвратная потеря даных. То есть, данные никуда не деваются, но найти их не представляется возможным. При выравнивании износа, уборке мусора, FTL тоже должна обновляться, так как меняется физическое расположение данных в NAND. В ход идут разные ухищрения, вроде журналов, циклического перемещения служебной области по мере записи и т.п. В общем, утверждать про какую-то фиксированную "служебную область", износ в которой вызывает сбой FTL, я бы не стал. Ещё, для снижения нагрузки эта таблица мапится в DRAM память, либо на самом диске, либо в DMA хоста в случае безбуферников, но тут возникает проблема, что делать в случае сбоев, например, питания. И там тоже идут в ход ухищрения, вроде конденсаторов, обеспечивающих работу контроллера в случае пропажи питания, на миллисекунды, чтобы успеть дописать.
Всё очень сложно, неудивительно, что сбои не редкость и они вовсе не обязательно связаны с износом какой-то "служебной области". Тем более, что после попытки перепрошивки сбойного диска тот часто продолжает работать как ни в чём ни бывало. Будь фиксированная служебная область у таких экземпляров ушатана в ноль, восстановить работоспособность не получалось бы.
Усугубляет и то, что имплементации этого всего разные в разных контроллерах, алгоритмы работы и их реализации - где и как хранится FTL, как обеспечивается защита от сбоев - представляют собой коммерческую тайну, потому подробной инфы в открытом доступе просто нет. »
интересно, а какая тип памяти по вашему самая лучшая ? когда брать ссд придётся чтобы знать на что ориентироваться

[Cereal Keeler]

интересно, а какая тип памяти по вашему самая лучшая ? »
В смысле какая? SLC, MLC, TLC, QLC? Первые две давно практически не доступны на потребительском рынке, TLC лучше QLC, но дороже в пересчёте на единицу хранения.
когда брать ссд придётся чтобы знать на что ориентироваться »
О конкретных производителях и моделях флеш-памяти нет смысла говорить - производители ссд используемые модели не указывают, максимум тип - TLC или QLC, а также меняют применяемые чипы памяти, тоже не удосуживаясь об этом никого уведомлять. К примеру, читаете вы обзор годовой давности какого-нибудь ссд, там пишут, что используется 64-слойная TLC от Micron. Покупаете его, а там 96-слойный Hynix. Такое сейчас норма. Узнать, какая конкретно память тебе досталась, можно только после покупки, либо при визуальном осмотре, либо посредством специального ПО.