(РЕШЕНО) Сломался BTRFS

vasek	# 5 лет, 8 месяцев назад
Темы: 47 Сообщения: 11859 Участник с: 17 февраля 2013	Shama_comp И что каждый файл вытаскивать? Грубо можно разделить проблему на две ситуации 1) Система хоть и не рабочая, но раздел определяется и данные (файлы) на разделе видны, например, из другой системы или Live CD. В данной ситуации нет проблемы с извлечением файлов и как правило стоит задача реанимировать систему. Плюс к этому важная инфа всегда бэкапится. 2) Система не рабочая и раздел не определяется, а в большинстве случаев это просто образ такой системы или же ее частей. В данной ситуации не стоит задача реанимации системы, а стоит задача вытащить конкретные данные, то есть отдельные файлы, содержащие важную информацию. То есть на первом месте стоит ИНФОРМАЦИЯ, заключенная в отдельных файлах. И в наилучшем случае имена этих файлов, их приблизительное сдержание и формат известны. И чем меньше информации о данных файлах мы имеем, тем труднее их извлечение. Лично меня интересует 2-ая ситуация. Зачем, не спрашивай ... И на btrfs смотрю именно с этой точки зрения, захотел посмотреть запасной вариант с использованием inspect-internal dump-tree - всегда должно быть что то в запасе, на всякий пожарный. Повторюсь - самый надежный способ это поиск по сигнатуре. Но бывают ситуации когда файлов с такой сигнатурой море и найти нужный проблематично - вот тут то и не плохо иметь дополнительную информацию о приблизительном расположении файла в системе, его имени и размере. PS 1 - у nafanja стоит задача, насколько я понял, спасти систему. Думаю файлы с нужной информацией у него продублированы в другом месте и его это особо не беспокоит. PS 2 - ну а если нужно вытащить много файлов, то для этого есть специальные утилиты, не зависящие от типа файловой структуры, работающие с raw date - foremost и scalpel, правда они не все сигнатуры понимают, им нужно это объяснять. Ошибки не исчезают с опытом - они просто умнеют

# 5 лет, 8 месяцев назад

Сообщения: 11859

Участник с: 17 февраля 2013

Shama_comp
И что каждый файл вытаскивать?

Грубо можно разделить проблему на две ситуации
1) Система хоть и не рабочая, но раздел определяется и данные (файлы) на разделе видны, например, из другой системы или Live CD. В данной ситуации нет проблемы с извлечением файлов и как правило стоит задача реанимировать систему. Плюс к этому важная инфа всегда бэкапится.
2) Система не рабочая и раздел не определяется, а в большинстве случаев это просто образ такой системы или же ее частей. В данной ситуации не стоит задача реанимации системы, а стоит задача вытащить конкретные данные, то есть отдельные файлы, содержащие важную информацию. То есть на первом месте стоит ИНФОРМАЦИЯ, заключенная в отдельных файлах. И в наилучшем случае имена этих файлов, их приблизительное сдержание и формат известны. И чем меньше информации о данных файлах мы имеем, тем труднее их извлечение.

Лично меня интересует 2-ая ситуация. Зачем, не спрашивай ... И на btrfs смотрю именно с этой точки зрения, захотел посмотреть запасной вариант с использованием inspect-internal dump-tree - всегда должно быть что то в запасе, на всякий пожарный.
Повторюсь - самый надежный способ это поиск по сигнатуре. Но бывают ситуации когда файлов с такой сигнатурой море и найти нужный проблематично - вот тут то и не плохо иметь дополнительную информацию о приблизительном расположении файла в системе, его имени и размере.

PS 1 - у nafanja стоит задача, насколько я понял, спасти систему. Думаю файлы с нужной информацией у него продублированы в другом месте и его это особо не беспокоит.

PS 2 - ну а если нужно вытащить много файлов, то для этого есть специальные утилиты, не зависящие от типа файловой структуры, работающие с raw date - foremost и scalpel, правда они не все сигнатуры понимают, им нужно это объяснять.

Ошибки не исчезают с опытом - они просто умнеют

Shama_comp	# 5 лет, 8 месяцев назад
Темы: 2 Сообщения: 39 Участник с: 28 июня 2017	vasek PS 1 - у nafanja стоит задача, насколько я понял, спасти систему. Думаю файлы с нужной информацией у него продублированы в другом месте и его это особо не беспокоит. А я думал наоборот восстановить данные. С моей точки зрения на систему-то п*срать ведь ее легко можно переустановить исключение составляют конфиги, которые заточены "под себя", а ну а дефолтные не важно они есть и все работает без настройки и редактирования.

Shama_comp

# 5 лет, 8 месяцев назад

Темы: 2

Сообщения: 39

Участник с: 28 июня 2017

vasek
PS 1 - у nafanja стоит задача, насколько я понял, спасти систему. Думаю файлы с нужной информацией у него продублированы в другом месте и его это особо не беспокоит.

А я думал наоборот восстановить данные. С моей точки зрения на систему-то п*срать ведь ее легко можно переустановить исключение составляют конфиги, которые заточены "под себя", а ну а дефолтные не важно они есть и все работает без настройки и редактирования.

vasek	# 5 лет, 8 месяцев назад
Темы: 47 Сообщения: 11859 Участник с: 17 февраля 2013	Shama_comp С моей точки зрения на систему-то п*срать ведь ее легко можно переустановить исключение составляют конфиги, которые заточены "под себя", а ну а дефолтные не важно они есть и все работает без настройки и редактирования. Согласен, думаю большинство так и делает, плюс к этому и бэкапит нужные документы, хранящиеся в /home. Но всегда интересно поработать над восстановлением системы, у большинства системы стоят много, много лет. Ошибки не исчезают с опытом - они просто умнеют

vasek

# 5 лет, 8 месяцев назад

Темы: 47

Сообщения: 11859

Участник с: 17 февраля 2013

Shama_comp
С моей точки зрения на систему-то п*срать ведь ее легко можно переустановить исключение составляют конфиги, которые заточены "под себя", а ну а дефолтные не важно они есть и все работает без настройки и редактирования.

Согласен, думаю большинство так и делает, плюс к этому и бэкапит нужные документы, хранящиеся в /home.
Но всегда интересно поработать над восстановлением системы, у большинства системы стоят много, много лет.

Ошибки не исчезают с опытом - они просто умнеют

Shama_comp	# 5 лет, 8 месяцев назад
Темы: 2 Сообщения: 39 Участник с: 28 июня 2017	vasek Но всегда интересно поработать над восстановлением системы, у большинства системы стоят много, много лет. Согласен да интересно разобраться в чем проблема. За одно не малый опыт приобрести по восстановлению данных на экзотической ФС. Ведь по-моему мнению это единственное нас отличает от "форточников", которые себя не утруждают и тянутся к загрузочной флешке\болванки для переустановки ОСи, конечно, не все так делают, но большинство. Даже не знаю, чтобы я делал в такой ситуации,наверное, тоже потянулся к загрузочной флешке с Арчем. Плохая,конечно, манера, но она у сохранилась как не печально было бы мне.

Shama_comp

# 5 лет, 8 месяцев назад

Темы: 2

Сообщения: 39

Участник с: 28 июня 2017

vasek
Но всегда интересно поработать над восстановлением системы, у большинства системы стоят много, много лет.

Согласен да интересно разобраться в чем проблема. За одно не малый опыт приобрести по восстановлению данных на экзотической ФС. Ведь по-моему мнению это единственное нас отличает от "форточников", которые себя не утруждают и тянутся к загрузочной флешке\болванки для переустановки ОСи, конечно, не все так делают, но большинство. Даже не знаю, чтобы я делал в такой ситуации,наверное, тоже потянулся к загрузочной флешке с Арчем. Плохая,конечно, манера, но она у сохранилась как не печально было бы мне.

nafanja	# 5 лет, 7 месяцев назад (отредактировано 5 лет, 7 месяцев назад)
Темы: 94 Сообщения: 9252 Участник с: 02 июня 2012 заблокирован	и так, итоги. команда которая привела к тому что раздел можно было примонтировать раздел в режиме RO: mint@mint:~$ sudo btrfs check –repair –init-extent-tree /dev/sda3 enabling repair mode Checking filesystem on /dev/sda3 UUID: 4432f74b-a439-48cc-96e6-226c7902d714 Creating a new extent tree Failed to find [487869906944, 168, 16384] btrfs unable to find ref byte nr 487869906944 parent 0 root 1 owner 1 offset 0 Failed to find [487870529536, 168, 16384] btrfs unable to find ref byte nr 487870660608 parent 0 root 1 owner 0 offset 1 Failed to find [487870562304, 168, 16384] btrfs unable to find ref byte nr 487994556416 parent 0 root 1 owner 0 offset 1 checking extents ref mismatch on [451362684928 4096] extent item 0, found 8 data backref 451362684928 parent 580500160512 owner 0 offset 0 num_refs 0 not found in extent tree incorrect local backref count on 451362684928 parent 580500160512 owner 0 offset 0 found 1 wanted 0 back 0x5ff983c0 data backref 451362684928 parent 580158013440 owner 0 offset 0 num_refs 0 not found in extent tree incorrect local backref count on 451362684928 parent 580158013440 owner 0 offset 0 found 1 wanted 0 back 0x13bc2080 data backref 451362684928 parent 580451762176 owner 0 offset 0 num_refs 0 not found in extent tree incorrect local backref count on 451362684928 parent 580451762176 owner 0 offset 0 found 1 wanted 0 back 0x5e0d3250 data backref 451362684928 parent 513070186496 owner 0 offset 0 num_refs 0 not found in extent tree incorrect local backref count on 451362684928 parent 513070186496 owner 0 offset 0 found 1 wanted 0 back 0x13e21dd0 data backref 451362684928 parent 488814985216 owner 0 offset 0 num_refs 0 not found in extent tree incorrect local backref count on 451362684928 parent 488814985216 owner 0 offset 0 found 1 wanted 0 back 0x857ac10 data backref 451362684928 parent 579627270144 owner 0 offset 0 num_refs 0 not found in extent tree incorrect local backref count on 451362684928 parent 579627270144 owner 0 offset 0 found 1 wanted 0 back 0x84f97a0 data backref 451362684928 root 471 owner 7010715 offset 589824 num_refs 0 not found in extent tree incorrect local backref count on 451362684928 root 471 owner 7010715 offset 589824 found 1 wanted 0 back 0x57f5d280 data backref 451362684928 parent 488756936704 owner 0 offset 0 num_refs 0 not found in extent tree incorrect local backref count on 451362684928 parent 488756936704 owner 0 offset 0 found 1 wanted 0 back 0xd65d320 backpointer mismatch on [451362684928 4096] adding new data backref on 451362684928 parent 580500160512 owner 0 offset 0 found 1 adding new data backref on 451362684928 parent 580158013440 owner 0 offset 0 found 1 adding new data backref on 451362684928 parent 580451762176 owner 0 offset 0 found 1 adding new data backref on 451362684928 parent 513070186496 owner 0 offset 0 found 1 adding new data backref on 451362684928 parent 488814985216 owner 0 offset 0 found 1 adding new data backref on 451362684928 parent 579627270144 owner 0 offset 0 found 1 adding new data backref on 451362684928 root 471 owner 7010715 offset 589824 found 1 adding new data backref on 451362684928 parent 488756936704 owner 0 offset 0 found 1 Repaired extent references for 451362684928 ref mismatch on [451362689024 4096] extent item 0, found 1 data backref 451362689024 parent 513244233728 owner 0 offset 0 num_refs 0 not found in extent tree incorrect local backref count on 451362689024 parent 513244233728 owner 0 offset 0 found 1 wanted 0 back 0x2bb1880 backpointer mismatch on [451362689024 4096] adding new data backref on 451362689024 parent 513244233728 owner 0 offset 0 found 1 Repaired extent references for 451362689024 ref mismatch on [451362693120 28672] extent item 0, found 1 data backref 451362693120 root 725 owner 1293192 offset 1048576 num_refs 0 not found in extent tree incorrect local backref count on 451362693120 root 725 owner 1293192 offset 1048576 found 1 wanted 0 back 0x2722ca20 backpointer mismatch on [451362693120 28672] adding new data backref on 451362693120 root 725 owner 1293192 offset 1048576 found 1 .... до окончания я так и не дождался, макс что было это 12 часов (и это на ssd размер ~100Г), но хватило бы, для того же результата, и 15 минут. после выполнения команды я все же сумел подключить раздел только для чтения и вытащить нужные данные, но не все... для под тома @kubuntu_root не было ниодного снимка (я до поломки подчищал, что бы выделить место) и на верное по этому я не смог полностью вытащить все данные с него, где то была ошибка чтения записи. под тома @archlinux_boot @kubuntu_boot @archlinux_root были скопированны без ошибок. под том @home_all был тоже поврежден, но для него были снимки, поэтому удалось вытащить данные только с задержкой 1 час назад (снимки home делались каждый час). выводы: btrfs в принципе это хорошо для экономии места: сжатие, псевдоразделы совместно использующие все доступное свободное пространство, снимки как история изменений, штатные средства для настоящих и даже инкрементных бэкапов, а не просто снимки. так и плохо, потому что это все же одна фс, если испортится, то потянет и псевдоразделы (под тома)... я могу рекомендовать btrfs тем, у кого много свободного места для снимков, но все же настоящий бэкап на другом диске никогда не помешает!!! Псевдографический инсталлятор Arch Linux ver. 3.8.2 Благодарности принимаются на ЯД 410012815723874

nafanja

# 5 лет, 7 месяцев назад (отредактировано 5 лет, 7 месяцев назад)

Темы: 94

Сообщения: 9252

Участник с: 02 июня 2012

заблокирован

и так, итоги.
команда которая привела к тому что раздел можно было примонтировать раздел в режиме RO:
mint@mint:~$ sudo btrfs check –repair –init-extent-tree /dev/sda3

enabling repair mode
Checking filesystem on /dev/sda3
UUID: 4432f74b-a439-48cc-96e6-226c7902d714
Creating a new extent tree
Failed to find [487869906944, 168, 16384]
btrfs unable to find ref byte nr 487869906944 parent 0 root 1  owner 1 offset 0
Failed to find [487870529536, 168, 16384]
btrfs unable to find ref byte nr 487870660608 parent 0 root 1  owner 0 offset 1
Failed to find [487870562304, 168, 16384]
btrfs unable to find ref byte nr 487994556416 parent 0 root 1  owner 0 offset 1
checking extents
ref mismatch on [451362684928 4096] extent item 0, found 8
data backref 451362684928 parent 580500160512 owner 0 offset 0 num_refs 0 not found in extent tree
incorrect local backref count on 451362684928 parent 580500160512 owner 0 offset 0 found 1 wanted 0 back 0x5ff983c0
data backref 451362684928 parent 580158013440 owner 0 offset 0 num_refs 0 not found in extent tree
incorrect local backref count on 451362684928 parent 580158013440 owner 0 offset 0 found 1 wanted 0 back 0x13bc2080
data backref 451362684928 parent 580451762176 owner 0 offset 0 num_refs 0 not found in extent tree
incorrect local backref count on 451362684928 parent 580451762176 owner 0 offset 0 found 1 wanted 0 back 0x5e0d3250
data backref 451362684928 parent 513070186496 owner 0 offset 0 num_refs 0 not found in extent tree
incorrect local backref count on 451362684928 parent 513070186496 owner 0 offset 0 found 1 wanted 0 back 0x13e21dd0
data backref 451362684928 parent 488814985216 owner 0 offset 0 num_refs 0 not found in extent tree
incorrect local backref count on 451362684928 parent 488814985216 owner 0 offset 0 found 1 wanted 0 back 0x857ac10
data backref 451362684928 parent 579627270144 owner 0 offset 0 num_refs 0 not found in extent tree
incorrect local backref count on 451362684928 parent 579627270144 owner 0 offset 0 found 1 wanted 0 back 0x84f97a0
data backref 451362684928 root 471 owner 7010715 offset 589824 num_refs 0 not found in extent tree
incorrect local backref count on 451362684928 root 471 owner 7010715 offset 589824 found 1 wanted 0 back 0x57f5d280
data backref 451362684928 parent 488756936704 owner 0 offset 0 num_refs 0 not found in extent tree
incorrect local backref count on 451362684928 parent 488756936704 owner 0 offset 0 found 1 wanted 0 back 0xd65d320
backpointer mismatch on [451362684928 4096]
adding new data backref on 451362684928 parent 580500160512 owner 0 offset 0 found 1
adding new data backref on 451362684928 parent 580158013440 owner 0 offset 0 found 1
adding new data backref on 451362684928 parent 580451762176 owner 0 offset 0 found 1
adding new data backref on 451362684928 parent 513070186496 owner 0 offset 0 found 1
adding new data backref on 451362684928 parent 488814985216 owner 0 offset 0 found 1
adding new data backref on 451362684928 parent 579627270144 owner 0 offset 0 found 1
adding new data backref on 451362684928 root 471 owner 7010715 offset 589824 found 1
adding new data backref on 451362684928 parent 488756936704 owner 0 offset 0 found 1
Repaired extent references for 451362684928
ref mismatch on [451362689024 4096] extent item 0, found 1
data backref 451362689024 parent 513244233728 owner 0 offset 0 num_refs 0 not found in extent tree
incorrect local backref count on 451362689024 parent 513244233728 owner 0 offset 0 found 1 wanted 0 back 0x2bb1880
backpointer mismatch on [451362689024 4096]
adding new data backref on 451362689024 parent 513244233728 owner 0 offset 0 found 1
Repaired extent references for 451362689024
ref mismatch on [451362693120 28672] extent item 0, found 1
data backref 451362693120 root 725 owner 1293192 offset 1048576 num_refs 0 not found in extent tree
incorrect local backref count on 451362693120 root 725 owner 1293192 offset 1048576 found 1 wanted 0 back 0x2722ca20
backpointer mismatch on [451362693120 28672]
adding new data backref on 451362693120 root 725 owner 1293192 offset 1048576 found 1
....

до окончания я так и не дождался, макс что было это 12 часов (и это на ssd размер ~100Г), но хватило бы, для того же результата, и 15 минут.
после выполнения команды я все же сумел подключить раздел только для чтения и вытащить нужные данные, но не все...
для под тома @kubuntu_root не было ниодного снимка (я до поломки подчищал, что бы выделить место) и на верное по этому я не смог полностью вытащить все данные с него, где то была ошибка чтения записи.
под тома @archlinux_boot @kubuntu_boot @archlinux_root были скопированны без ошибок.
под том @home_all был тоже поврежден, но для него были снимки, поэтому удалось вытащить данные только с задержкой 1 час назад (снимки home делались каждый час).

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

я могу рекомендовать btrfs тем, у кого много свободного места для снимков, но все же настоящий бэкап на другом диске никогда не помешает!!!

Псевдографический инсталлятор Arch Linux ver. 3.8.2
Благодарности принимаются на ЯД 410012815723874

Dobrov	# 5 лет, 3 месяца назад (отредактировано 5 лет, 3 месяца назад)
Темы: 17 Сообщения: 148 Участник с: 03 ноября 2017	Как восстановить каталог с повреждённого btrfs раздела? (поднимаю продолжение темы) Предыстория: поставил CentOS 7, результат: btrfs раздел оказался удалён. Где был первый сектор btrfs-раздела, не знаю. Вывод gdisk: `Disk /dev/sdb: 1953525168 sectors, 931.5 GiB Total free space is 169312222 sectors (80.7 GiB) № Start (sector) End (sector) Size Code Name 1 2048 786431 383.0 MiB EF00 EFI System Partition 3 170096640 1886412799 818.4 GiB NTFS исправный раздел 4 1886412800 1953525134 32.0 GiB сюда поставил CentOS 7` под № 2 примерно с 786432 сектора был btrfs-раздел на 80 GB Далее я поломал таблицу файлов: в gparted под Arch-Linux создал на этом свободном месте btrfs-раздел, и gparted пересоздал btrfs структуру. Как исправить мою ошибку? Дамп в testdisk я сделал лишь после того, как gparted всё затёр, создав btrfs заново. Пробовал искать суперблок: sudo btrfs inspect-internal dump-super -a /dev/sdb2 superblock: bytenr=65536, device=/dev/sdb2 ERROR: bad magic on superblock on /dev/sdb2 at 65536 superblock: bytenr=67108864, device=/dev/sdb2 ERROR: bad magic on superblock on /dev/sdb2 at 67108864 Текущий вывод gdisk, неизвестно настоящее начало btrfs-раздела: Disk /dev/sdb: 1953525168 sectors, 931.5 GiB Sector size (logical/physical): 512/4096 bytes Partition table holds up to 128 entries Main partition table begins at sector 2 and ends at sector 33 First usable sector is 34, last usable sector is 1953525134 Partitions will be aligned on 2048-sector boundaries Total free space is 2014 sectors (1007.0 KiB) Number Start (sector) End (sector) Size Code Name 1 2048 786431 383.0 MiB EF00 EFI System Partition 2 786432 170096639 80.7 GiB 8300 Linux filesystem 3 170096640 1886412799 818.4 GiB 0700 Basic data partition 4 1886412800 1953525134 32.0 GiB 0700 Basic data partition Мне нужно вытащить каталог с фотками, их было десятки тысяч! btrfs-раздел был со включенным сжатием, без подтомов, снимки файловой системы я не делал.

Dobrov

# 5 лет, 3 месяца назад (отредактировано 5 лет, 3 месяца назад)

Темы: 17

Сообщения: 148

Участник с: 03 ноября 2017

Как восстановить каталог с повреждённого btrfs раздела? (поднимаю продолжение темы)
Предыстория: поставил CentOS 7, результат: btrfs раздел оказался удалён.
Где был первый сектор btrfs-раздела, не знаю. Вывод gdisk:

Disk /dev/sdb: 1953525168 sectors, 931.5 GiB
Total free space is 169312222 sectors (80.7 GiB)

№  Start (sector) End (sector)  Size      Code  Name
1            2048       786431   383.0 MiB  EF00 EFI System Partition
3       170096640   1886412799   818.4 GiB  NTFS  исправный раздел
4      1886412800   1953525134   32.0 GiB   сюда поставил CentOS 7

под № 2 примерно с 786432 сектора был btrfs-раздел на 80 GB
Далее я поломал таблицу файлов: в gparted под Arch-Linux создал на этом свободном месте btrfs-раздел, и gparted пересоздал btrfs структуру.
Как исправить мою ошибку? Дамп в testdisk я сделал лишь после того, как gparted всё затёр, создав btrfs заново.

Пробовал искать суперблок: sudo btrfs inspect-internal dump-super -a /dev/sdb2
superblock: bytenr=65536, device=/dev/sdb2
ERROR: bad magic on superblock on /dev/sdb2 at 65536
superblock: bytenr=67108864, device=/dev/sdb2
ERROR: bad magic on superblock on /dev/sdb2 at 67108864

Текущий вывод gdisk, неизвестно настоящее начало btrfs-раздела:

Disk /dev/sdb: 1953525168 sectors, 931.5 GiB
Sector size (logical/physical): 512/4096 bytes
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 1953525134
Partitions will be aligned on 2048-sector boundaries
Total free space is 2014 sectors (1007.0 KiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048          786431   383.0 MiB   EF00  EFI System Partition
   2          786432       170096639   80.7 GiB    8300  Linux filesystem
   3       170096640      1886412799   818.4 GiB   0700  Basic data partition
   4      1886412800      1953525134   32.0 GiB    0700  Basic data partition

Мне нужно вытащить каталог с фотками, их было десятки тысяч!
btrfs-раздел был со включенным сжатием, без подтомов, снимки файловой системы я не делал.

vasek	# 5 лет, 3 месяца назад (отредактировано 5 лет, 3 месяца назад)
Темы: 47 Сообщения: 11859 Участник с: 17 февраля 2013	Dobrov Мне нужно вытащить каталог с фотками, их было десятки тысяч! btrfs - неплохая система, но нет софта для восстановления удаленных разделов и не все хорошо обстоит с восстановлением файлов. Так как файлов (фоток) очень и очень много, то вижу один путь для их восстановления - утилиты foremost и scalpel (одинакового типа, но scalpel из AUR и более шустрая - хотя все это относительно) - работают не с файловой системой, а с raw date и файлы находятся по их сигнатуре. Удобнее для начала задать один тип файлов и прошерстить раздел/диск, если все найдется, то можно дальше задать уже и несколько типов, но, имхо, лучше так и искать по отдельности. В инете много примеров их использования. EDIT 1 - плохо то, что Dobrov Предыстория: поставил CentOS 7, результат: btrfs раздел оказался удалён. Многие файлы могут быть затерты. Можно для интереса (да и набора информации) попробовать востановить ручками любое фото (как, описывал в одном из блогов). Вот если бы не btrfs .... можно было бы пробовать восстановить раздел, используя дисковый редактор ... Ошибки не исчезают с опытом - они просто умнеют

vasek

# 5 лет, 3 месяца назад (отредактировано 5 лет, 3 месяца назад)

Темы: 47

Сообщения: 11859

Участник с: 17 февраля 2013

Dobrov
Мне нужно вытащить каталог с фотками, их было десятки тысяч!

btrfs - неплохая система, но нет софта для восстановления удаленных разделов и не все хорошо обстоит с восстановлением файлов.
Так как файлов (фоток) очень и очень много, то вижу один путь для их восстановления - утилиты foremost и scalpel (одинакового типа, но scalpel из AUR и более шустрая - хотя все это относительно) - работают не с файловой системой, а с raw date и файлы находятся по их сигнатуре. Удобнее для начала задать один тип файлов и прошерстить раздел/диск, если все найдется, то можно дальше задать уже и несколько типов, но, имхо, лучше так и искать по отдельности.
В инете много примеров их использования.

EDIT 1 - плохо то, что

Dobrov
Предыстория: поставил CentOS 7, результат: btrfs раздел оказался удалён.

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

Ошибки не исчезают с опытом - они просто умнеют

Dobrov	# 5 лет, 3 месяца назад
Темы: 17 Сообщения: 148 Участник с: 03 ноября 2017	vasek Вот если бы не btrfs …. можно было бы пробовать восстановить раздел, используя дисковый редактор … А есть возможность найти в btrfs цепочки каталогов? Фото были сгруппированы и имена каталогов были важны. dmde, testdisk и scalpel находят файлы, но это сортировать всё это слишком долго…

Dobrov

# 5 лет, 3 месяца назад

Темы: 17

Сообщения: 148

Участник с: 03 ноября 2017

vasek
Вот если бы не btrfs …. можно было бы пробовать восстановить раздел, используя дисковый редактор …

А есть возможность найти в btrfs цепочки каталогов? Фото были сгруппированы и имена каталогов были важны.
dmde, testdisk и scalpel находят файлы, но это сортировать всё это слишком долго…

vasek	# 5 лет, 3 месяца назад
Темы: 47 Сообщения: 11859 Участник с: 17 февраля 2013	Dobrov А есть возможность найти в btrfs цепочки каталогов? Фото были сгруппированы и имена каталогов были важны. Я btrfs практически не знаю, но утилиты восстанавливают, как правило файлы, а не директории - любая директория в файловой системе это тот же файл, размером обычно 4096 байт (1 страница), но inode директории имеет таблицу всех inode входящих в эту директорию (дерево). При удалении файла, удаляется не содержимое файла а его информация об inode (нет inode, нет файла). Удалили директорию, но не удалили файлы, входящие в эту директорию, а удалили информацию об inode. То есть нужно восстанавливать файлы, а не директории. Писал по памяти, почти не думая, так что возможны и не точности. Строго прошу не судить. Ошибки не исчезают с опытом - они просто умнеют

vasek

# 5 лет, 3 месяца назад

Темы: 47

Сообщения: 11859

Участник с: 17 февраля 2013

Dobrov
А есть возможность найти в btrfs цепочки каталогов? Фото были сгруппированы и имена каталогов были важны.

Я btrfs практически не знаю, но утилиты восстанавливают, как правило файлы, а не директории - любая директория в файловой системе это тот же файл, размером обычно 4096 байт (1 страница), но inode директории имеет таблицу всех inode входящих в эту директорию (дерево). При удалении файла, удаляется не содержимое файла а его информация об inode (нет inode, нет файла). Удалили директорию, но не удалили файлы, входящие в эту директорию, а удалили информацию об inode. То есть нужно восстанавливать файлы, а не директории.
Писал по памяти, почти не думая, так что возможны и не точности. Строго прошу не судить.

Ошибки не исчезают с опытом - они просто умнеют

vasek	# 5 лет, 3 месяца назад
Темы: 47 Сообщения: 11859 Участник с: 17 февраля 2013	Dobrov dmde …. находят файлы, Забыл спросить, давно не работал с DMDE - вроде бы DMDE не поддерживает btrfs? Ошибки не исчезают с опытом - они просто умнеют