Перейти из форума на сайт.

НовостиФайловые архивы
ПоискАктивные темыТоп лист
ПравилаКто в on-line?
Вход Забыли пароль? Первый раз на этом сайте? Регистрация
Компьютерный форум Ru.Board » Hardware » Магнитные носители информации » Восстановление разделов и информации на HDD (часть 8)

Модерирует : Akam1, Dr_StandBy, vertex4

Akam1 (13-11-2016 05:23): http://forum.ru-board.com/topic.cgi?forum=84&topic=5216  Версия для печати • ПодписатьсяДобавить в закладки
Страницы: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100

   

Akam1



Комса
Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору
Восстановление разделов и информации на HDD
 
1 часть :: 2 часть :: 3 часть:: 4 часть :: 5 часть :: 6 часть :: 7 часть

Внимание! Если у Вас возникли проблемы с доступом к информации на дисках большого объема (более 120 Гб) - пропала таблица разделов, система говорит, что нужно отформатировать диск и т.п., то сначала прочитайте эту ветку про LBA48.
 
Для операций с разделами на жестких дисках по-возможности используйте штатные средства ОС. Прежде, чем править разделы с помощью Acronis Partition Expert, Norton Partition Magic и им подобных программ, пробегите быстро по всем страницам всех частей этой темы и Вы увидите, что половина проблем из-за них! Если не хотите сами наступить на эти грабли, запомните несколько простых правил:
 
- перед использованием программ типа Partition Magic всегда сохраняйте резервные копии важных данных
- не забывайте проверять диски на ошибки и дефрагментировать их (может помочь позже, при восстановлении данных)
- не пытайтесь изменять разделы на дисках с ошибками или на которых имеются сбойные блоки
- на время правки разделов постарайтесь обеспечить бесперебойную работу компьютера
- никогда не прерывайте процесс изменения разделов, если он уже начался
- не проводите операций по изменению разделов на дисках забитых до отказа, т.к. это значительно увеличивает продолжительность таких операций, а следовательно и риск возникновения сбоев
 
Прочтите и передайте другим, которые заходят сюда, когда уже слишком поздно...

 
То же самое касается программ ScanDisk и CHKDSK, автоматически проверяющих диски при загрузке системы. В случае серьезных сбоев они ничем помочь не смогут, но навредить могут изрядно. Поэтому всегда отключайте эти утилиты из автозапуска и выполняйте проверку дисков только вручную, периодически, когда уверены, что серьезных проблем на диске нет. Как их отключить написано здесь (на английском)

  • Общие рекомендации по самостоятельному восстановлению данных
     
  • Хороший совет по восстановлению, когда не уверен в своих знаниях
     
  • Список программ для восстановления информации
     
  • Статьи о восстановлении данных и жестких дисках
     
  • Восстановление данных из .chk файлов
    Обращаясь в тему за помощью, обязательно укажите информацию о диске: тип, емкость, способ подключения, информацию о разделах, SMART винта из MHDD / Victoria / HDDScan, наименование и мощность БП, возраст БП, результаты MemTest86, версию ОС и сервис-пака, а также обстоятельства краха - честное слово, толковым запросам и отвечать приятно. Здесь телепатов нет...
     

    Важно! Инструкция по чистке контактов на плате HDD

  • Всего записей: 26360 | Зарегистр. 20-04-2006 | Отправлено: 05:45 11-10-2015
    acrid2

    Newbie
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    Подробнее...
     
    в общем, как я понял, там все настолько перемешалось, что восстановить если и возможно, то явно не самому, а везти куда-то этот диск смысла нет... Спасибо за попытку помочь! [/more]

    Всего записей: 25 | Зарегистр. 08-02-2016 | Отправлено: 02:28 10-02-2016 | Исправлено: acrid2, 02:37 10-02-2016
    temp9285

    BANNED
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    acrid2
    Если папки, файлы находятся хитманом, то они должны быть и в DMDE - удалённые или найденные, в руте или в папке Все найденные + реконструкция.

    Всего записей: 1369 | Зарегистр. 07-11-2015 | Отправлено: 02:37 10-02-2016
    acrid2

    Newbie
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

    Цитата:
    Если папки, файлы находятся хитманом, то они должны быть и в DMDE - удалённые или найденные, в руте или в папке Все найденные + реконструкция.

     
    да, есть там эти папки. Вот они:
    http://s017.radikal.ru/i435/1602/ef/6de181112a6c.jpg

    Всего записей: 25 | Зарегистр. 08-02-2016 | Отправлено: 02:41 10-02-2016
    temp9285

    BANNED
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    acrid2
    Насколько понял - папки пустые или в них мало (мелких?) файлов?
    Если учесть что дата MFT - октябрь 2014 года, не удивлюсь ели подтвердится что бывший хозяин форматнул раздел.

    Всего записей: 1369 | Зарегистр. 07-11-2015 | Отправлено: 02:55 10-02-2016
    avtandil33

    Newbie
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    temp9285
     
    Цитата:
    вот у меня в папке 0Huis еще была подпапка Gruz2016, а  в ней еще несколько подпапок с данными.
     

    Цитата:
    Можно увидеть что в логе по поводу этих папок?

     
    Checkdisk log. В файле 7.txt - отфильтрованные по именам файлов записи из этого лога. Но опять-таки повторюсь, что они тут не все, так нет ни одной из подпапок 0Huis\Gruz2016. Суды по всему и остальные подпапки из 0Huis, такие как ac , Bounces, Metelkin,Mix ,Pics безвестно канули. Что интересно у них у всех стоит чекдисковская метка - файл  113424. Я так понял, что в данном случае это признак одной и той же поддиректории, в данном случае 0Huis
     
    Цитата:
    судя по всему чекдиск снес подпапку Gruz2016, и соответственно о том, что было там внутри вообще никаких упоминаний нет.
     

    Цитата:
    Если даже снесена запись об этой папке, в записях MFT подпапок и файлов внутри неё, остался номер родительской папки. И, в отсуствии родительской, они как раз собираются в DMDE в папки типа $Fxxxx
    Потому и писал о таких папках и о поиске по известным именам. Технически, можно поискать где фигурируют названия в хексредакторе и возможно что ситуация прояснится, но это очень муторно.
    Дамп подтвердил подозрение в наличии расширенного атрибута в 0-вой записи, причём его "конструкция" для меня нова. Здесь уже было как то пара-тройка случаев с таким атрибутом, огромным числом записей (у тебя около 460 тысяч, но было и больше) и невиндовыми системами. Могу предположить что это как то взаимосвязано - ведь NTFS не документирована в полном обьёме, и всевоможные приблуды для работы с инородной ФС не гарантируют свою безошибочность.
    Как то так.  

     
    Попробовал несколько поисков по именам, которые помню - ничего не нашлось. В папках $Fxxxx в основном файлы, которые были сознательно удалены и они как раз неинтересны.
     
    Я не думаю, что тут вмешались сторонние системы - я записывал данные под семеркой, потом просто несколько раз втыкал этот диск в виртуальную винду на маке, но это не портило файлы. А испортил как раз чекдиск, который я опять-таки запускал на семерке.

    Всего записей: 24 | Зарегистр. 06-01-2006 | Отправлено: 10:18 10-02-2016 | Исправлено: avtandil33, 10:20 10-02-2016
    temp9285

    BANNED
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    avtandil33
    Мне не очень понятны некоторые записи (терминологии) чекдиска, но попробую пояснить что мне видется.
     
    Неверный нерезидентный атрибут типа 0x80. Правильная длина данных 0x28b00000,
    размер файла 0x28b00000, выделенная длина 0x222bf000.

    Судя по всему, речь идёт о упоминаемом расширенном атрибуте в 0-вой записи.
    Правильная длина и размер файла (в десятичных) - 682622976, а выделенная длина 573304832.
    Последнее значение как раз фигурирует в 80-м атрибуте. Если учитывать что размер стандартной записи 1024 байта, то в файле такого размера может быть информация о 559868 записях.
    А для 682622976 это значение равно 666624.
     
    Теперь другой фрагмент, коих немало
    Запись в индексе $I30 в файле 0x1bb10 указывает на файл 0x89032,
    который расположен вне MFT.

    Опять же, если перевести в десятичные, то можно прочесть о том, что индексная запись в файле 113424 указывает на файл 561202, который размещён за пределами MFT.
    Что, в принципе справедливо т.к. 561202 > 559868; и можно предположить что чекдиск кастрировал MFT.

    Всего записей: 1369 | Зарегистр. 07-11-2015 | Отправлено: 16:30 10-02-2016
    acrid2

    Newbie
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    temp9285

    Цитата:
    Насколько понял - папки пустые или в них мало (мелких?) файлов?
    Если учесть что дата MFT - октябрь 2014 года, не удивлюсь ели подтвердится что бывший хозяин форматнул раздел.

     
    Не знаю, вроде не пустые, в некоторых есть подпапки и файлы.
    вот, развернул одну для примера.  
     
    http://s008.radikal.ru/i304/1602/19/db18b2e774b3.jpg
     
    Так же приведу ниже скрин, что нашел hetman(там есть папка lost files, где также куча папок и файлов.
     
    http://s019.radikal.ru/i631/1602/c1/0d24390a44e5.jpg
     
    а если диск таки был отформатирован, уже невозможно восстановить таблицу и бут(файлы как я понимаю на месте, а потерянные из-за повреждения таблицы)?
     
    upd: скрины перепутаны местами
     
     

    Всего записей: 25 | Зарегистр. 08-02-2016 | Отправлено: 16:49 10-02-2016 | Исправлено: acrid2, 16:54 10-02-2016
    temp9285

    BANNED
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    avtandil33
    Ещё один фрагмент
    Удаление элемента Arab1-A.wav из индекса $I30 файла 559770.
    Такой же есть и в отношении 559771, а может и ещё других.
    Теперь смотри часть найденных фрагментов MFT http://tau.rghost.ru/6MsM7VcS4/image.png
    Фиолеовы выделено уже знакомое число записей.
    Но сейчас важен выделенный красным. Это фрагмент начинающийся с записи 556380 и длиной 3488 записи. Но печалька в значении в скобочке -3139 - это число отсутствующих записей. Может туда что то упало не то, может они серьёзно повреждены, но их как бы нет (даже с каким то сдвигом).
    Поэтому не удивительно что нет чего то.
    И неудивительно что из индексов каталогов удалялась информация об отсутствующих файлах.
     

    Цитата:
    Что интересно у них у всех стоит чекдисковская метка - файл  113424

    Посмотри что в этой и других часто упоминаемых записях и станет чуть понятнее.
     
    PS. В результатах поиска есть немало крупных неидентифицированных фрагментов, в которых немало и удалённых записей. Возможно что среди них и есть нужные тебе, но это надо расскапывать.
     
    PPS. Совсем забыл про
    Цитата:
     Я не думаю, что тут вмешались сторонние системы - я записывал данные под семеркой, потом просто несколько раз втыкал этот диск в виртуальную винду на маке, но это не портило файлы. А испортил как раз чекдиск, который я опять-таки запускал на семерке.

    Даже при простом подключении к работающей системе происходят записи в ФС. Кстати, маковские ОС очень недурно гадят несколькими служебными папками (название не помню). И вообще, в неопределённый то момент может произойти какое то стечение обстоятельств, которое приведёт к глюку. Причём это могут быть не зависящие от пользователя.
    И если произошло какое то наложение мусора в область MFT, то чекдиск можно обвинить, но наверное в обрезке размера файла, но не в корректировке индексов об отсутствующих записях. Хотя, если вспомнить скандиск или NDD, то там было более грамотно - сообщение об ошибках, запрос на исправление, создание файла отката изменений.
    И ещё один момент. Учитывая сильную фрагментацию MFT, можно быть уверенным в том что и сами данные сильно фрагментированы; что нередко является следствием чрезмерной заполненности раздела. Насколько был заполнен раздел?
     
     
    Добавлено:
    acrid2
    Я не в курсе как устроен раздел восстановления соньки, но обычно есть несколько огромных wim-файлов.
    Есть что то подобное?

    Цитата:
    а если диск таки был отформатирован, уже невозможно восстановить таблицу

    Учитывая значение начальных кластеров MFT и зеркала, число записей равное 256 - форматирование делалось вистой или более новой виндой. Соответственно - нет содержимого такого числа записей бывших ранее. А это достаточно много когда речь идёт о восстановлении функционал раздела восстановления, который то и без одного файла может не заработать.
    Если интересно, сделай Поиск NTFS на учаcтке этого раздела и выложи лог поиска.
    ИМХО, не стоит использовать без надобности бэта версии.
     
    И в условиях поиска убери галку с RAW и прочего, что не относится к NTFS.

    Всего записей: 1369 | Зарегистр. 07-11-2015 | Отправлено: 16:50 10-02-2016 | Исправлено: temp9285, 17:46 10-02-2016
    acrid2

    Newbie
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

    Цитата:
    Если интересно, сделай Поиск NTFS на учаcтке этого раздела и выложи лог поиска.
    ИМХО, не стоит использовать без надобности бэта версии.
     
    И в условиях поиска убери галку с RAW и прочего, что не относится к NTFS.

     
    Вот это, наверное, не есть хорошо?
     
    http://s018.radikal.ru/i514/1602/a7/808980ff4dbd.jpg
     
    лог
     

    Всего записей: 25 | Зарегистр. 08-02-2016 | Отправлено: 18:40 10-02-2016 | Исправлено: acrid2, 18:40 10-02-2016
    temp9285

    BANNED
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    acrid2
    Пробовал открыть результаты поиска?
    По логу виден фрагмент размером в 2304 записи.

    Всего записей: 1369 | Зарегистр. 07-11-2015 | Отправлено: 20:39 10-02-2016
    acrid2

    Newbie
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

    Цитата:
    По логу виден фрагмент размером в 2304 записи.

     
    Да, пробовал, а на что обращать внимание, на размер?
     
    что отражает объем "записи" -это размер, кол-во файлов или что?
     
    Добавлено:
    Искал по разделу поиском, параметры и результат на скрине.
     
    http://s016.radikal.ru/i334/1602/07/714fb1d2024b.jpg
     
    Добавлено:
    вообще, все что нашел hetman и что я скопировал на диск - это 2,8Gb. 2,72gb из них в папке "$ lost and found" больших фалов а-ля *.wim нет
     
    Добавлено:
    вообщем ладно, спасибо Вам за помощь, уже даже мне понятно, что там ничего не восстановить...там основных файлов нет, а все что осталось какой-то мусор..

    Всего записей: 25 | Зарегистр. 08-02-2016 | Отправлено: 21:37 10-02-2016 | Исправлено: acrid2, 21:37 10-02-2016
    avtandil33

    Newbie
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    temp9285
     

    Цитата:
     
    Ещё один фрагмент
    Удаление элемента Arab1-A.wav из индекса $I30 файла 559770.
    Такой же есть и в отношении 559771, а может и ещё других.
    Теперь смотри часть найденных фрагментов MFT http://tau.rghost.ru/6MsM7VcS4/image.png
    Фиолеовы выделено уже знакомое число записей.
    Но сейчас важен выделенный красным. Это фрагмент начинающийся с записи 556380 и длиной 3488 записи. Но печалька в значении в скобочке -3139 - это число отсутствующих записей. Может туда что то упало не то, может они серьёзно повреждены, но их как бы нет (даже с каким то сдвигом).
    Поэтому не удивительно что нет чего то.
    И неудивительно что из индексов каталогов удалялась информация об отсутствующих файлах.
     
     
    Цитата:
    Что интересно у них у всех стоит чекдисковская метка - файл  113424
     
    Посмотри что в этой и других часто упоминаемых записях и станет чуть понятнее.

     
    Посмотрел - не стало Объяснишь ?
     
     

    Цитата:
     
    PS. В результатах поиска есть немало крупных неидентифицированных фрагментов, в которых немало и удалённых записей. Возможно что среди них и есть нужные тебе, но это надо расскапывать.

     
     
    А это реально покопать или уже в морг ?
     

    Цитата:
    PPS. Совсем забыл про
    Цитата:
     Я не думаю, что тут вмешались сторонние системы - я записывал данные под семеркой, потом просто несколько раз втыкал этот диск в виртуальную винду на маке, но это не портило файлы. А испортил как раз чекдиск, который я опять-таки запускал на семерке.
     
    Даже при простом подключении к работающей системе происходят записи в ФС. Кстати, маковские ОС очень недурно гадят несколькими служебными папками (название не помню). И вообще, в неопределённый то момент может произойти какое то стечение обстоятельств, которое приведёт к глюку. Причём это могут быть не зависящие от пользователя.
    И если произошло какое то наложение мусора в область MFT, то чекдиск можно обвинить, но наверное в обрезке размера файла, но не в корректировке индексов об отсутствующих записях. Хотя, если вспомнить скандиск или NDD, то там было более грамотно - сообщение об ошибках, запрос на исправление, создание файла отката изменений.
    И ещё один момент. Учитывая сильную фрагментацию MFT, можно быть уверенным в том что и сами данные сильно фрагментированы; что нередко является следствием чрезмерной заполненности раздела. Насколько был заполнен раздел?  

     
    Где-то около полутора ТБ из двух. Причем ценной инфы где-то 500 гигов, порядка 1 ТБ есть и в копии. Там была вот еще какая особенность. Был один каталог Chartco, у которого внутри было порядка 2000 мелких файлов. В свое время подобный каталог мне убил флэшку, а искомый диск вис в маке при обращении к этой папке. Но я всю папку гневно удалил (даже мимо корзины), после чего диск стал нормально работать на маке и соответственно на виртуальной винде. А чекдиск был уже после этого процесса.

    Всего записей: 24 | Зарегистр. 06-01-2006 | Отправлено: 23:03 10-02-2016
    temp9285

    BANNED
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    avtandil33

    Цитата:
    Но я всю папку гневно удалил (даже мимо корзины), после чего диск стал нормально работать на маке и соответственно на виртуальной винде. А чекдиск был уже после этого процесса.

    Не всё проявляется моментально, тем более там, где есть кэширование.
    Банальный пример - если при работающей системе обнулить таблицу разделов, то ничео не случится. А после перезагрузки - банан.

    Цитата:
    Посмотрел - не стало  Объяснишь ?

    Видно и на скриншоте что это одна из твоих папок. Соответственно, упоминание удаление каких то записей за пределами MFT, относящихся к этой папке, означает упоминание о них и это место становится доступным для новой информации - в том числе и для изменяемой далее чекдиском.
     

    Цитата:
    А это реально покопать или уже в морг ?

    Это зависит от тебя - захочешь ли ты искать названия, определять к чему это относится и далее определяться что делать.
     
     
    acrid2
    Ну что поделать.  Хотя .... я не являюсь истиной в последней инстанции.
    Может стоит всё таки разобраться в соответствующем месте и установить систему.
    Например, беглый поиск привёл в https://community.sony.ru/t5/pk-i-aksessuary/poryadok-ustanovki-drayverov-vpcz13z9r-windows-7/td-p/1990060/page/4
    Ну и ещё один совет - подумай о необходимости 0-го рэйда из четырёх SSD. Любо из них вылетит и аля-улю всему массиву.

    Всего записей: 1369 | Зарегистр. 07-11-2015 | Отправлено: 23:51 10-02-2016
    acrid2

    Newbie
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    Подробнее... Да как я уже только не пробовал драйвера ставить и приложения, что там доступны...и так и сяк и наперекосяк... не работают fn хоть ты тресни...люди в сети пишут, что такое случается и на других ноутах(например hp), что нормально все работает только из рекавери... да и еще там что-то должно быть, кроме виндовых дров для fn клавиш, ведь они должны работать еще до загрузки винды, сразу после включения экрана грубо говоря(как, например на простейшем нетбуке acer aspire one, c которого я сейчас пишу), а хрен там...  
    Может эти дрова заточены под систему которая на ноуте в стоке стоит win 7 pro AO CIS and GE x16-96122...потому что при попытке накатить лицензионную винду с новой проблемой столкнулся, что ключ, который на наклейке только к такой сборке подойдет, а ее тоже хрен найдешь, с офф. сайта не скачаешь...пишут только к производителю обращаться...вот и вторая причина по которой рекавери необходим...
     
    а теперь еще одна проблема нарисовалась, после моих манипуляций с удалением раздела и воостановлением из копии, не грузится винда теперь ) короче он бут не видит теперь вообще... видать тот что на 100мб виндовский был слеплен с рекавери но работал, а после разделения надо бы его сделать как-то ) как бы все вернуть теперь? dmde на том ноуте, грузить с загрузочной флешки, запускать dmde, а дальше что?  Подробнее... [/more]

    Всего записей: 25 | Зарегистр. 08-02-2016 | Отправлено: 00:30 11-02-2016 | Исправлено: acrid2, 00:35 11-02-2016
    temp9285

    BANNED
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    acrid2
    Что касается установки винды и т.п., это уже. оффтоп
    Ну а что касается проблемы с загрузкой, то их как бы не должно быть из за того, что сделали потому что до изменений у тебя был один рабочий раздел и один без бутсектора, считай что его не было. На рабочем у тебя были необходимые для загрузки файлы и он активный. И это не должно было измениться.
    Ну разве что в контейнере загрузки была запись о загрузке с восстановленного раздела, которая раньше просто не работала (и то это гипотетически). Если что, можешь загрузиться с чего то, что увидит твой рэйд полноценно (кстати, ещё одно из неудобств рэйдов) и  удалить восстановленный раздел, можешь бутсектор затереть.
    А для начала просто загрузись с дстрибутива и войди в режим восстановления - возможно что винда починит что нужно.

    Всего записей: 1369 | Зарегистр. 07-11-2015 | Отправлено: 00:53 11-02-2016
    acrid2

    Newbie
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    после изменений у меня стало три раздела: один не размеченный, как раз тот самый виндвый на 100мб(помечен черным), один с виндой(диск с и один на те самые 8 гб(рекавери), и бут при старте ноута он берет с него, вместо виндового на 100мб раздела...(это как я понимаю, возможно в корне ошибаюсь)  
    ведь я правильно понимаю, что для нормальной загрузки винды как раз и служит тот самый  резервный раздел на 100мб и на нем хранится boot record и mft таблица? или mft для каждого раздела своя, а на 100мб только запись бут?

    Всего записей: 25 | Зарегистр. 08-02-2016 | Отправлено: 01:13 11-02-2016
    temp9285

    BANNED
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    acrid2
    Покажи текущее состояние разделов, ну или опиши как то более подробно.  
    Если ты правильно восстанавливал, у тебя должно быть всего два раздела - основной и рековери. Так оно и есть.
    Даже если бы ты восстановил 100 меговый, то загрузка всё равно начинается со большого раздела, т.к. он активный (буковка А около типа 07).
    MFT у каждого раздела своя.

    Всего записей: 1369 | Зарегистр. 07-11-2015 | Отправлено: 01:29 11-02-2016 | Исправлено: temp9285, 01:33 11-02-2016
    avtandil33

    Newbie
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    temp9285
     

    Цитата:
    Цитата:
    Посмотрел - не стало  Объяснишь ?
     
    Видно и на скриншоте что это одна из твоих папок. Соответственно, упоминание удаление каких то записей за пределами MFT, относящихся к этой папке, означает упоминание о них и это место становится доступным для новой информации - в том числе и для изменяемой далее чекдиском.

     
    Пока не врубился. Тут где-то цифры надо из 16-ричной в 10-ричную переводить, чтобы номера получить ? А то не узнаю свою папку по скриншоту.
     
     

    Цитата:
    Цитата:
    А это реально покопать или уже в морг ?
     
    Это зависит от тебя - захочешь ли ты искать названия, определять к чему это относится и далее определяться что делать.  

     
    Дык русские же не сдаются ! Даже если не удастся полностью восстановить нужные данные,
    не догоню, так хоть согреюсь, всяко опыта поприбавится...
    Так что жду инструкций...

    Всего записей: 24 | Зарегистр. 06-01-2006 | Отправлено: 02:11 11-02-2016 | Исправлено: avtandil33, 02:12 11-02-2016
    acrid2

    Newbie
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    temp9285
    посмотрите пож-та мой пост от 10 числа 00:32 самый нижний скриншот, там я показывал как винда видит разделы.  
     
    вот он http://s019.radikal.ru/i623/1602/11/b749e87455a2.jpg
     
    как я вижу ситуацию.  
    предыдущий владелец, перед продажей наспех устанавливал винду(скорее всего и понятия не имея что такое рекавери) соответственно, перед установкой делал разбивку диска, как предлагала винда. винда под его присмотром установила свой mbr и сопутствующие файлы в раздел рекавери sony, отсюда их симбиоз, тем самым поломала мбр и уничтожила часть файлов(возможно вместе с mft)рекавери раздела Sony.
    так вот, загрузочная запись для прежней конфигурации винды как раз и находилась в тех 100 мб( которые теперь не распределены) и в данный момент берется из раздела 8 гб( где полная разруха и нинаких упоминаний о нынешней винде ессно)  
    возможно(и скорее всего) у меня в голове примерно такая же ситуация как в mtf таблице раздела рекавери sony ))
    что скажете, док?
     
    Добавлено:
    я вообще правильно понимаю для чего при установке виндой создается 100мб раздел(как я понимаю, там бут рекорд и другие системные файлы, необходимые для загрузки)??
    Может я вас не понимаю как раз из-за неправильно представления о том как происходит загрузка...
     
    Добавлено:
    Вот, вычитал что 100 раздел нужен для BitLocker и создается он, когда при установке Windows разделы создаются заново, а если они уже были созданы ранее, то этот 100 не создается и загрузчик находится там же где система(в моем случае на С...
    Но, раз у меня этот раздел присутствует значит мое предположение верно, и тот кто ставил винду создавал разделы заново при установке винды и этот 100 мб упал в раздел с рекавери, при этом потер его...только не пойму  тогда, почему размер этого раздела был прежние 8(условно) + 100, вместо того, чтобы 100 + все остальное...
     
    Добавлено:
    дополню: сначала, он видимо додумался его отформатировать, раз менеджер разбиения винды не видел разделов при установке
     
    Добавлено:
    по поводу raid 0 - а какие варианты? потерять половину объема и raid1?

    Всего записей: 25 | Зарегистр. 08-02-2016 | Отправлено: 12:44 11-02-2016 | Исправлено: acrid2, 12:50 11-02-2016
    temp9285

    BANNED
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    avtandil33

    Цитата:
    Тут где-то цифры надо из 16-ричной в 10-ричную переводить, чтобы номера получить ?

    Конечно, если в логе чекдиска они в таком формате, то как без перевода в привычный вид?
    У шестнадцатиричных в начале 0x

    Цитата:
    всяко опыта поприбавится...  Так что жду инструкций...

    Вряд ли по инструкциям он прибавится. Да и без повторений (осмысленных) быстро забудется.
    Попробую написать, но не люблю я слишком долго описывать, а кратко сложновато.
     
    acrid2
    Давай не будем здесь углубляться в оффтоп.
    Есть тема http://forum.ru-board.com/topic.cgi?forum=62&topic=18466#1 в которой описан механизм загрузки, и из которой можно понять что вставка раздела не должна влиять на начальную загрузку.
    Ну и что касается рэйда0, то лучше пойми его структуру и к чему приводит потеря одного участника.
    Обьём ты не потеряешь. если не будешь делать рэйд1 (смысл в нём?).

    Всего записей: 1369 | Зарегистр. 07-11-2015 | Отправлено: 23:23 11-02-2016
       

    Страницы: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100

    Компьютерный форум Ru.Board » Hardware » Магнитные носители информации » Восстановление разделов и информации на HDD (часть 8)
    Akam1 (13-11-2016 05:23): http://forum.ru-board.com/topic.cgi?forum=84&topic=5216


    Реклама на форуме Ru.Board.

    Powered by Ikonboard "v2.1.7b" © 2000 Ikonboard.com
    Modified by Ru.B0ard
    © Ru.B0ard 2000-2024

    BitCoin: 1NGG1chHtUvrtEqjeerQCKDMUi6S6CG4iC

    Рейтинг.ru