Восстановление данных ext4 со структурой каталогов (GParted, незавершённая задача)

[ReSeR]

Требовалось объединить два раздела с ext4 в один.
В Gparted было выбрано удаление первого (пустого) раздела, второму было выбрано Resize (увеличение на всё оставшееся пространство). Во время выполнения пропало напряжение и после включения ПК, Gparted сказал, что нужно проверить на ошибки раздел. И после проверки на разделе остались живы только 7 файлов из ~40.000. Последнее, что делал Gparted, так это было перемещение файлов (из конца раздела в начало или наоборот, точно не помню). Теперь на диске есть этот большой раздел (объединенный один из двух), но без данных.
Пробовал:
tune2fs -O ^has_journal /dev/... - не отпустило.
Программы:
extundelete
photorec
UFS Explorer
DiskGetor Data Recovery
EASEUS Data Recovery Wizard Professional 5.0.1
Stellar Phoenix Linux Data Recovery
R-Linux
но все они восстанавливают файлы без структуры каталогов.
Точно знаю, с подобными проблемами я не один такой, по этому прошу бывалых поделиться опытом.
В общем, помогите пожалуйста, я в отчаянии.

[kyzic]

помогите пожалуйста, я в отчаянии.

Бэкап - акт проявления трусости.

пробовал восстанавливать, хорошего решения под линуксом не нашел. под винду есть какая-то прога (легко найдешь поиском), вроде неплохо восстанавливает, но платная проприентарщина. я в общем-то забил, ибо игра не стоит свеч в моем случае.

[Bizdelnick]

testdisk пробовали? Хотя с таким случаем он может не справиться, но тогда уже ничто не поможет.

[ReSeR]

Вы имеете в виду "photorec" из комплекта "testdisk"? Если да, то пробовал, она восстанавливает файлы без структуры. Или может ей нужно параметры указать какие?

[Bizdelnick]

Я имею в виду именно testdisk.

[ReSeR]

Нет. Сейчас попробую.

[ReSeR]

Как в доке сказано, запустил testdisk, выбрал Advanced и тот раздел с которого хочу восстановить. Но в доке есть пункт Undelete, а у меня нет. Выкачал с офф сайта последнюю версию, но и там Undelete нет. Выбрал в меню Advanced, пункт Superblock. Он мне выдал:

Код: Выделить всё

     Partition                  Start        End    Size in sectors

  Linux                 2743 138 20 14593  66  1  190365696 [home]
superblock 0, blocksize=4096 [home]
superblock 32768, blocksize=4096 [home]
superblock 98304, blocksize=4096 [home]
superblock 163840, blocksize=4096 [home]
superblock 229376, blocksize=4096 [home]
superblock 294912, blocksize=4096 [home]
superblock 819200, blocksize=4096 [home]
superblock 884736, blocksize=4096 [home]
superblock 1605632, blocksize=4096 [home]
superblock 2654208, blocksize=4096 [home]

To repair the filesystem using alternate superblock, run
fsck.ext4 -p -b superblock -B blocksize device

Если сделать

Код: Выделить всё

fsck.ext4 -p -b superblock -B blocksize device

хуже не сделаю?

[drBatty]

может и сделаете хуже. Надо над образом делать. У вас больше нет вариантов. Платные программы венды не помогут - ext4

[/dev/random]

Перемещение начала раздела влево (как в вашем случае) производится следующим образом.

Первоначальное состояние:
---|12345678|---

Здесь символы | обозначают границы раздела, а цифры - блоки ФС. Разумеется, на самом деле этих блоков гораздо больше.

Вначале удаляется раздел и пересоздаётся с изменёнными границами:
|---12345678|---

Затем начинают перемещаться блоки:
|1--12345678|---
|12-12345678|---
|12312345678|---
(назовём этот момент границей восстановления, ниже начинается запись поверх старых блоков)
|12342345678|---
|12345345678|---
|12345645678|---
|12345675678|---
|12345678678|---

Затем запись о размере ФС меняется, и блоки в конце регистрируются как новые, пустые блоки:
|123456789AB|---
Перемещение завершено.

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

Если выполнение прервалось _до_ "границы восстановления" (см. выше), то восстановить ФС несложно. Достаточно удалить раздел и пересоздать его в точности там, где он был первоначально, байт-в-байт:
-12|12345678|---
и ФС становится работоспособной. Если вы не помните, где был раздел, то такие инструменты, как testdisk, могут помочь найти нужную позицию. Нужно просто удалить раздел и включить восстановление. Программа найдёт несколько позиций, где могла начинаться ФС, и из них следует выбрать правильную.

Но если выполнение прервалось на позднем этапе, то этот способ не поможет:
-12|45345678|---
Очевидно, что то, что здесь находится между ||, не является файловой системой. Здесь уже невозможно не только автоматическое, но даже полуавтоматическое восстановление. Только ручное, выполняемое человеком, хорошо разбирающимся в структуре данной ФС. Необходимо выяснить, какие блоки были перемещены, и переместить их обратно. Ни один автоматический инструмент этого не сделает.

[drBatty]

Только ручное, выполняемое человеком, хорошо разбирающимся в структуре данной ФС.

надо ещё знать как GParted это делает...
проще photorec.

[ReSeR]

Если вы не помните, где был раздел, то такие инструменты, как testdisk, могут помочь найти нужную позицию. Нужно просто удалить раздел и включить восстановление. Программа найдёт несколько позиций, где могла начинаться ФС, и из них следует выбрать правильную.

Стоит попробовать.

Только ручное, выполняемое человеком, хорошо разбирающимся в структуре данной ФС.

надо ещё знать как GParted это делает...
проще photorec.

photorec восстановил мне кучу фалов, ещё не разбирал что толкового он восстановил. Но все они сложены хаотично и именуются символьно-цифровым способом (я так полагаю, по номерам inode).
Имена файлов никак вытащить ему не под силу?

[/dev/random]

Но все они сложены хаотично и именуются символьно-цифровым способом (я так полагаю, по номерам inode).

Нет, не по номерам inode. Если ФС убита в хлам (как в описанном выше случае, при прерывании после "границы восстановления"), то такого понятия, как "файл", на ней больше нет. Подобные программы ищут не файлы, а последовательности байтов, похожие на содержимое файлов определённого типа, и выдирают их, сохраняя в файлы с бессмысленными именами. Причём если файл был фрагментирован, то в этом "хламе" соответствующей ему последовательности байтов не будет (точнее, будет несколько её кусков, в разных местах), и восстановить его этим способом нельзя. Но даже если он не был фрагментирован, то это всё равно не файл, и говорить о именах или даже номерах инодов совершенно бессмысленно.
И, кстати, это _единственный_ не-ручной способ восстановления данных в ситуации, когда саму ФС спасти невозможно. Например, если питание у вас отключилось после описанной выше "границы восстановления".

[drBatty]

Имена файлов никак вытащить ему не под силу?

имена файлов хранятся не в файлах, а в каталогах. Каталог в EXT4 имеет сложную нерегулярную структуру, и photorec'ом НЕ выдирается. К сожалению. В принципе можно написать программу, которая восстанавливает каталоги (а следовательно и имена файлов и их иноды), но насколько я знаю, этим никто не озаботился.

По идее, если сделать образ диска, то можно восстановить так:
1. testdisk'ом ищем один из суперблоков, и его выбираем.
2. восстанавливаем ФС командой fsck.ext4
3. если ничего не получилось (или получилось не всё) GoTo 1.

И, кстати, это _единственный_ не-ручной способ восстановления данных в ситуации, когда саму ФС спасти невозможно. Например, если питание у вас отключилось после описанной выше "границы восстановления".

не, ну почему-же? за границей восстановления наверняка остался хотя-бы один суперблок, который восстановит все таблицы инодов, которые лежат полностью за этой границей. Ну а по таблице инодов можно восстановить многие файлы (в т.ч. и каталоги), опять-таки за этой границей. Правда это всё теория. На практике проще развернуть бекап. :)

[ReSeR]

И, кстати, это _единственный_ не-ручной способ восстановления данных в ситуации, когда саму ФС спасти невозможно. Например, если питание у вас отключилось после описанной выше "границы восстановления".

На сколько я помню, Gparted оставалось последнее перемещение данных. Так как из уже выполненных действий было: удаление пустого раздела, какое-то перемещение данных, увеличение границ раздела на все оставшееся пространство, и после это (так полагаю последнее) перемещение данных во время которого всё и рухнуло.

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

Получается если testdisk мне выдаёт:

Код: Выделить всё

     Partition                  Start        End    Size in sectors

  Linux                 2743 138 20 14593  66  1  190365696 [home]
superblock 0, blocksize=4096 [home]
superblock 32768, blocksize=4096 [home]
superblock 98304, blocksize=4096 [home]
superblock 163840, blocksize=4096 [home]
superblock 229376, blocksize=4096 [home]
superblock 294912, blocksize=4096 [home]
superblock 819200, blocksize=4096 [home]
superblock 884736, blocksize=4096 [home]
superblock 1605632, blocksize=4096 [home]
superblock 2654208, blocksize=4096 [home]

To repair the filesystem using alternate superblock, run
fsck.ext4 -p -b superblock -B blocksize device

то лучше попробовать восстановить по суперблоку?

[ReSeR]

Чем лучше сделать образ? Можно просто dd?

[sash-kan]

Можно просто dd?

можно просто cp·
эффект тот же, а писать (аргументы) меньше·
так зачем платить больше? ©

[/dev/random]

Можно просто dd?

можно просто cp·
эффект тот же, а писать (аргументы) меньше·
так зачем платить больше? ©

Я бы не стал рекомендовать использовать для этого cp. Я не раз встречал, что в некоторых дистрибутивах были предустановленные алиасы, задающие дефолтные параметры для cp. И нет никакой гарантии, что у человека, читающего этот совет, не будет установлено что-то вроде '-a' или '-r'. А с этими флагами cp будет создавать идентичный специальный файл вместо копирования содержимого.

У топикстартера debian, он подобным не страдает, но тему кто-то может найти в поисковике.

[sash-kan]

Я не раз встречал, что в некоторых дистрибутивах были предустановленные алиасы, задающие дефолтные параметры для cp. И нет никакой гарантии, что у человека, читающего этот совет, не будет установлено что-то вроде '-a' или '-r'.

примеры дистрибутивов, в которых встречаются такие идиоты среди мэйнтэйнеров, подсовывающие root-у вообще какие-нибудь alias-ы, приведи, пожалуйста·

p.s. если пользоваться cp для данный задачи «рекомендуемым» способом — sudo cp image /dev/blabla, то никакие и ничьи alias-ы влияния не окажут·
p.p.s. а вообще много чего у «человека из поисковика» может быть экзотического в системе (равно как и сама система)·
вот только если писать пост, предусматривая все мало-мальски возможные варианты…

[/dev/random]

примеры дистрибутивов, в которых встречаются такие идиоты среди мэйнтэйнеров, приведи, пожалуйста·

Именно этих флагов не видел ни разу (к счастью), А вот --interactive чуть ли не на всех командах, которые его поддерживают - несколько лет назад в мандриве. Кстати, с тех пор я каждый раз, когда сажусь за чужую машину, первым делом ввожу unalias -a.

Но это уже оффтоп.

[Bizdelnick]

примеры дистрибутивов, в которых встречаются такие идиоты среди мэйнтэйнеров, подсовывающие root-у вообще какие-нибудь alias-ы, приведи, пожалуйста·

$

$ cat /etc/profile /etc/profile.d/* | grep '^alias' alias mc 'source /usr/lib/mc/mc-wrapper.csh' alias mc='. /usr/lib/mc/mc-wrapper.sh' alias ls="ls $LS_OPTIONS" alias d="ls" alias l="ls" # classical listing. alias ll="ls -l" # List detailled. alias la='ls -a' # List all. alias lsd="ls -d */" # List only the directory. alias cd..="cd .." alias s="cd .." alias p="cd -" alias md="mkdir" alias rd="rmdir" alias cp="cp -i" alias mv="mv -i" alias rm="rm -i" alias grep="grep --color" # colored grep by default alias egrep="egrep --color" # colored grep by default alias fgrep="fgrep --color" # colored grep by default alias du='du -h' alias df='df -h -x supermount'

Что за дистрибутив - сам догадаешься?

[ReSeR]

В общем, можно ставить отметку [РЕШЕНО]
Из всего перечня:

Код: Выделить всё

tune2fs -O ^has_journal /dev/...
extundelete
photorec
UFS Explorer
DiskGetor Data Recovery
EASEUS Data Recovery Wizard Professional 5.0.1
Stellar Phoenix Linux Data Recovery
R-Linux

ничего не подошло, т.к. восстановление делают пофайлово.
Восстановил данные на 75% при помощи R-Studio, она и структуру каталогов восстановила, имена файлов и директорий.

[sash-kan]

Что за дистрибутив - сам догадаешься?

догадался·

$ cat /etc/profile /etc/profile.d/* | grep '^alias'

само по себе это ни о чём не говорит·
а вот это:
$ sudo -i alias | wc -l
20
тянет на жирный матерный багрепорт·
и вот это — тоже:

Код: Выделить всё

$ cat /etc/profile.d/20mc.sh
# Don't define aliases in plain Bourne shell
[ -n "${BASH_VERSION}${KSH_VERSION}${ZSH_VERSION}" ] || return 0
alias mc='. /usr/lib/mc/mc-wrapper.sh'

if [ "$PS1" ]  && [ -n "$BASH" ]; then
    # work around mc history issues (#59547)
    # see also https://midnight-commander.org/ticket/2104 for other solutions
    # and workarounds
    HISTIGNORE=" cd \"\`*: PROMPT_COMMAND=?*?"
fi

[sash-kan]

а вот это:
$ sudo -i alias | wc -l
20
тянет на жирный матерный багрепорт·

кстати, этот баг актуален лишь для любителей нарушать правила хорошего тона, т.е., не пользоваться sudo·
ибо:
$ sudo bash -c 'alias' | wc -l
0