Проблемы с дисками, восстановление данных, Жесткими, твердотельными, мягкотелыми, круглыми, квадратными Опции

[Hose]

Добрый вечер всем.я тут новенький,хотел бы у вас узнать есть ли какая то программа что может помочь мне в моей проблеме *???Я проверил программой свой винчестер Viktoria у меня нашел 217 оранжевых сектором а так же температура моего винчестера 48 градусов и еще,проверил другой программой "Hard Disk Sentinel"
тоже самое показало за температуру и написала вот такую ошибку..

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

Можно как то это решить вообще???эту проблему??

[Datarecover]

Намного проще.

Вот тебе вывод phison_flash_id:

да спасибо. Просто те утилиты что попадальсь раньше, полезными для восстановления не были и я пеерстал им уделять внимание. Да и в основном в доступе были утилиты тоько для UFD. А для починки дисков приходилось разбирать фирмварь.

Теперь - "долгое чтение". Оно бывает по двум причинам: утекший заряд в ячейках (дрянная память, или изношенная память, или долгое хранение при повышенной температуре, или активное чтение одного и того же места или комбинация перечисленного) - тогда флеш многократно читает страницу в надежде, что в какой-то из разов она прочитается так, что алгоритмы восстановления данных сумеют восстановить исходное ее содержимое, или - многократное обращение к всему массиву флеша с тем, чтобы найти нужную страницу ("безбуферный SSD", замученный транслятор). Что характерно - SE помогает при немедленной проверке чтения в обоих случаях: так как после SE читать из флеша ничего не нужно - то контроллер на запросы отплевывается нулями сразу же, с максимальной скоростью. Потому - чтобы понять, какой из этих двух вариантов имеет место быть, стоит после SE линейно прописать весь накопитель ненулевым паттерном (хотя бы тот же тест записи поверхности у AIDA), и дать ему полежать хоть несколько дней (если есть возможность положить в тепло - это будет еще надежнее). Если после такого выдерживания на графике чтения AIDA окажутся глубокие провалы (неглубокие - не в счет, они могут возникнуть по массе причин, например, при переписывании данных из SLC буфера в постоянное хранилище) - то скорее всего дело в флеше. Если же график чтения получится более или менее ровным - дело было в трансляторе.

полностью с этим согласен, и в общем именно исходя из похожей схемы я и делал выводы что проблема с чипами и как показывала практика иногда хватало просто пропаять чипы и это помогало , в принципе поэтому я и утверждаю что проблема в железе. И сейчас пропись патернами используется всеми около професиональными тулзами еще с моментов определения алгоритмов кодировния, а последние время это стало важно и для ХДД. И именно по этот алгритм я писал что определить чип не возможно. Хотя среднестатистический пользователь наверно не будет и паять чип. И спасибо за рекомендации аиды , а то я в основном людям совету всякие патерн райтеры или ртестер (со своими тестами) ну или на крайняк дисканализкр от которых пользователи пугаються и не доверяют их результатам.

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

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

Не встречал я пока такой стадии в SSD. Блок ушел на стирание, после стирания - проверка: стерся? - порядок, добавляем его в пул готовых к записи страниц, не стерся? - пробуем еще раз и опять проверяем, не получилось - объявляем мертвым. Проверка состояния всех бит блока после подачи на него стриающего импульса - это не "стадия принятия решения", а штатная часть процесса стирания.

ну так это и есть стадия заполнения Г листа , но она наступает для блоков которые ПОМЕЧЕНЫ для стирания, основной процес их не стирает а помечает. а пост процес стираетю На хдд это чуть иначе там основной процес осуществляет записи и\или чтение (для сигейта) и если сектор выщел за пределы по времени он уходит в пендинг лист и тем самым покинул зону трансляции , затем во время постпроцесса на него даеться несколько проверок и он помещаеться в Г-лист либо возвращается в резерв. ССД тоже используют основной поток работы и вторичный и основной поток не стирает данные а стираються они в доп потоке который я и назвала стадией принятия решений, ну пусть будет процесом стирания. Но в софте начинается гонка за ресурсами на уровне таблицы блоков помеченных для удаления , я понимаю что это можно расписать еще более подробно поключивши туда трим и шурфинг , но это работа штатная и она одинаково работает на одинаковой прошивке. Я иногда подбирал случайную запись при котрой эти тормоза становились заметны, хотя они уже проявляються на стадии выхода за пределы буфера, но не видел перманентного торможения (хотя наверно попробую создать такой тест) поэтому и относил это все к железу.

И еще, мне в основном уже доходят диски с явными проблемами, тк их уже часто смотрели ля меня , может по этому те что лечаться копированием просто не доходят.