Показать полную графическую версию : [решено] Слетела файловая система
Есть диск 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:
http://savepic.ru/4157597m.png (http://savepic.ru/4157597.htm)
А Linux Mint LiveDVD открывает его как Ext4, там даже есть несколько файлов
http://savepic.ru/4146333m.png (http://savepic.ru/4146333.htm)
http://savepic.ru/4151453m.png (http://savepic.ru/4151453.htm)
То есть Gparted создал первые 40 Гб действительно Ext4, а дальше идет 890 Гб NTFS.
GetDataBack до NTFS раздела добирается и файлы можно пересохранить, но потребуется новый объемный диск. Можно ли откорректировать файловую систему, чтобы второй раздел 890 Гб NTFS виден был?
2 Как и предупреждал Gparted, возможно MBR уже затерт и потому файловая система не распознается. »
Если дело только в этом, а фактического перемещения данных не было, то нестрашно...:)
Посмотрите что я Паша-Север советовал
См. пост Tau_0 Отправлено: 16:28, 05-02-2012 | в теме
HDD - не заходит на хард
http://forum.oszone.net/post-1852294.html#post1852294
И тоже самое выполните. Это очень быстро делается...
Немного не успели вы за моим сообщением выше.
Немного не успели вы за моим сообщением выше. »
Я успел написать то, что Вам следует сделать в первую очередь... Обязательно сделайте это дело...
Главное, --- чтобы Вы авторековырялками окончательно ВСЁ не попортили.
ЗЫ Вы просто не представляете себе, --- какая это мощная штука, --- дисковый редактор.
Ясно
Простой вид:
http://savepic.ru/4179092m.png (http://savepic.ru/4179092.htm)
Расширенный вид:
http://savepic.ru/4172948m.png (http://savepic.ru/4172948.htm)
Сектора http://yadi.sk/d/irFTsVJJ2v9ob
Раздел 893 Гб нужно сохранить.
ext4 раздел появился наверное потому что я линукс на 40 Гб раздел ставил и удалял раньше. Причем несколько раз.
Раздел 893 Гб нужно сохранить. »
Хм...???...
Я бы в DMDE:
1. Выделил раздел MSData (07) и удалил его.
2. Выделил раздел $Noname 04 и вставил его как основной. И пока ВСЁ. По книге жизни и Вашему рассказу, скорее всего, он нужен...
3. Перезагрузил компьютер и посмотрел со стороны, --- что в разделе...???...
ЗЫ Ни в коем случае не допускайте запуска/автозапуска чекдиска с ключём /F. А вот в режиме чтения (без ключа /F) чекдиск можно, если том смонтируется, следует потом напустить.)
ЗЗЫ Сейчас 9285 наедет и начнёт меня строить и ругать за поспешность... Забьём на это...:gigi::gigi::gigi:
Но если делать аккуратно, то так можно...
Выделил раздел $Noname 04 и вставил его как основной. И пока ВСЁ. »
А как это сделать, какой пункт выбрать? Я с этой прогой раньше никогда не работал
http://savepic.ru/4134056m.png (http://savepic.ru/4134056.htm)
Нужен 893 Гб вообще-то, он должен быть годным.
Нужен 893 Гб вообще-то, он должен быть годным. »
сначала расширил (опция Resize/Move) 830+60=890 Гб, получился раздел 890 Гб. Довольно быстро сделалось (изменения на диск записались, так как я нажал кнопку применить). »
Вот после применения индексы пересчитались и данные переместились. Посмотреть оно конечно можно, что в этом разделе творится. Но бут как минимум затерт.
Поэтому я пришёл к выводу, что надо восстанавливать раздел $Noname 04, а не $Noname 02
Вы перезагрузитесь и покажите картинку из управления дисками
Пуск ===> Выполнить ===> diskmgmt.msc
В диспетчере файлов программы и в 893 и в 957 файлы видны вроде все. »
Эти разделы перекрываются, --- можно выбрать только один из двух...
Я же писал
2. Выделил раздел $Noname 04 и вставил его как основной. »
После выделения раздела $Noname 04 в левом нижнем углу станет доступна клавиша Вставить, --- её тискайте...
Разобрался, сделал. После перезагрузки раздел появился в системе, все на месте вроде. Размер 891 Гб (618 Гб занято, 272 Гб свободно).
Вот так выглядит в Windows:
http://savepic.ru/4167852m.png (http://savepic.ru/4167852.htm)
В dmde:
http://savepic.ru/4159660m.png (http://savepic.ru/4159660.htm)
При загрузке Windows порывалась сделать chkdsk, я отказался. Сделал сам в режиме чтения:
http://savepic.ru/4140204m.png (http://savepic.ru/4140204.htm)
Значит на chkdsk можно соглашаться?
И можно ли пространство 40 Гб отформатировать средствами системы в новый NTFS раздел? Чтобы место не пропадало. Объединять уж не буду, ну их.
Значит на chkdsk можно соглашаться? »
Угу, запускайте Берлагу с ключём /F.
Посмотрите потом интереса для в DMDE --- у раздела $Noname 04 чекдиск выставит индикатор BCF, а было BxF, это значит, что резервную копию бута в последний сектор раздела чекдиск на всякий пожарный поместилпоместил.
ЗЫ Никогда не двигайте левую границу раздела (не добавляйте/объединяйте раздел с местом слева). Даже если оно и без аварии закончится, --- в разделе большой бардак получится. Это мина замеддленного действия. В любой момент рвануть сможет. Хотя внешне для пользователя ВСЁ и пристойно выглядит.
Другими методами/путями подобную проблему решайте. У Вас ведь пока перед разделом память свободная гуляет...
Никогда не двигайте левую границу раздела »
Буду знать. Отформатировал 40 Гб в раздел, все нормально. Вот так стало:
http://savepic.ru/4167842m.png (http://savepic.ru/4167842.htm)
Спасибо за помощь!
Отформатировал 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. Но это уже другая песня. Работает и ладно
http://savepic.ru/4144135m.png (http://savepic.ru/4144135.htm)
http://savepic.ru/4129799m.png (http://savepic.ru/4129799.htm)
И я не знаю когда это началось, может быть давно, а я просто не обращал внимание. Опять же линуксы могли быть виноваты со своими загрузчиками.
Тупая прога. »
Опять же линуксы могли быть виноваты со своими загрузчиками. »
Это точно - ножики тоже виноваты что ими пальцы отрезают. :lol:
Tau_0
Можешь и забить, тем более что данные не твои.
F не всегда означает всю таблицу, а при приклеивании места слева неизбежны изменения - или сдвиг всех данных или пересчёт всех данных в таблице. Или и то и другое вместе.
PS. Вот только непонятно, почему бы не посмотреть что есть в разделе перед восстановлением?
А то что несуществующие разделы видны так и должно быть? »
Это реликты, когда-то там были нормальнын разделы, но потом они удалялись/переразбивались/форматировались... DMDE ведь ремонтный редактор, --- его основная задача найти обломки и показать. А Ваша задача, основываясь на представленных данных DMDE, --- применить свой творческий потенциал, --- отсеять лишнее и взять нужное, чтобы нормально восстановить разделы.
Эти реликты нисколько не мешают Windows, --- он их не замечает. Но мешают человеку восстанавливать рухнувшие пазделы (при определённых условиях помещают и авторековери прогаммам). Шумы всегда мешают...
Поэтому при серьёзных переразбиениях диска желательно пробить весь хард нулями. Он станет после этого девственно чистым, тогда его история не будет мешать...
Но это уже другая песня. Работает и ладно »
Нект, --- надо исправить.
DMDE показывает, что на харде последний физический сектор заканчивается в секторе LBA = 117231407. А у Вас последний сектор раздела $Noname 02 заканчивается в секторе EndLBA = 117240372, а это уже за пределами харда. Так неверно в таблице разделов прописано... Скорее всего правильное значение для последнего сектора --- EndLBA = 117227519. Такой раздел находит DMDE, и этот сектор попадает в диапазон реальных секторов харда.
Проверим эту догадку, --- пришлите 50 секторов, начиная с LBA = 206848.
Ну и заодно ещё и 50 секторов, начиная с LBA = 117227500.
Добавлено...
PS. Вот только непонятно, почему бы не посмотреть что есть в разделе перед восстановлением? »
А вот теперь и посмотрим...:gigi::gigi::gigi:
А вот теперь и посмотрим »
Что мешало посмотреть открыв раздел?
Что мешало посмотреть открыв раздел? »
Как я его открою, когда раздел у deniskx...???...
© OSzone.net 2001-2012
vBulletin v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.
Available in ZeroNet 1osznRoVratMCN3bFoFpR2pSV5c9z6sTC