Слетела файловая система
 

Есть диск SSD 60 Гб с Win7 x64.
Есть HDD 1 Тб. На нем было вначале 40 Гб неразмеченного пространства, потом 830 Гб (насколько помню) NTFS данные E: , потом в конце 60 Гб неразмеченное пространство. Неразмеченное пространство я сделал в утилите управления дисками Windows (там были пустые NTFS разделы на их месте).
Я хотел все это объединить в один NTFS раздел. Загрузился с Linux Mint 14 LiveDVD и в программе Gparted сначала расширил (опция Resize/Move) 830+60=890 Гб, получился раздел 890 Гб. Довольно быстро сделалось (изменения на диск записались, так как я нажал кнопку применить). Я решил делать по очереди. Таким образом мне оставалось 40 Гб объединить. Но так как видимо из-за того, что они в начале диска, программа написала что будет делать 2 часа и начала похоже перемещать раздел 890 Гб в начало диска. А может быть и не начала, там было написано Read only test: Read 890 Gb, я так и не понял это имитация или само перемещение (в интернете нагуглил, что сначала идет имитация). Еще она предупредила, что загрузочный сектор будет стерт, я согласился, так как на этом диске операционных систем нет. Так вот оставалось 20 минут до конца ее операции и как назло комп вырубился, может электричество пропало. Загрузился в Windows, она этот диск показывает как RAW. Хотя раздел E: в моем компьютере остался, но при заходе туда пишет "не удается распознать файловую систему". Управление дисками показывает размер 930 Гб. Загрузился в Linux опять, Gparted вообще распознает диск как файловую систему Linux ext3 или 4. Загрузился в Windows LiveCD, там утилита HDD Doctor тоже пишет, что файловая система не NTFS, а ext3 и спрашивает исправить ли, я отказался. Как теперь вернуть данные?
У меня есть два предположения:
1 Gparted все-таки делал Readonly test и данные физически не перемещались. Только вот зараза почему так долго, 2 часа на тест, еще столько же на перемещение выходит. Наверное надо было создать 40 Гб пустого раздела NTFS, а потом их объединить. Тупая прога.
2 Как и предупреждал Gparted, возможно MBR уже затерт и потому файловая система не распознается.
Запасных терабайтников нет.

Я пока сканю прогой GetDataBack, пишет тоже 2 часа надо. Если она найдет файловую систему, пересохраню важные мелкие файлы на SSD диск, а тяжелым контентом придется пожертвовать в худшем случае. Потом уже можно будет пытаться восстанавливать терабайтник.
В GetDataBack файлы видны, некоторые восстановил. Но хотелось бы исправить файловую систему.

Вот как диск видят спец проги:
Тип первичный
Логический диск E: без метки, неактивный
Файловая система: Linux Ext3
ID 0x07 NTFS
Размер 931,5 Гб
Свободно 31,1 Гб
Начальный сектор 2048

Вот так Windows:


А Linux Mint LiveDVD открывает его как Ext4, там даже есть несколько файлов



То есть Gparted создал первые 40 Гб действительно Ext4, а дальше идет 890 Гб NTFS.
GetDataBack до NTFS раздела добирается и файлы можно пересохранить, но потребуется новый объемный диск. Можно ли откорректировать файловую систему, чтобы второй раздел 890 Гб NTFS виден был?

Если дело только в этом, а фактического перемещения данных не было, то нестрашно...:)
Посмотрите что я Паша-Север советовал
См. пост Tau_0 Отправлено: 16:28, 05-02-2012 | в теме
HDD - не заходит на хард
http://forum.oszone.net/post-1852294.html#post1852294

И тоже самое выполните. Это очень быстро делается...

Немного не успели вы за моим сообщением выше.

Я успел написать то, что Вам следует сделать в первую очередь... Обязательно сделайте это дело...
Главное, --- чтобы Вы авторековырялками окончательно ВСЁ не попортили.

ЗЫ Вы просто не представляете себе, --- какая это мощная штука, --- дисковый редактор.

Ясно
Простой вид:

Расширенный вид:

Сектора http://yadi.sk/d/irFTsVJJ2v9ob
Раздел 893 Гб нужно сохранить.

ext4 раздел появился наверное потому что я линукс на 40 Гб раздел ставил и удалял раньше. Причем несколько раз.

Хм...???...

Я бы в DMDE:
1. Выделил раздел MSData (07) и удалил его.
2. Выделил раздел $Noname 04 и вставил его как основной. И пока ВСЁ. По книге жизни и Вашему рассказу, скорее всего, он нужен...
3. Перезагрузил компьютер и посмотрел со стороны, --- что в разделе...???...

ЗЫ Ни в коем случае не допускайте запуска/автозапуска чекдиска с ключём /F. А вот в режиме чтения (без ключа /F) чекдиск можно, если том смонтируется, следует потом напустить.)
ЗЗЫ Сейчас 9285 наедет и начнёт меня строить и ругать за поспешность... Забьём на это...:gigi::gigi::gigi:
Но если делать аккуратно, то так можно...

А как это сделать, какой пункт выбрать? Я с этой прогой раньше никогда не работал

Нужен 893 Гб вообще-то, он должен быть годным.

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

Поэтому я пришёл к выводу, что надо восстанавливать раздел $Noname 04, а не $Noname 02

Вы перезагрузитесь и покажите картинку из управления дисками
Пуск ===> Выполнить ===> diskmgmt.msc

Эти разделы перекрываются, --- можно выбрать только один из двух...

Я же писал

После выделения раздела $Noname 04 в левом нижнем углу станет доступна клавиша Вставить, --- её тискайте...

Разобрался, сделал. После перезагрузки раздел появился в системе, все на месте вроде. Размер 891 Гб (618 Гб занято, 272 Гб свободно).
Вот так выглядит в Windows:

В dmde:

При загрузке Windows порывалась сделать chkdsk, я отказался. Сделал сам в режиме чтения:

Значит на chkdsk можно соглашаться?

И можно ли пространство 40 Гб отформатировать средствами системы в новый NTFS раздел? Чтобы место не пропадало. Объединять уж не буду, ну их.

Угу, запускайте Берлагу с ключём /F.

Посмотрите потом интереса для в DMDE --- у раздела $Noname 04 чекдиск выставит индикатор BCF, а было BxF, это значит, что резервную копию бута в последний сектор раздела чекдиск на всякий пожарный поместилпоместил.

ЗЫ Никогда не двигайте левую границу раздела (не добавляйте/объединяйте раздел с местом слева). Даже если оно и без аварии закончится, --- в разделе большой бардак получится. Это мина замеддленного действия. В любой момент рвануть сможет. Хотя внешне для пользователя ВСЁ и пристойно выглядит.

Другими методами/путями подобную проблему решайте. У Вас ведь пока перед разделом память свободная гуляет...

Буду знать. Отформатировал 40 Гб в раздел, все нормально. Вот так стало:


Спасибо за помощь!

Ну почти нормально...:)

Маленьная дюрочка каким-то образом образовалась.

Смотрим раздел $Noname 01 (тот раздел, что Вы отформатировали)
StartLBA = 2048 --- начало
EndLBA = 83890175 --- конец

Тогда, как раздел
$Noname 02 (раньше DMDE обзывал его как $Noname 04)
StartLBA = 83891430 --- начало
EndLBA = 193525167 --- конец

Оцениваем зазор
GAP = 83891430 - 83890175 + 1 = 1256 секторов
Учитывая, что стандартный размер сектора равен 512 байам = 1/2 KiB

т.е. в килобайтах это будет: --- 1256 / 2 = 628 KiB

Совсем мизерная потеря, --- я бы плюнул на неё...

Но несложно и приклепать эти 1256 секторов, --- справа добавлять память можно. Просто лишняя возня из-за ерунды. Но если хотите, --- присоединим эти 628 KiB к разделу $Noname 01. В Seven так совсем просто расширить раздел. --- В управлении дисками отмечаете том и выбираете пункт "расширить том". В XP тоже можно расширить, но вручную, --- через правку таблицы разделов, правку BPB (блока параметров BIOS) в загрузочном секторе тома. Затем ещё чекдиск надо будет на том напустить, чтобы окончательно "приклепать".

А так, если судить по индикаторам DMDE с разделами гуд. EBCF включены. Кстати, посмотрите в справке DMDE, --- что эти буквы/индикаторы означают.

Да там мусора хватает. Еще дохлый grub сидит в начале диска. Если выбрать загружаться с этого HDD, то grub стартует естественно с ошибкой.
А то что несуществующие разделы видны так и должно быть?

На первом SSD 60 Гб винте тоже какая-то аномалия. dmde ругается, Gparted вообще показывает как unnolocated c похожим предупреждением. HDD Doctor говорит надо бы исправить фактический размер раздела. При этом Windows нормально загружается! Даже chkdsk диска C делал, он там что-то подправил, но аномалия осталась. А вот если согласиться с HDD Doctor и подправить размер, то Windows отказывалась загружаться. Пришлось восстанавливать загрузку с установочного диска Windows (решение проблемы загрузки). Но тогда аномалия возвращалась, выходит так нужно Windows. Но это уже другая песня. Работает и ладно


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

Это точно - ножики тоже виноваты что ими пальцы отрезают. :lol:

Tau_0
Можешь и забить, тем более что данные не твои.
F не всегда означает всю таблицу, а при приклеивании места слева неизбежны изменения - или сдвиг всех данных или пересчёт всех данных в таблице. Или и то и другое вместе.
PS. Вот только непонятно, почему бы не посмотреть что есть в разделе перед восстановлением?

Это реликты, когда-то там были нормальнын разделы, но потом они удалялись/переразбивались/форматировались... DMDE ведь ремонтный редактор, --- его основная задача найти обломки и показать. А Ваша задача, основываясь на представленных данных DMDE, --- применить свой творческий потенциал, --- отсеять лишнее и взять нужное, чтобы нормально восстановить разделы.

Эти реликты нисколько не мешают Windows, --- он их не замечает. Но мешают человеку восстанавливать рухнувшие пазделы (при определённых условиях помещают и авторековери прогаммам). Шумы всегда мешают...

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

Нект, --- надо исправить.
DMDE показывает, что на харде последний физический сектор заканчивается в секторе LBA = 117231407. А у Вас последний сектор раздела $Noname 02 заканчивается в секторе EndLBA = 117240372, а это уже за пределами харда. Так неверно в таблице разделов прописано... Скорее всего правильное значение для последнего сектора --- EndLBA = 117227519. Такой раздел находит DMDE, и этот сектор попадает в диапазон реальных секторов харда.

Проверим эту догадку, --- пришлите 50 секторов, начиная с LBA = 206848.
Ну и заодно ещё и 50 секторов, начиная с LBA = 117227500.


Добавлено...

А вот теперь и посмотрим...:gigi::gigi::gigi:

Что мешало посмотреть открыв раздел?

Как я его открою, когда раздел у deniskx...???...

Предложить ему это сделать перед изменениями никак?

Ну вот Вы и предложили...:)

ЗЫ Я тоже порой предпочитаю строго как унтер информацию из BPB брать...
DMDE конечно замечательный редактор, но так оно строже , будет...

lba_206848_50.bin http://yadi.sk/d/f5fq-wSo2wZqn

lba_117227500_50.bin http://yadi.sk/d/q-cS6juD2wZrD

У меня есть предположение почему так могло случится. Дело в том, что я несколько раз делал/восстанавливал полную RAW копию всего диска SSD 60 Гб прогой HDDRAWCopyTool. Чтобы забэкапить полностью Windows и поставить Linux, а через какое-то время делал копию Linux и восстанавливал Windows. Со всеми потрохами (чтобы с разделами, загрузчиками, правами не было проблем и они полностью скопировались). Так как SSD винт у меня только один, а хотелось бы чтобы оси стояли на быстром винте. Этот слепок в виде 60 Гб img файла я сохранял на 1 Тб винте, а потом сжимал WinRAR-ом к слову. Так вот если у SSD диска уменьшились сектора, например в следствии их износа, не знаю возможно ли такое, а в накатываемой копии секторов было соответственно немного больше, отсюда несоответствие.
Однако SMART показывает, что с диском все в порядке

Смотрим загрузочный сектор тома NTFS (самый первый сектор из файла lba_206848_50.bin)
Редактор ===> Загрузочный сектор
и видим такую картинку


На основании Total NTFS sectors и начала раздела находим его правильный конец таким вот образом: ---

Total NTFS sectors = 117020671
StartLBA = 206848
Тогда
EndLBA = StartLBA + Total sectors = 206848 + 117020671 = 117227519 --- этот конец верный...

Дополнительно убеждаемся в его корректности --- в секторе 117227519 действительно лежит верная копия бута.

Не получилось у меня в DMDE шаблон на копию бут сектора тома одеть...???..., --- через WunHex только вышло...

Теперь можно либо таблицу разделов подправить (на мой взгляд это правильнее и строже...), либо (что быстрее и проще) удалить раздел $Nonamt 02, а затем оять его вставить. DMDE должен правильное значение вставить.

Не могу картинку по правке PT показать --- нужен всего лишь один сектор LBA = 0. А у меня его нет, не запросил.:( Пришлите его, или через удаление-вствку корректуру выполните...

Не знаю насколько постоянно число секторов у SSD. Скорее всего просто в результате работы втёмную с различными утилитами так получилось...

lba_0_100.bin http://yadi.sk/d/UqTCP64S2w_nV
Утилита одна и та же всегда использовалась HDDRAWCopy Tool. Может быть и не в этом дело. Я не припомню, чтобы количество секторов в ней отличалось.

Сделал. Теперь Dmde не ругается

Gparted тоже стал нормально отображать разделы. А HDD Doctor ругается на все. И что размеры не совпадают и что в конце есть еще раздел. Наверное не стоит ее слушать.

У меня завалялся августовский архив SSD диска. Подсунул его в HDDRAWCopy Tool и там размеры с текущим диском совпадают. Вот что прога написала:
Source RAW File LBA 117,231,408
Destination SSD LBA 117,231,408

Похоже, что Вы правы, --- со временем SSD усыхает...:(
Во дела...:gigi::gigi::gigi:

Поискал навскидку в сети...
Емкость SSD со временем уменьшается?
http://otvet.mail.ru/question/68627926

Добавлено....

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


1. Выбрать нужный диск
2. Редактор ====> Таблица разделов
a). Выделяем вторую строку
b). Ctr + E
b). Корректируем поле Число секторов

117033525 <===== 117020671

c). По Ctr + W сохраняем изменения и перезагружаемся...

Ну емкость то не меняется. Быстродействие должно ухудшаться.

А вот это надо и уточнить. Вроде как уменьшается ёмкость на запись, тогда от того, что данные читаются радость невелика...

ЗЫ У меня нет SSD, --- боюсь их..., как та бабушка, которая боялась электричества...

Не бойтесь :gigi: . Я пользуюсь уже долго никаких нареканий. С таким настроем нужно боятся и обычных HDD там тоже есть чему сдохнуть.
Емкость уменьшаться не должна. Вот что я нагуглил
http://www.compress.ru/article.aspx?id=21619&iid=987

Согласен. Причём ёмкость резеврвной области у ССД больше чем у ХДД в процентном соотношении к рабочему обьёму.