LINUX.ORG.RU

Как починить битый раздел ext4 после перемещения?

 ,


1

2

Добрый вечер.
Имеется hdd 2tb gpt. Относительно новый (куплен в начале прошлого года) - маловероятно что он посыпался.

На нём было два раздела:

  • sdb1 - ntfs (250гб в начале) - файлопомойка для винды
  • sdb2 - ext4 (всё остальное пространство)

Решил снести винду за ненадобностью, соответственно удалил ntfs раздел sdb1.
Вместо него делать ещё один ext4 некрасиво, хотел единый ext4 на весь диск. Поскольку sdb2 забит под завязку, а ещё одного харда на 2тб нет чтобы сделать бекап, решил попробовать расширить sdb2 на пространство до него. Предварительно поэкспериментировал, создав тестовый раздел, скинув на него 10гб файл, затем переместил его - убедился что всё работает.

В KDE Partition Manager переместил sdb2 влево до начала диска, с последующим расширением до конца диска (т.е. уменьшил отступ перед разделом и увеличил размер раздела).
Выхлоп KDE Partition Manager: https://pastebin.com/p9HZZT1P

В результате тип раздела не определяется.

e2fsck выдаёт следующее: https://pastebin.com/5VZfwmuC
Пробовал запускать
e2fsck -v -b 8193
e2fsck -v -b 32768
результат тот же.

Есть ли шансы восстановить раздел?
Если да - в какую сторону копать, что делать?



Последнее исправление: Khronos (всего исправлений: 1)

Если там нет важных данных, что нужно вытянуть, а всё нужное сохранилось в бекапах — просто переустанови ОС и больше так не делай.

Если важные данные есть, но нет компетенции — ни в коем случае не трогай винт, а неси в контору по восстановлению данных и объясни ситуацию. Сразу скажу, это будет дорого.

Vsevolod-linuxoid ★★★★★
()

Ну или если совсем туго с деньгами или просто хочется попробовать себя в восстановлении данных, то для начала:

  • Берешь любой винт, свободного место на котором как минимум в 3 раза больше, чем размер винта, на котором ты так глупо убил ФС.

  • При помощи ddrescue с Live любого Linux снимаешь бинарную копию: https://wiki.gentoo.org/wiki/Ddrescue#Disk_to_image

  • Делаешь копию этой копии.

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

И тебе нужно не ФС восстановить, а данные вытянуть в первую очередь. Как — не подскажу, так как сам ни разу именно так ФС не убивал.

Vsevolod-linuxoid ★★★★★
()
Последнее исправление: Vsevolod-linuxoid (всего исправлений: 1)
Ответ на: комментарий от naKovoNapalBaran

Если в gui разделы на предыдущем месте, то можно попробовать..

  • Записать номер сектора каждого раздела начало и конец и размер раздела точный из таблицы gpt, хорошо их всегда записывать перед операциями.
  • Изменить номер сектора в консольном gptdisk например, т.е. в данном случае удалить разделы лишние из gpt, и изменить начало раздела ext на 2048, и сделать проверку без записи, т.е. изменится лишь запись gpt, не заденет разделы.

Короч, gpt таблицу редактируй, это не сложно. Там тупо цифры {номер раздела, сектор начало, сектор конец} в 1 секторе 512 байт вроде. Можно просто удалить в gpt все разделы и руками все заново вбить это не заденет данные на разделах.

naKovoNapalBaran
()
Последнее исправление: naKovoNapalBaran (всего исправлений: 8)

Неудачный инструмент.

Others complained recently about partition lost when moved to the left with «KDE Partition Manager» (KPM), including in Kubuntu forums, so I suspect the cause is a software bug, and not a hardware error.

https://www.eevblog.com/forum/general-computing/os-partition-lost-after-move-and-resize-with-kde-partition-manager/

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

Изучай форум по ссылке, кастуй местных спецов по файловым системам…

greenman ★★★★★
()
Последнее исправление: greenman (всего исправлений: 1)
Ответ на: комментарий от tz4678_2

testdisk пишет

Bad GPT partition, invalid signature.
Trying alternate GPT
Bad GPT partition, invalid signature.

В этом меню можно выбрать [Quick Search], который нашел следующее:

Disk /dev/sdb2 - 2000 GB / 1863 GiB - CHS 243201 255 63
     Partition               Start        End    Size in sectors
 P Linux filesys. data     16777214   67108861   50331648 [test1]
 D Linux filesys. data    524287998 3907020797 3382732800 [ext4purple]
 D MS Data                524287999 1048575998  524288000

  • test1 - это тестовый раздел, о котором я писал в нульпосте. он был удалён.
  • ext4purple - это битый раздел, который я пытаюсь восстановить. притом указана старая позиция, до перемещения и расширения.
  • MS Data - это бывшая ntfs файлопомойка, которая была удалена. но раньше она была в начале диска

Если на ext4purple нажать P (list files), выдает следующее: Can't open filesystem. Filesystem seems damaged.

Khronos
() автор топика
Ответ на: комментарий от Vsevolod-linuxoid

просто переустанови ОС и больше так не делай

Это не системный раздел, а файлопомойка. ОС на отдельном ssd не затронута, важные файлы на месте + забекаплены в облако, в этом плане я обо всём позаботился. Важных файлов на битом разделе не было, только фильмы, музыка, видосы с ютуба. 95% из них можно снова скачать из интернета, но на это придется потратить много времени.

Вытянуть данные я всегда успею с помощью r-linux, хотелось бы попробовать именно восстановить раздел если это возможно. Ранее был опыт восстановления битого exfat через dmde буквально в одно действие за пару сек, поэтому надеюсь что и тут не всё потеряно.

Khronos
() автор топика
Ответ на: комментарий от greenman

Спасибо за ссылку.

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

Ну, диск усердно что-то делал 9 часов подряд, думаю что раздел таки переместился.

Khronos
() автор топика
Ответ на: комментарий от naKovoNapalBaran

Если в gui разделы на предыдущем месте

В gui раздел переместился и расширился, но не определяется как ext4: https://i.imgur.com/3xUE4Ub.png

Короч, gpt таблицу редактируй, это не сложно.

Есть мануал как это сделать? Гугл выдает ерунду какую-то.

Khronos
() автор топика
Ответ на: комментарий от Khronos

Можешь в testdisk руками вбить начало и конец раздела.
Только не самые крайние т.к. таблица gpt вначале и конце дика, если раздел до конца расширен, то возможно он затер резервную таблицу.

naKovoNapalBaran
()
Ответ на: комментарий от Khronos

Редактировать с помощью parted.

mklabel gpt

unit s mkpart name ext4 2048 -1

Попробуй просканируй тестдиском на предмет партиций.

Еще в качестве теста хорошо использовать loop на весь диск с указанием смещения.

Подбираешь смещение так, чтобы файловая система взлетела.

AVL2 ★★★★★
()
Ответ на: комментарий от Khronos

На проблемном диске ничего не делай. Если тебе важны данные, то иди в магазин за диском больше размера и как сказали делай образ диска 2Тб и работай с образом, пытаясь восстановить файловую систему в образе.

Если данные не важные, то создай новую разметку (разделы) и создай новую файловую систему (отформатируй), смонтируй её и работай дальше.

Но тебе видимо данные не важны потому что ты пытаешься что-то делать с проблемным диском.

У тебя сейчас, скорее всего, повреждена файловая система и восстановить доступ к ней созданием новых записей в таблице разделов не получится. Даже fsck тебе, скорее всего, не поможет. Тебе нужны специализированные утилиты по восстановлений файлов с повреждённых файловых систем. К тому же платные, ну либо «трофейные».

kostik87 ★★★★★
()
Ответ на: комментарий от Khronos

удаление раздела не приводит к его повреждению, так тупо переписывается таблица разделов (первые 2048 секторов) и пересоздание раздела (без пересоздания файловой системы) делает его снова рабочим.

tz4678_2
()
Ответ на: комментарий от Khronos

диск усердно что-то делал 9 часов подряд, думаю что раздел таки переместился.

В логах есть такие строчки:

Copying 190,772 chunks (2,000,397,795,328 bytes) from 1,048,576 to 1,048,576, direction: left.

Copying remainder of chunk size 8,388,608 from 2,000,390,455,296 to 2,000,390,455,296.

Числа from и to совпадают. Похоже, программа читала кусок данных с диска, а потом в то же самое место записывала. Очень вероятно, что сама файловая система у тебя осталась на том же месте, и если восстановить предыдущее расположение раздела, ФС начнёт монтироваться.

i-rinat ★★★★★
()

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

amd_amd ★★★★★
()
Ответ на: комментарий от amd_amd

Ну так ты же данные не перемещал. Все изменения были в таблице разделов. Так ничего грохнуть нельзя. А если перемещать раздел, то большая часть будет банально затерта.

AVL2 ★★★★★
()

Напишу отчет на будущее, для таких же бедолаг как я.

С помощью сканирования r-linux выяснилось следующее:

Выполнил

sudo losetup -o $(( 524290048 * 512 ))  --sizelimit $(( 3382739120 * 512 )) -r -f /dev/sdb
sudo file -s /dev/loop0
sudo mount /dev/loop0 ~/mnt_tst/

С помощью losetup подбираем правильные числа смещения и размера раздела, потом через file -s /dev/loop0 смотрим результат - там должно быть что-то в духе Linux rev 1.0 ext4 filesystem data. Смонтировал - всё работает.

Затем в parted

mklabel gpt
unit s mkpart ext4purple ext4 524290048 -1

Пересоздалась таблица gpt и раздел ext4, без пересоздания файловой системы. Раздел на месте, файлы на месте, как будто ничего и не было.

Спасибо за идею и информацию @naKovoNapalBaran @tz4678_2 @AVL2

Khronos
() автор топика